From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0; DigExt)
Description of problem:
Kernel oops occurs during installation of Fairfax Beta 2. While loading
modules, system gives kernel oops loading the e1000 module.
Occurs on cdrom and nfs install. System is a Dell 2550 with an add-in
Intel Pro 1000. Pulled out card and system installed correctly.
Steps to Reproduce:
1. Install system with Intel Pro 1000
2. Start cdrom or bootnet install
3. System will oops
Actual Results: Kernel oops
Expected Results: No oops
Created attachment 24348 [details]
Text of oops
Created attachment 24349 [details]
Re-assigning to kernel.
I wonder if this is fixed in the updated e1000 driver that is in 2.4.6-2.3 and
This defect considered MUST-FIX for Fairfax.
really assigning to kernel
Problem appears to be happening only on the Dell PE 2550. Installing card after
OS installation works correctly; only install kernel has issue. Problem still
exists with Beta 3
I tried this on a PE 6450. Card works fine after installation, but attempting
to install with latest Rawhide fails. Anaconda seems to think the card is an
eepro and loads the eepro driver rather than the e1000.
Bob: any chance of getting "lspci" and "lspci -n" outputs ?
My mistake - the 6450 has an eepro on the motherboard which Anaconda was
detecting. It looks like the boot kernel is not seeing the e1000 card at all.
00:00.0 Host bridge: ServerWorks CNB20HE (rev 21)
00:00.1 Host bridge: ServerWorks CNB20HE (rev 01)
00:00.2 Host bridge: ServerWorks: Unknown device 0006
00:00.3 Host bridge: ServerWorks: Unknown device 0006
00:04.0 VGA compatible controller: ATI Technologies Inc 3D Rage IIC (rev 7a)
00:07.0 Ethernet controller: Intel Corporation 82557 [Ethernet Pro 100] (rev 08)
00:08.0 Ethernet controller: Intel Corporation 82557 [Ethernet Pro 100] (rev 08)
00:0f.0 ISA bridge: ServerWorks OSB4 (rev 4f)
00:0f.1 IDE interface: ServerWorks: Unknown device 0211
00:0f.2 USB Controller: ServerWorks: Unknown device 0220 (rev 04)
0c:0c.0 Ethernet controller: Intel Corporation 82542 Gigabit Ethernet Adapter
0c:0d.0 SCSI storage controller: Adaptec 7892A (rev 02)
# lspci -n
00:00.0 Class 0600: 1166:0008 (rev 21)
00:00.1 Class 0600: 1166:0008 (rev 01)
00:00.2 Class 0600: 1166:0006
00:00.3 Class 0600: 1166:0006
00:04.0 Class 0300: 1002:4759 (rev 7a)
00:07.0 Class 0200: 8086:1229 (rev 08)
00:08.0 Class 0200: 8086:1229 (rev 08)
00:0f.0 Class 0601: 1166:0200 (rev 4f)
00:0f.1 Class 0101: 1166:0211
00:0f.2 Class 0c03: 1166:0220 (rev 04)
0c:0c.0 Class 0200: 8086:1000 (rev 03)
0c:0d.0 Class 0100: 9005:0080 (rev 02)
Ok, got the right driver disk. Anaconda sees the card and selects the correct
module, but the module fails to load. No oops though.
Bug reported to Intel (Walker, Timothy E [firstname.lastname@example.org]) on 10
August 2001. Tim said he'd pass this on for investigation by the appropriate
Intel suggests making HardwareVirtualAddress volatile.
It should be volatile anyway; they think that there may possibly
also be a compiler bug involved here and we are investigating to
see whether this is correct.
The change will be in 2.4.7-2.6 or later.
Kernel bug (lacking volatile) fixed, and there's another bug report
open to track the possible compiler bug.