|Summary:||NIC (forcedeth) doesn't work with suspend (S3)|
|Product:||Drivers||Reporter:||Dâniel Fraga (fragabr)|
|Component:||Network||Assignee:||Jeff Garzik (jgarzik)|
|Severity:||high||CC:||aabdulla, aros, ban-ubuntu, bunk, cosoleto, cyan.spam, rjw|
|Bug Depends on:|
Before (working state)
After (non-working state)
Correct lspci output (working state)
Correct lspci output (non-working state)
This is a test patch for msi issue during suspend/resume cycle.
after stalled state
working state (plain text)
after stalled state (plain text)
Description Dâniel Fraga 2008-04-20 00:06:06 UTC
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
Comment 1 Anonymous Emailer 2008-04-20 15:21:21 UTC
Reply-To: email@example.com (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) firstname.lastname@example.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: email@example.com > ReportedBy: firstname.lastname@example.org > > > 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 > >
Comment 2 Dâniel Fraga 2008-04-20 16:16:29 UTC
On Sun, 20 Apr 2008 15:21:35 -0700 Andrew Morton <email@example.com> 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.
Comment 3 Francesco Cosoleto 2008-08-04 09:48:00 UTC
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.
Comment 4 Francesco Cosoleto 2008-08-21 16:36:32 UTC
Fixed in 2.6.27-rc4.
Comment 5 Dâniel Fraga 2008-10-07 22:02:19 UTC
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".
Comment 6 Dâniel Fraga 2008-10-27 13:36:31 UTC
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".
Comment 7 Francesco Cosoleto 2008-11-20 01:07:08 UTC
Does "modprobe -r forcedeth ; modprobe forcedeth" as root works?
Comment 8 Dâniel Fraga 2008-11-20 20:07:46 UTC
(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.
Comment 9 Colomban Wendling 2008-12-27 13:34:23 UTC
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.
Comment 10 Andy Whitcroft 2009-01-22 11:36:07 UTC
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
Comment 11 Dâniel Fraga 2009-01-22 12:37:33 UTC
This bug still hits me. Can't nvidia help? :(
Comment 12 Ayaz Abdulla 2009-01-26 13:23:15 UTC
I will take a look at this issue.
Comment 13 Ayaz Abdulla 2009-01-26 13:41:05 UTC
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)?
Comment 14 Dâniel Fraga 2009-01-26 15:13:15 UTC
(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.
Comment 15 Dâniel Fraga 2009-01-26 15:14:04 UTC
Created attachment 20002 [details] Before (working state)
Comment 16 Dâniel Fraga 2009-01-26 15:14:39 UTC
Created attachment 20003 [details] After (non-working state)
Comment 17 Ayaz Abdulla 2009-01-26 16:56:09 UTC
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.
Comment 18 Dâniel Fraga 2009-01-27 05:31:44 UTC
Sorry Ayaz. I'm attaching the correct lspci output. I forgot to run it with sudo.
Comment 19 Dâniel Fraga 2009-01-27 05:32:31 UTC
Created attachment 20007 [details] Correct lspci output (working state)
Comment 20 Dâniel Fraga 2009-01-27 05:32:59 UTC
Created attachment 20008 [details] Correct lspci output (non-working state)
Comment 21 Ayaz Abdulla 2009-01-27 10:50:49 UTC
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.
Comment 22 Dâniel Fraga 2009-01-27 11:38:21 UTC
(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!
Comment 23 Colomban Wendling 2009-02-06 07:20:50 UTC
Well done! It seems to work perfectly for me too (tested by patching 18.104.22.168), thanks a lot :)
Comment 24 maximilian attems 2009-03-09 06:30:04 UTC
well it be cool if that fix would land upstream, didn't see it even yet in linux-next
Comment 25 Dâniel Fraga 2009-03-24 01:27:24 UTC
(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.
Comment 26 Dâniel Fraga 2009-03-24 10:27:45 UTC
(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.
Comment 27 Dâniel Fraga 2009-03-24 10:53:59 UTC
Forget my last message. The patch works fine with 2.6.29. So you can merge it in for 2.6.30.
Comment 28 eth0problem 2009-03-26 16:33:13 UTC
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 22.214.171.124 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.
Comment 30 eth0problem 2009-03-26 16:34:23 UTC
Created attachment 20688 [details] after stalled state
Comment 31 eth0problem 2009-03-26 16:37:45 UTC
Created attachment 20689 [details] working state (plain text) changed to plain text
Comment 32 eth0problem 2009-03-26 16:38:27 UTC
Created attachment 20690 [details] after stalled state (plain text) changed to plain text
Comment 33 eth0problem 2009-03-26 22:20:28 UTC
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
Comment 34 Dâniel Fraga 2009-04-15 06:42:10 UTC
This bug was fixed in 2.6.30-rc2, so I'm closing (CODE_FIX) this bug.
Comment 35 Artem S. Tashkinov 2009-04-21 17:03:08 UTC
*** Bug 10800 has been marked as a duplicate of this bug. ***