Bug 176460 - kernel 2.6.14-1.1777_FC5 made unbootable by ACPI
kernel 2.6.14-1.1777_FC5 made unbootable by ACPI
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
All Linux
medium Severity high
: ---
: ---
Assigned To: Dave Jones
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2005-12-22 21:07 EST by Michal Jaegermann
Modified: 2015-01-04 17:23 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-12-23 13:36:50 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
dmesg output from the same machine and a bootable kernel (14.69 KB, text/plain)
2005-12-22 21:08 EST, Michal Jaegermann
no flags Details
dmesg output for 2.6.14-1.1777_FC5 with 'acpi=off' (12.71 KB, text/plain)
2005-12-22 21:10 EST, Michal Jaegermann
no flags Details

  None (edit)
Description Michal Jaegermann 2005-12-22 21:07:11 EST
Description of problem:

An attempt to boot 2.6.14-1.1777_FC5 generates oops and kernel wedges trying
to identify disk devices.  Opps is pretty extensive and nothing really works
yet beyond a screen output so it is hard to record traces.  Here is what
I retyped from a screen lines which seem to be the most relevant.

ACPI: PCI Interrupt 0000:00:0f.0[B] -> GSI 20 (level, low) -> IRQ 0
PCI: Via IRQ fixup for 0000:00:0f.0, from 5 to 0
sata_via 0000:00:0f.0: routed to hard irq line 0
ata1: SATA max UDMA/133 cms 0xE800 ctl 0xE402 bmdma 0xD400 irq 0
ata2: SATA max UDMA/133 cms 0xE000 ctl 0xD802 bmdma 0xD408 irq 0
Unable to handle kernel NULL pointer dereference at 0000000000000000 RIP:
PGD 1f674067 PUD 1f699067 PMD 0
Oops: 0000 [1] SMP
last sysfs file: /block/ram0/dev
Modules linked in: sata_vi libata sd_mod scsi_mod
Pid: 337, comm: insmod Not tainted 2.6.14-1.1777_FC5 #1
RIP: 0010:[<ffffffff802742c5>] <ffffffff802742c5>{make_class_name+27}
Process insmod (pid: 337, threadinfo fff81f6300000, fast fff81001fadb110)
Call Trace:>ffffffff8027454a>{class_device_devl+187}
.... (really long trace here which ends with ...)

Code: f2 ae 48 89 ca 48 f7 d2 48 8b 45 60 48 8b 38 48 89 ff1 44 89
RIP <ffffffff802742c5>{make_class_name+27} RSP <ffff81001f631ad8>
CR2: 0000000000000000
sd 2:0:0:0: Attached scsi disk sda
  Vendor: ATA ....
sd 3:0:0:0: Attached scsi disk sda

(at this point a machine is dead but a reset button still works).

Note an interrupt routing to IRQ 0.  In the last working kernel, which
on this machine happens to be 2.6.14-1.1773_FC5, the corresponding line
looks like this:

ACPI: PCI Interrupt 0000:00:0f.0[B] -> GSI 20 (level, low) -> IRQ 169

and there are no problems in accessing drives.  As a matter of fact this
bug seems to be related to bug #176284 only results are considerably more
dramatic.  This impression is also supported by this detail that adding
'acpi=off' to a boot command allows to boot (and networking then happens
to work too).

dmesg output for a working kernel and for 1777 with acpi off is attached.

Version-Release number of selected component (if applicable):
kernel 2.6.14-1.1777_FC5

How reproducible:
Comment 1 Michal Jaegermann 2005-12-22 21:08:47 EST
Created attachment 122549 [details]
dmesg output from the same machine and a bootable kernel
Comment 2 Michal Jaegermann 2005-12-22 21:10:45 EST
Created attachment 122550 [details]
dmesg output for 2.6.14-1.1777_FC5 with 'acpi=off'
Comment 3 Dave Jones 2005-12-23 13:36:50 EST
should be fixed now (backed out acpi changes, and reported upstream).
Comment 4 Michal Jaegermann 2005-12-23 15:48:47 EST
> should be fixed now
Indeed.  I am booting 2.6.14-1.1783_FC5 again without using 'acpi=off'.
Also networking problems as described in bug #176284 disappeared. Not a very
big surprise.  Thanks.

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