Bug 176460
| Summary: | kernel 2.6.14-1.1777_FC5 made unbootable by ACPI | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Michal Jaegermann <michal> | ||||||
| Component: | kernel | Assignee: | Dave Jones <davej> | ||||||
| Status: | CLOSED RAWHIDE | QA Contact: | Brian Brock <bbrock> | ||||||
| Severity: | high | Docs Contact: | |||||||
| Priority: | medium | ||||||||
| Version: | rawhide | CC: | pfrields, wtogami | ||||||
| Target Milestone: | --- | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | All | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2005-12-23 18:36:50 UTC | Type: | --- | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Bug Depends On: | |||||||||
| Bug Blocks: | 165150 | ||||||||
| Attachments: |
|
||||||||
Created attachment 122549 [details]
dmesg output from the same machine and a bootable kernel
Created attachment 122550 [details]
dmesg output for 2.6.14-1.1777_FC5 with 'acpi=off'
should be fixed now (backed out acpi changes, and reported upstream). > 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. |
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