Red Hat Bugzilla – Bug 50596
On Compaq Armada 1590T, after loading pnp at boot causes oops
Last modified: 2005-10-31 17:00:50 EST
I upgraded a laptop (Compaq Armada 1590T) from RHL71 to beta3. At boot, after 'isapnp' (ie. right in the beginning, when kernel is being loaded), the screen is filled with infinite, unstoppable kernel oops.
This defect is considered MUST-FIX for Fairfax
Additional note: not 100% sure whether this is isapnp or what, but appending noisapnp to kernel boot line in grub didn't fix it at least.
Actually this might be a BIOS/APM problem: boot: linux console=ttyS0,38400 Loading linux...................... Linux version 2.4.6-3.1 (bhcompile@stripples.devel.redhat.com) (gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-94)) #1 Tue Jul 24 16:03:09 EDT 2001 BIOS-provided physical RAM map: BIOS-e801: 0000000000000000 - 000000000009f000 (usable) BIOS-e801: 0000000000100000 - 0000000005000000 (usable) On node 0 totalpages: 20480 zone(0): 4096 pages. zone(1): 16384 pages. zone(2): 0 pages. Kernel command line: BOOT_IMAGE=linux ro root=302 BOOT_FILE=/boot/vmlinuz-2.4.6-3.1 console=ttyS0,38400 console=tty0 console=ttyS0,38400 Initializing CPU#0 Detected 163.998 MHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 326.86 BogoMIPS Memory: 77148k/81920k available (1523k kernel code, 3868k reserved, 90k data, 224k init, 0k highmem) Dentry-cache hash table entries: 16384 (order: 5, 131072 bytes) Inode-cache hash table entries: 8192 (order: 4, 65536 bytes) Mount-cache hash table entries: 2048 (order: 2, 16384 bytes) Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes) Page-cache hash table entries: 32768 (order: 6, 262144 bytes) Intel Pentium with F0 0F bug - workaround enabled. Intel old style machine check architecture supported. Intel old style machine check reporting enabled on CPU#0. CPU: Intel Pentium MMX stepping 03Intel old style machine check reporting enabled on CPU#0. CPU: Intel Pentium MMX stepping 03 Checking 'hlt' instruction... OK. Checking for popad bug... OK. POSIX conformance testing by UNIFIX mtrr: v1.40 (20010327) Richard Gooch (rgooch@atnf.csiro.au) mtrr: detected mtrr type: none PCI: PCI BIOS revision 2.10 entry at 0xf73a9, last bus=0 PCI: Using configuration type 1 PCI: Probing PCI hardware PCI: Using IRQ router OPTI [1045/c700] at 00:01.0 isapnp: Scanning for PnP cards... isapnp: No Plug & Play device found PnP: PNP BIOS installation structure at 0xc00fe2d0 PnP: PNP BIOS version 1.0, entry at f0000:95af, dseg at f0000 Unable to handle kernel paging request at virtual address 00007eef printing eip: 00002e72 *pde = 00000000 Oops: 0002 CPU: 0 EIP: 0068:[<00002e72>] EFLAGS: 00010046 eax: 000000c0 ebx: 00000002 ecx: 00020000 edx: 000000e4 esi: 00002aef edi: c02800e5 ebp: c11d7ef0 esp: c11d7eea ds: 0080 es: 0080 ss: 0018 Process swapper (pid: 1, stackpage=c11d7000) Stack: 00002aef 00260000 002e984e 2f680070 2aef0000 7f0a002e 00e50002 00e40000 00000070 7f3c984e 2b870070 024696a7 02069608 00180018 df680018 0001c028 00700000 00800000 00010002 00780000 e0000000 000b0008 00010060 00780000 Call Trace: [<df680018>] [<e0000000>] [<df680000>] [<e000c028>] [<e2d000fa>] [<e000c010>] [<c6820009>] [<d76b819b>] [<f6f876fe>] [<ccb987cf>] [<ecbcb286>] [<db678c04>] [<ce337d58>] [<f1caa06f>] [<e89f3dc2>] [<d5b83dda>] [<d8dcca53>] [<e246d9bd>] [<d61e2aac>] [<e2ca73f7>] [<f1f80a74>] [<c8a7c178>] [<d2b36cca>] [<e299f6a5>] [<e271cdb2>] [<e331f1ee>] [<ee331246>] [<cbda51f1>] [<e41d4297>] [snip] Unfortunately, I can't ksymoops this on this system (can't boot into the the kernel in question), and running the trace with same kernel on different box doesn't give too good results: >>EIP; 00002e72 Before first symbol <===== Trace; df680018 <END_OF_CODE+1ade65b8/????> Trace; e0000000 <END_OF_CODE+1b7665a0/????> Trace; df680000 <END_OF_CODE+1ade65a0/????> Trace; e000c028 <END_OF_CODE+1b7725c8/????> Trace; e2d000fa <END_OF_CODE+1e46669a/????> Trace; e000c010 <END_OF_CODE+1b7725b0/????> Trace; c6820009 <END_OF_CODE+1f865a9/????> Trace; d76b819b <END_OF_CODE+12e1e73b/????> Trace; f6f876fe <END_OF_CODE+326edc9e/????> but hopefully this is enough to trace this...
Bios bug indeed. We still shouldn't crash though I'll look into that. Also, would you be so kind to run the http://people.redhat.com/arjanv/dmidecode.c program as root and mail the output to hardwarebugs-list@redhat.com with a subject similar to "broken PNPBIOS" so we can add it to the "no PNP" list.
Umm? Only output I get (in linux rescue mode) is: "PNP Bios present." Not very informative in itself, I'd suspect. But if you want it, sure I can email it. :-) (Btw, bios update 08/31/98 -> 06/10/99 (the latest) didn't fix this)
Should be fixed in more recent builds
Confirm as fixed in 2.4.7-2.