Bug 176460 - kernel 2.6.14-1.1777_FC5 made unbootable by ACPI
Summary: kernel 2.6.14-1.1777_FC5 made unbootable by ACPI
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: rawhide
Hardware: All
OS: Linux
medium
high
Target Milestone: ---
Assignee: Dave Jones
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks: FCMETA_ACPI
TreeView+ depends on / blocked
 
Reported: 2005-12-23 02:07 UTC by Michal Jaegermann
Modified: 2015-01-04 22:23 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-12-23 18:36:50 UTC
Type: ---


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

Description Michal Jaegermann 2005-12-23 02:07:11 UTC
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:
<ffffffff802742c5>{make_class_name+27}
PGD 1f674067 PUD 1f699067 PMD 0
Oops: 0000 [1] SMP
last sysfs file: /block/ram0/dev
CPU 0
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 ...)
<ffffffff80154acd>{sys_init_module+278}
<ffffffff8010f8ca>{system_call+126}

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:
always

Comment 1 Michal Jaegermann 2005-12-23 02:08:47 UTC
Created attachment 122549 [details]
dmesg output from the same machine and a bootable kernel

Comment 2 Michal Jaegermann 2005-12-23 02:10:45 UTC
Created attachment 122550 [details]
dmesg output for 2.6.14-1.1777_FC5 with 'acpi=off'

Comment 3 Dave Jones 2005-12-23 18:36:50 UTC
should be fixed now (backed out acpi changes, and reported upstream).


Comment 4 Michal Jaegermann 2005-12-23 20:48:47 UTC
> 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.