Bug 49571 - Kernel oops in anaconda during install when loading e1000 omdule
Summary: Kernel oops in anaconda during install when loading e1000 omdule
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel
Version: 7.3
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Michael K. Johnson
QA Contact: Brock Organ
Depends On:
TreeView+ depends on / blocked
Reported: 2001-07-20 19:29 UTC by John A. Hull
Modified: 2007-04-18 16:34 UTC (History)
6 users (show)

Clone Of:
Last Closed: 2001-08-22 07:35:49 UTC

Attachments (Terms of Use)
Text of oops (794 bytes, text/plain)
2001-07-20 19:30 UTC, John A. Hull
no flags Details
ksymoops output (7.42 KB, text/plain)
2001-07-20 19:31 UTC, John A. Hull
no flags Details

Description John A. Hull 2001-07-20 19:29:44 UTC
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.

How reproducible:

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

Additional info:

Comment 1 John A. Hull 2001-07-20 19:30:31 UTC
Created attachment 24348 [details]
Text of oops

Comment 2 John A. Hull 2001-07-20 19:31:09 UTC
Created attachment 24349 [details]
ksymoops output

Comment 3 Glen Foster 2001-07-20 19:49:35 UTC
Re-assigning to kernel.

Comment 4 Arjan van de Ven 2001-07-20 19:53:12 UTC
I wonder if this is fixed in the updated e1000 driver that is in 2.4.6-2.3 and 

Comment 5 Glen Foster 2001-07-20 19:57:13 UTC
This defect considered MUST-FIX for Fairfax.

Comment 6 Matt Wilson 2001-07-20 21:28:53 UTC
really assigning to kernel

Comment 7 John A. Hull 2001-07-31 16:29:29 UTC
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

Comment 8 Bob Matthews 2001-08-09 19:41:15 UTC
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.

Comment 9 Arjan van de Ven 2001-08-09 19:45:31 UTC
Bob: any chance of getting "lspci" and "lspci -n" outputs ?

Comment 10 Bob Matthews 2001-08-09 20:25:30 UTC
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.

# lspci
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
(rev 03)
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)

Comment 11 Bob Matthews 2001-08-09 21:17:46 UTC
Ok, got the right driver disk.  Anaconda sees the card and selects the correct
module, but the module fails to load.  No oops though.

Comment 12 Matt Domsch 2001-08-10 18:05:04 UTC
Bug reported to Intel (Walker, Timothy E [timothy.e.walker@intel.com]) on 10 
August 2001.  Tim said he'd pass this on for investigation by the appropriate 
driver team.

Comment 13 Michael K. Johnson 2001-08-20 18:35:49 UTC
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.

Comment 14 Michael K. Johnson 2001-08-24 14:37:45 UTC
Kernel bug (lacking volatile) fixed, and there's another bug report
open to track the possible compiler bug.

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