From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050524 Fedora/1.0.4-4 Firefox/1.0.4 Description of problem: The following is an extract (typed by hand) of what is seen when trying to boot hdc: lost_interrupt .... hdc: ATAPI 24X DVD-ROM drive, 512kb Cache UDMA(33) Uniform CD-ROM driver Revision 3.20 ... After booting, the following appears a couple of times. See lost interrupt and similar screen to below but not quite the same. This is the 3rd screen which comes up and stays up for longer (long enough to type). [<c0150b90>] __do_IRQ_0x1f7/0x347 [<c02c04cd>] cdrom_pc_intr+0x0/0x21a [<c0105b1d>] do_IRQ+0x4a/0x82 ======================= [<c0103c0e>] common_interrupt+0x1a/0x20 [<c02c04cd>] cdrom_pc_intr+0x0/0x21a [<c02b19be>] ide_timer_expiry+0x23f/0x518 [<c013a7a3>] rcu_check_quiescent_state+0x7d [<c02b177f>] ide_timer_expiry+0x0/0x518 [<c012cf53>] run_timer_softirq+0x01b/0x472 [<c013a8eb>] __rcu_process_callbacks+0x4e/0x1c4 [<c015ab35>] kmem_rcu_free+0x11/0x27 [<c01282ce>] __do_softirq+0x3e/0x8a [<c0105c29>] do_softirq+0x3e/0x42 ======================= [<c0105b24>] do_IRQ+0x51/0x82 [<c0103c0e>] common_interrupt+0x1a/0x20 [<c024a7ce>] acpi_processor_idle+0x10e/0x20 [<c01010a6>] cpu_idle+0x34/0x4c [<c042070a>] start_kernel+0x15d/0x1b7 [<c04202f7>] unknown_bootoption+0x0/0x1b6 handlers: [<c02b1d46>] (ide_intr+0x0/0x60e) Disabling IRQ #15 Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: boot with kernel > 2.6.12-1.1398_FC4 Actual Results: The system freezes up with the above text. Expected Results: Sucessful boot. Additional info: Currently kernel-2.6.11-1.1369_FC4 is fine, but all kernels since including the latest (kernel-2.6.12-1.1398_FC4) won't get past detecting the cdrom drive. This happens irrespective of whether there is a cdrom in the drive or not. I have also tried compiling the lastest kernels up to 2.6.13-rc4-git1 and still get the same problem.
Similiar thing happens on my Acer TravelMate 529ATX laptop. When I try to boot kernel-2.6.12-1.1398_FC4 or kernel-2.6.12-1.1447_FC4 then I get: Uncompressing Linux... Ok, booting the kernel. irq 15: nobody cared! handlers: [<c02b4236>] (ide_intr+0x0/0x60e) Disabling IRQ #15 (typed by hand extract of 1447 boot) kernel-2.6.11-1.1369_FC4 works fine. I haven't tested kernel-2.6.12-1.1390_FC4, so I don't know wheter it works on my laptop or not. There were some IRQ routing fixes in 1390 - maybe that's the cause of trouble?... And a short extract from lspci: 00:10.0 IDE interface: ALi Corporation M5229 IDE (rev c3) (prog-if fa) Subsystem: Acer Incorporated [ALI]: Unknown device 1010 Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 32 (500ns min, 1000ns max) Interrupt: pin A routed to IRQ 15 Region 4: I/O ports at 6050 [size=16] Capabilities: [60] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Please try booting with acpi=off to help debug this
Adding acpi=off helps in my case (Acer TravelMate 529ATX). Tested on both kernel-2.6.12-1.1447 and kernel-2.6.12-1.1398.
Adding acpi=off also allows the laptop to boot for me. However my pcmcia modem doesn't work with this option, so I tried acpi=noirq. This also allows me to boot OK, and my modem works as well. Tested with kernel 2.6.13-rc6-git11. Also, before trying acpi options I have tried deleting the ide-cdrom module, and managed to boot, capturing the first part of the stack trace I tried to copy out in the original bug report. This is attached. Before doing the tests above, I restored the ide-cdrom module.
Created attachment 118678 [details] dmesg of boot with ide-cdrom module deleted - boots ok. No specific acpi options were set. Shows some kind of stack trace of the interrupt getting lost. Hope this is helpful.
Mass update to all FC4 bugs: An update has been released (2.6.13-1.1526_FC4) which rebases to a new upstream kernel (2.6.13.2). As there were ~3500 changes upstream between this and the previous kernel, it's possible your bug has been fixed already. Please retest with this update, and update this bug if necessary. Thanks.
2.6.13-1.1532_FC4 still hangs during boot on my Acer laptop. "irqpoll" option that is mentioned in error message helps. It is better than acpi=off, because software power-off works.
Both kernel-2.6.13-1.1526_FC4.i686.rpm, and kernel-2.6.13-1.1532_FC4.i686.rpm still suffer the same problem. The work-around boot parameter acpi=noirq still works for me, so I have changed the severity to "normal". Also changed status back to assigned. Please advise if there is anything else we need to try to collect more info.
2.6.14-1.1637_FC4 has been released as an update for FC4. Please retest with this update, as a large amount of code has been changed in this release, which may have fixed your problem. Thank you.
The following packages still show the same behaviour: kernel-2.6.14-1.1637_FC4.i686.rpm kernel-2.6.14-1.1656_FC4.i686.rpm
This is a mass-update to all currently open kernel bugs. A new kernel update has been released (Version: 2.6.15-1.1830_FC4) based upon a new upstream kernel release. Please retest against this new kernel, as a large number of patches go into each upstream release, possibly including changes that may address this problem. This bug has been placed in NEEDINFO_REPORTER state. Due to the large volume of inactive bugs in bugzilla, if this bug is still in this state in two weeks time, it will be closed. Should this bug still be relevant after this period, the reporter can reopen the bug at any time. Any other users on the Cc: list of this bug can request that the bug be reopened by adding a comment to the bug. If this bug is a problem preventing you from installing the release this version is filed against, please see bug 169613. Thank you.
2.6.15-1.1830_FC4 Still has same problem.
Similar problem - hang at boot with lost interrupt for hdc (ide-cdrom) - occurs on Compaq DL360 with kernel-2.6.16-1.2069_FC4. The hang did not occur with kernel-2.6.13-1.1526_FC4, but interim kernels have not been tested. pci=noacpi option avoids the hang with kernel-2.6.16-1.2069_FC4.
[This comment added as part of a mass-update to all open FC4 kernel bugs] FC4 has now transitioned to the Fedora legacy project, which will continue to release security related updates for the kernel. As this bug is not security related, it is unlikely to be fixed in an update for FC4, and has been migrated to FC5. Please retest with Fedora Core 5. Thank you.
A new kernel update has been released (Version: 2.6.18-1.2200.fc5) based upon a new upstream kernel release. Please retest against this new kernel, as a large number of patches go into each upstream release, possibly including changes that may address this problem. This bug has been placed in NEEDINFO state. Due to the large volume of inactive bugs in bugzilla, if this bug is still in this state in two weeks time, it will be closed. Should this bug still be relevant after this period, the reporter can reopen the bug at any time. Any other users on the Cc: list of this bug can request that the bug be reopened by adding a comment to the bug. In the last few updates, some users upgrading from FC4->FC5 have reported that installing a kernel update has left their systems unbootable. If you have been affected by this problem please check you only have one version of device-mapper & lvm2 installed. See bug 207474 for further details. If this bug is a problem preventing you from installing the release this version is filed against, please see bug 169613. If this bug has been fixed, but you are now experiencing a different problem, please file a separate bug for the new problem. Thank you.
(this is a mass-close to kernel bugs in NEEDINFO state) As indicated previously there has been no update on the progress of this bug therefore I am closing it as INSUFFICIENT_DATA. Please re-open if the issue still occurs for you and I will try to assist in its resolution. Thank you for taking the time to report the initial bug. If you believe that this bug was closed in error, please feel free to reopen this bug.