Bug 169616 - ACPI suspend/resume results in "no link" with 8139too
Summary: ACPI suspend/resume results in "no link" with 8139too
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 4
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: John W. Linville
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2005-09-30 10:27 UTC by James
Modified: 2007-11-30 22:11 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2005-10-20 15:09:09 UTC
Type: ---

Attachments (Terms of Use)
System log extract for 2.6.13-1.1526_FC4 session (39.07 KB, text/plain)
2005-09-30 10:31 UTC, James
no flags Details
jwltest-8139too-resume-hack.patch (679 bytes, patch)
2005-09-30 17:54 UTC, John W. Linville
no flags Details | Diff
jwltest-8139too-resume.patch (870 bytes, patch)
2005-10-04 20:01 UTC, John W. Linville
no flags Details | Diff

Description James 2005-09-30 10:27:14 UTC
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):

How reproducible:

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:

Comment 1 James 2005-09-30 10:31:37 UTC
Created attachment 119457 [details]
System log extract for 2.6.13-1.1526_FC4 session

Comment 2 John W. Linville 2005-09-30 17:54:20 UTC
Created attachment 119478 [details]

Comment 3 John W. Linville 2005-09-30 19:32:47 UTC
Test kernels w/ the above hack/patch available here: 
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! 

Comment 4 James 2005-09-30 20:18:45 UTC
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?

Comment 5 John W. Linville 2005-10-04 20:01:33 UTC
Created attachment 119623 [details]

This applies on top of the previous patch.  It seems davej like the first
(kludgey) one so much, he has already applied it... :-)

Comment 6 John W. Linville 2005-10-05 13:21:27 UTC
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! 

Comment 7 James 2005-10-06 08:02:27 UTC
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.)

Comment 8 John W. Linville 2005-10-20 15:09:09 UTC
I have posted this fix upstream.  It should filter into Fedora RSN... :-) 

Note You need to log in before you can comment on or make changes to this bug.