Red Hat Bugzilla – Bug 169616
ACPI suspend/resume results in "no link" with 8139too
Last modified: 2007-11-30 17:11:14 EST
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050922 Fedora/1.0.7-1.1.fc4 Firefox/1.0.7 Description of problem: ACPI suspend-to-RAM/resume cycle breaks RealTek 8139 support with the 8139too driver. The driver is still loaded and can be reloaded, but it seems like the tranceiver isn't powered back up. The kernel logs then report "no link", and the interface cannot connect. Recovery requires powering the whole machine down, and then starting up again. This problem is not present in kernel 2.6.12-1398. Version-Release number of selected component (if applicable): kernel-2.6.13-1.1526_FC4 How reproducible: Always Steps to Reproduce: 1. Suspend to RAM. 2. Resume. 3. Attempt to bring up eth0. Actual Results: "no link" messages in the kernel log. No ethernet connectivity. Expected Results: RealTek card is fully powered up and can reconnect. Additional info:
Created attachment 119457 [details] System log extract for 2.6.13-1.1526_FC4 session
Created attachment 119478 [details] jwltest-8139too-resume-hack.patch
Test kernels w/ the above hack/patch available here: http://people.redhat.com/linville/kernels/fc4/ Please give them a try and post the results...thanks! P.S. If they work, please attach the output of "lspci -n". If they don't work, please attach the output of "sysreport"...thanks!
I've tried kernel-2.6.13-1.1526_FC4.jwltest.18.i686, and things appear to be working now. (By the way... "older" card? I got this notebook a month ago! ;) It's identified in dmesg as a RTL-8100B/8139D.) $ /sbin/lspci -n 00:00.0 Class 0600: 8086:3580 (rev 02) 00:00.1 Class 0880: 8086:3584 (rev 02) 00:00.3 Class 0880: 8086:3585 (rev 02) 00:02.0 Class 0300: 8086:3582 (rev 02) 00:02.1 Class 0380: 8086:3582 (rev 02) 00:1d.0 Class 0c03: 8086:24c2 (rev 03) 00:1d.1 Class 0c03: 8086:24c4 (rev 03) 00:1d.2 Class 0c03: 8086:24c7 (rev 03) 00:1d.7 Class 0c03: 8086:24cd (rev 03) 00:1e.0 Class 0604: 8086:2448 (rev 83) 00:1f.0 Class 0601: 8086:24cc (rev 03) 00:1f.1 Class 0101: 8086:24ca (rev 03) 00:1f.3 Class 0c05: 8086:24c3 (rev 03) 00:1f.5 Class 0401: 8086:24c5 (rev 03) 00:1f.6 Class 0703: 8086:24c6 (rev 03) 01:01.0 Class 0280: 8086:4220 (rev 05) 01:02.0 Class 0200: 10ec:8139 (rev 10) 01:04.0 Class 0607: 104c:ac50 (rev 02) 01:05.0 Class 0c00: 1106:3044 (rev 80) Although I'm no kernel hacker, I check the source of a working kernel and notice that the call to RTL_W8() was originally in rtl8139_hw_start(). Was there any particular reason for this?
Created attachment 119623 [details] jwltest-8139too-resume.patch This applies on top of the previous patch. It seems davej like the first (kludgey) one so much, he has already applied it... :-)
Test kernels with the above patch are available at the same location as in comment 3. Please give them a try and post the results here...thanks!
I've just tried a kernel built from your 2.6.13-1.1528_FC4.jwltest.19 sources, and 8139too suspend/resume still appears to be working OK. (Sorry for delay, had to do a rebuild because I need the NTFS read module.)
I have posted this fix upstream. It should filter into Fedora RSN... :-)