Bug 42650 - epic100 module does not restore ACPI power state
epic100 module does not restore ACPI power state
Status: CLOSED ERRATA
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
7.1
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Arjan van de Ven
Brock Organ
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-05-28 22:02 EDT by James Ralston
Modified: 2007-04-18 12:33 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-05-28 22:02:50 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description James Ralston 2001-05-28 22:02:46 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.2-2 i686; en-US; rv:0.9)
Gecko/20010507

Description of problem:
I have a dual-boot Linux/Windows machine with a SMC EtherPower II (EPIC/100
83c170) network card.  When rebooting from Windows, the Windows driver will
leave the card in the ACPI D3 state.

The epic100.o module that ships with Red Hat Linux 7.1 does not know how to
restore the ACPI power state of the card.  Therefore, if I have booted my
machine into Windows, in order to boot into Linux, I must first completely
power off my machine and power it back on.


How reproducible:
Always

Steps to Reproduce:
1.  Build a dual-boot Windows 98 / Red Hat Linux 7.1 system with a SMC
EtherPower II (EPIC/100 83c170) network card.
2.  Boot the system into Windows.
3.  From Windows, reboot into Linux.


Actual Results:

May 25 15:17:35 myhost kernel: epic100.c:v1.11 1/7/2001 Written by Donald
Becker <becker@scyld.com>
May 25 15:17:35 myhost kernel:   http://www.scyld.com/network/epic100.html
May 25 15:17:35 myhost kernel:  (unofficial 2.4.x kernel port, version
1.1.6, January 11, 2001)
May 25 15:17:35 myhost kernel: PCI: Enabling device 00:09.0 (0010 -> 0013)
May 25 15:17:35 myhost kernel: PCI: Found IRQ 5 for device 00:09.0
May 25 15:17:35 myhost kernel: PCI: The same IRQ used for device 00:04.2
May 25 15:17:35 myhost kernel: PCI: The same IRQ used for device 00:04.3
May 25 15:17:35 myhost kernel: PCI: The same IRQ used for device 00:0d.0
May 25 15:17:35 myhost kernel: eth0: SMSC EPIC/100 83c170 at 0xd08be000,
IRQ 5, ff:ff:ff:ff:ff:ff.
May 25 15:17:35 myhost kernel: eth0: ***WARNING***: No MII transceiver found!
May 25 15:17:54 myhost kernel: NETDEV WATCHDOG: eth0: transmit timed out
May 25 15:17:54 myhost kernel: eth0: Transmit timeout using MII device, Tx
status ffff.
May 25 15:17:58 myhost kernel: NETDEV WATCHDOG: eth0: transmit timed out
May 25 15:17:58 myhost kernel: eth0: Transmit timeout using MII device, Tx
status ffff.
May 25 15:18:02 myhost kernel: NETDEV WATCHDOG: eth0: transmit timed out
May 25 15:18:02 myhost kernel: eth0: Transmit timeout using MII device, Tx
status ffff.
May 25 15:18:06 myhost kernel: NETDEV WATCHDOG: eth0: transmit timed out
May 25 15:18:06 myhost kernel: eth0: Transmit timeout using MII device, Tx
status ffff.
May 25 15:18:10 myhost kernel: NETDEV WATCHDOG: eth0: transmit timed out
May 25 15:18:10 myhost kernel: eth0: Transmit timeout using MII device, Tx
status ffff.
May 25 15:18:14 myhost kernel: NETDEV WATCHDOG: eth0: transmit timed out
May 25 15:18:14 myhost kernel: eth0: Transmit timeout using MII device, Tx
status ffff.
May 25 15:18:18 myhost kernel: NETDEV WATCHDOG: eth0: transmit timed out
May 25 15:18:18 myhost kernel: eth0: Transmit timeout using MII device, Tx
status ffff.
[repeat ad infinitum]


Expected Results:

May 28 18:54:51 myhost kernel: epic100.c:v1.11 1/7/2001 Written by Donald
Becker <becker@scyld.com>
May 28 18:54:51 myhost kernel:   http://www.scyld.com/network/epic100.html
May 28 18:54:51 myhost kernel:  (unofficial 2.4.x kernel port, version
1.1.6, January 11, 2001)
May 28 18:54:51 myhost kernel: PCI: Found IRQ 5 for device 00:09.0
May 28 18:54:51 myhost kernel: PCI: The same IRQ used for device 00:04.2
May 28 18:54:51 myhost kernel: PCI: The same IRQ used for device 00:04.3
May 28 18:54:51 myhost kernel: PCI: The same IRQ used for device 00:0d.0
May 28 18:54:51 myhost kernel: eth0: SMSC EPIC/100 83c170 at 0xd08be000,
IRQ 5, 00:e0:29:75:32:17.
May 28 18:54:51 myhost kernel: eth0: MII transceiver #3 control 3000 status
7849.
May 28 18:54:52 myhost kernel: eth0: Autonegotiation advertising 01e1 link
partner 0001.
May 28 18:54:53 myhost kernel: eth0: Setting full-duplex based on MII #3
link partner capability of 45e1.


Additional info:

I've already encountered this problem under RH7.0 (kernel 2.2):

http://www.scyld.com/pipermail/epic-bug/2000-November/000000.html

The way I resolved the problem then was to move to using Becker's network
driver updates:

http://www.scyld.com/network/updates.html

But I can't do this for RH7.1 (kernel 2.4) because he hasn't yet ported his
epic100 to the 2.4 kernel.  I need a epic100.c that both works for kernel
2.4 *and* knows how to restore the ACPI power state of the card.
Comment 1 James Ralston 2002-01-02 18:04:20 EST
I don't know whether it was intentional or not, but this problem was corrected
in either the first or second kernel errata release that came out after I
submitted the bug report.

I've been warm-booting between Windows 98 SE and Red Hat for months now, under
both 7.1 and 7.2, and haven't run into the problem again.  Therefore, I'm
closing this bug with ERRATA as the status.

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