Bug 80356 - e100 fails selftest on warm boot and locks up
e100 fails selftest on warm boot and locks up
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Arjan van de Ven
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2002-12-24 17:24 EST by Pete Zaitcev
Modified: 2007-04-18 12:49 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-09-30 11:40:19 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Illustration which removes the symptom (745 bytes, patch)
2002-12-25 16:49 EST, Pete Zaitcev
no flags Details | Diff

  None (edit)
Description Pete Zaitcev 2002-12-24 17:24:51 EST
On my Sony Z505JE, after a warm reboot, e100 fails selftest
and locks up the box hard. The RH8.0 uses kernel 2.4.18-14 (updated)
with e100 2.1.24-k1. Marcelo tree 2.4.21-pre2 fails in the same way.

I observe that after a cold boot, BIOS initiates the chip,
the light on the hub is on. After a warm boot, it does not.
It stands to reason that either the PCI framework, or e100
do not perform a complete enough initialization.

Additional data:

Matt Galgoci has a laptop which exibits exactly the same symptom in RDU.

After a cold boot, BIOS initializes power state to D0, sets latency
timer to 66 decimal, cache line size to 32, and enables invalidate
(0x10 in command register). Kernel takes the chip from D3 to D0
in pci_enable_device. Setting the rest by hand in driver does not help.

I think that 7.3 with 2.4.9 ran properly on this laptop (with eepro100).
Last Marcelo tree to run properly was 2.4.18.

The lockup itself happens about 2 seconds after the start of self-test,
and it has nothing to do with interrupts or timers. NMI watchdog is not
available on this laptop (not even nmi_watchdog=2).
Comment 1 Arjan van de Ven 2002-12-25 05:30:56 EST
does eepro100 work ?
Comment 2 Pete Zaitcev 2002-12-25 15:57:51 EST
eepro100 works, naturally. It is not power management aware, so it
does not shut down the chip on reboot. I compared initialization
sequences between e100 and eepro100, and they are not significantly
different. With eepro100, sequence is:
 Power On
 BIOS initializes chip
 eepro100 loads
 eepro100 unloads, lets the chip initialized
 box reset, but BIOS does not do anything
 eepro100 loads
With e100:
 Power On
 BIOS initializes chip
 e100 loads
 e100 unloads and shuts the chip down
 box reset, but BIOS does not do anything
 e100 loads and cannot initialize the chip

Comment 3 Pete Zaitcev 2002-12-25 16:49:35 EST
Created attachment 88907 [details]
Illustration which removes the symptom
Comment 4 Pete Zaitcev 2002-12-25 16:52:49 EST
It seems that the stupid intelware does not want to jump from D3 to D0,
as the kernel tells it in pci_enable_device => pci_set_power_state(..., 0).
Comment 5 Bugzilla owner 2004-09-30 11:40:19 EDT
Thanks for the bug report. However, Red Hat no longer maintains this version of
the product. Please upgrade to the latest version and open a new bug if the problem

The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases, 
and if you believe this bug is interesting to them, please report the problem in
the bug tracker at: http://bugzilla.fedora.us/

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