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).
does eepro100 work ?
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
Created attachment 88907 [details] Illustration which removes the symptom
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).
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/