Bug 80356

Summary: e100 fails selftest on warm boot and locks up
Product: [Retired] Red Hat Linux Reporter: Pete Zaitcev <zaitcev>
Component: kernelAssignee: Arjan van de Ven <arjanv>
Status: CLOSED WONTFIX QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 8.0   
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-09-30 15:40:19 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Illustration which removes the symptom none

Description Pete Zaitcev 2002-12-24 22:24:51 UTC 
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 10:30:56 UTC 
does eepro100 work ?
Comment 2 Pete Zaitcev 2002-12-25 20:57:51 UTC 
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
 reboot
 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
 reboot
 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 21:49:35 UTC 
Created attachment 88907 [details]
Illustration which removes the symptom
Comment 4 Pete Zaitcev 2002-12-25 21:52:49 UTC 
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 15:40:19 UTC 
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
persists.

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/