Latest working kernel version: 2.6.25 Earliest failing kernel version: all Distribution: Linux from scratch Hardware Environment: Athlon64 x2 (x86-64), Asus M2N-E Software Environment: Problem Description: When I use s2ram to suspend to ram, everything works, except the network (forcedeth) that doesn't come back from suspend. So I have to reboot the machine. Steps to reproduce: 1) s2ram 2) then wake up from suspend 3) network isn't working anymore
Reply-To: akpm@linux-foundation.org (switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface). > On Sun, 20 Apr 2008 00:06:07 -0700 (PDT) bugme-daemon@bugzilla.kernel.org > wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=10487 > > Summary: NIC (forcedeth) doesn't work with suspend (S3) > Product: Power Management > Version: 2.5 > KernelVersion: 2.6.25 > Platform: All > OS/Version: Linux > Tree: Mainline > Status: NEW > Severity: high > Priority: P1 > Component: Hibernation/Suspend > AssignedTo: power-management_other@kernel-bugs.osdl.org > ReportedBy: fragabr@gmail.com > > > Latest working kernel version: 2.6.25 No, that's not right. Please tell us the latest version of the kernel which worked OK. > Earliest failing kernel version: all > Distribution: Linux from scratch > Hardware Environment: Athlon64 x2 (x86-64), Asus M2N-E > Software Environment: > Problem Description: > > When I use s2ram to suspend to ram, everything works, except the network > (forcedeth) that doesn't come back from suspend. So I have to reboot the > machine. > > Steps to reproduce: > > 1) s2ram > > 2) then wake up from suspend > > 3) network isn't working anymore > >
On Sun, 20 Apr 2008 15:21:35 -0700 Andrew Morton <akpm@linux-foundation.org> wrote: > No, that's not right. Please tell us the latest version of the kernel > which worked OK. No versions worked. Since I acquired this motherboard (Asus M2N-E), I couldn't suspend because of the NIC. Is there any test I can do to help you figure it out what's happening? Thanks.
I have a similar problem with suspend to disk, but I use modprobe to re-init the kernel module (modprobe -r forcedeth ; modprobe forcedeth), so network is working without a reboot.
Fixed in 2.6.27-rc4.
Well, I tested with 2.6.27-rc8 and it still doesn't work. I can't even set the default gateway after it wake up from S3. It returns "network unreachable".
I tested again with 2.6.28-rc2 and it still doesn't work. Just as an update report. It has the same behaviour as before: I can't even set the default gateway after it wake up from S3. It returns "network unreachable".
Does "modprobe -r forcedeth ; modprobe forcedeth" as root works?
(In reply to comment #7) > Does "modprobe -r forcedeth ; modprobe forcedeth" as root works? > No. It always returns "network unreachable" when it returns from S3, when setting the route.
Hi, I have a similar (probably the same) problem with a Gigabyte GA-M57SLI-S4 motherboard (nVidia nForce 570 SLI chipset; nVidia Corp. MCP55 Ethernet (rev a3)) when suspending with pm-* (using s2ram). I've tested with Debian's 2.6.26-* and with the official 2.6.28-rc9. With the 2.6.28-rc9, after resume the driver seems not to recognize the link (nothing visible on the logs when I plug/unplug the cable) and the interface doesn't work. I can do up/down on the interface, but nothing better happens. A reload of the driver after resume time doesn't make things working better. With Debian's 2.6.26 the behavior is the same but removing the driver after resume fully freezes the kernel. But with both Debian's 2.6.26 and official 2.6.28-rc9, if I remove the driver before suspending and reload if after, it works well. Regards, Colomban W.
Jeff did this go anywhere? I see a suggested patch at the URL below, though I cannot work out from the thread whether this was sensible nor whether it was enough? https://kerneltrap.org/mailarchive/linux-kernel/2008/8/5/2827954
This bug still hits me. Can't nvidia help? :(
I will take a look at this issue.
Can you send me the output of "lspci -xxx", "cat /proc/interrupts", "ethtool -d ethX" before (during working state) and after waking from sleep (during non-working state)?
(In reply to comment #13) > Can you send me the output of "lspci -xxx", "cat /proc/interrupts", "ethtool > -d > ethX" before (during working state) and after waking from sleep (during > non-working state)? Ok, I'll attach 2 files: before.txt and after.txt with the requested information.
Created attachment 20002 [details] Before (working state)
Created attachment 20003 [details] After (non-working state)
Could you please provide more data from the lspci command? It is only showing upto offset 0x3C. I would like to see upto offset 0xFC. Thanks.
Sorry Ayaz. I'm attaching the correct lspci output. I forgot to run it with sudo.
Created attachment 20007 [details] Correct lspci output (working state)
Created attachment 20008 [details] Correct lspci output (non-working state)
Created attachment 20010 [details] This is a test patch for msi issue during suspend/resume cycle. Please try out this patch to see if it resolves your issue.
(In reply to comment #21) > Created an attachment (id=20010) [details] > This is a test patch for msi issue during suspend/resume cycle. > > Please try out this patch to see if it resolves your issue. Bingo! It solved the problem! I'm changing this bug to FIXED. Thank you very much!
Well done! It seems to work perfectly for me too (tested by patching 2.6.28.3), thanks a lot :)
well it be cool if that fix would land upstream, didn't see it even yet in linux-next
(In reply to comment #21) > Created an attachment (id=20010) [details] > This is a test patch for msi issue during suspend/resume cycle. > > Please try out this patch to see if it resolves your issue. > Could you please send it to be merged in 2.6.30? I don't understand why this patch wasn't merged in 2.6.29 since it solves the issue.
(In reply to comment #21) > Created an attachment (id=20010) [details] > This is a test patch for msi issue during suspend/resume cycle. > > Please try out this patch to see if it resolves your issue. Well, I noticed that although this patch solves the issue on 2.6.28 and 2.6.29, on 2.6.29 it will make the connection stall after a while. So, the solution is in the patch, but it will introduce a new bug... :( It's getting complicated.
Forget my last message. The patch works fine with 2.6.29. So you can merge it in for 2.6.30.
My NIC is not working correctly after using this patch with the 2.6.29 kernel. It stalls after a short time (5~40 minutes) and it stalls faster if any kind of load is placed on it. This now occurs with both the patched and unpatched forcedeth module. It is also no longer detected/functional when trying to boot with the 2.6.27 or 2.6.28 kernel although the forcedeth module is being loaded. It was working fine all the way up through 2.6.28.8 using this patch. I have attached the lspci while working and the lspci after it stalls and I try to restart the network. Please help me, thank you.
Created attachment 20687 [details] working state
Created attachment 20688 [details] after stalled state
Created attachment 20689 [details] working state (plain text) changed to plain text
Created attachment 20690 [details] after stalled state (plain text) changed to plain text
Please ignore my previous posts and attachments. It looks like it was caused by the issue below and there is a patch that fixes it. Thanks for the previous patch, I hope it gets merged upstream. http://thread.gmane.org/gmane.linux.kernel/811167/focus=811417
This bug was fixed in 2.6.30-rc2, so I'm closing (CODE_FIX) this bug.
*** Bug 10800 has been marked as a duplicate of this bug. ***
*** Bug 11390 has been marked as a duplicate of this bug. ***