Description of problem:
Just got updates for a fresh install of f10 alpha, and the kernel
2.6.27-0.244.rc2.git1.fc10 that was installed by the update won't
boot. The boot process hangs right after printing info about
sd 6:0:0:0 (which I think is the extern USB drive). Just sits
there forever after that (though it does respond to Ctrl-Alt-Del).
Version-Release number of selected component (if applicable):
Every time I try to boot.
Steps to Reproduce:
1. see above
Hardware on this box described at:
Can you try the rc4 kernel at
Tried installing kernel-2.6.27-0.280.rc4.git4.fc10.x86_64.rpm
and I see the same hang.
System is not totally frozen, it merely appears to be waiting on something
which will never happen. It does reboot if I type Ctrl-Alt-Del, and even
logs a few messages after that as though it is shutting things down.
Paying closer attention, I notice what appears to be a kernel crash walkback
(or some kind of walkback anyway) zip past the screen early in the boot
process. Possibly some part of new init script system crashes which is what
I'm waiting on later? (I don't have the energy to get a serial console
hooked up to capture it :-).
Almost the first thing the kernel prints is:
PCI 0000:05:00.0: BAR3, can't allocate resource.
That may have something to do with the weird PCIE<->AGP bridge on this
motherboard, which might be relevant to the problem (random guess).
The last thing I see before the hang is messages about the external
USB disk, with the very last message being:
sd 6:0:0:0: Attached scsi generic sg3 type0
but I don't think that has much to do with it, since if I unplug the
disk and reboot, the last message then becomes the one from before
the sd 6 messages, this one about the intel8x0 sound chip:
intel8x0: clocking to 46866
So it is something that would happen after that which is hanging.
I'll attach the tail end of /var/log/messages and the /var/log/dmesg
file from the last attempt to boot (which I ended with Ctrl-Alt-Del
after letting it sit for a while doing nothing).
Created attachment 315057 [details]
/var/log/dmesg from the kernel that wouldn't boot
Created attachment 315058 [details]
tail of /var/log/messages from boot failure
Is there any way to add a kernel parameter or something to "single step"
the boot process? I have a feeling if I could go through the init one step
at a time, I'd be able to see exactly what crashes before the next
init items scroll it off the screen.
From the look of those logs, the kernel is done booting.
As for debugging the boot process after that.. umm, Bill?
I've watched the crash several times now, and it does get through the
nash init script, says "switching to new root and running init", then
says "starting udev", and right after the crash happens.
I've been trying to find where "starting udev" might get written, and
I've found there isn't an /etc/rc.d/init.d/udev script, but I haven't
found what is doing it instead of such a script :-).
That's from rc.sysinit; it implies that it's oopsing when loading a driver for your box. Booting with 'udevinfo' or 'udevdebug' may help.
Found my null modem cable, and used kermit to get a transcript of the boot.
Looks like the lirc_imon driver is what is killing it (I'll attach the boot
transcript). My HTPC case happens to include a IR remote that uses that
driver (but it works fine in fedora 9, no kernel oops).
When I rename the lirc_imon driver under /lib/modules, the boot proceeds
I also discovered that it isn't really hung forever. I was spending some time
examining the boot log I had accumulated, when I discovered the system
was up and finishing the boot process, so it merely hangs for a very long
Once the system was up, the kerneloops applet offered to send info about the
crash, and I said yes, so if that worked, there may be a report somewhere
out there to go with this bugzilla.
Created attachment 315159 [details]
transcript of boot from serial console
ah, that's helpful. thanks.
Jarod, can you take a look into this ?
Ew. I think I saw a similar-ish report of a system w/an imon failing to boot 2.6.26+ or 2.6.27 on the lirc list in the past few days, but there were no details. That driver *did* get a substantial update recently, I'll take a look at it. Wish I had an imon here to play with, would make it easier...
I'd be happy to send you mine, but it is manufactured in as part
of the case, so I don't think I can get it out :-). If you want me
to try swapping in a module with a gazillion printks added or
something like that, I can give it a whirl.
My suspicion is that the changes added for the lcd-based imon vs. the original vfd-based imon broke something. It *could* be some change in 2.6.27 vs. earlier kernels that is causing issues for some reason though, so first thing to try would be the latest 2.6.26.x F9 kernel to see if it fails the same way.
...has identical lirc_imon code as rawhide. If that still fails, we can start throwing in printk's and/or back out the lcd imon changes and see what we can see...
Two more things:
1) if you toss 'options lirc_imon debug=1', you should get some extra debug spew.
2) is your device possibly lcd-based?
Nope, no LCD on my remote. It is fairly old and came with my zalman
TNN 500AF case (http://home.att.net/~Tom.Horsley/zooty/zooty.html).
I'll try the new F9 kernel when I get home today.
Bad news I guess - the 188.8.131.52 kernel on F9 x86_64 seems to work
fine with the lirc_imon driver. I even ran my program to recognize
button pushes and it seems to give me good data from the lirc device.
Okay, we've done a ton of work on the lirc drivers in the past few days, including a fairly large update to lirc_imon... Nothing has been done specifically to address this issue, but there's a chance we've fixed things by some of the changes made... Can you try with a 2.6.27-rc5-git6 or later build?
Also hoping perhaps some usb interrupt handling changes that went in might have helped...
I'm afraid that didn't help. I see what appears to be the same
kernel backtrace and the same hang slightly later. This was using
the kernel/2.6.27/0.305.rc5.git6.fc10/ pointed at above.
Darn. Hrm, actually, I was incorrect, the latest lirc_imon bits aren't in that build, they're in git7 and later, which hasn't been built yet... However, I'm inclined to think the problem will persist, and what I really need to do is take a long hard look at the backtrace and the code.
Good news! I just installed latest rawhide with 2.6.27-0.314.rc5.git9.fc10.x86_64
and the lirc_imon driver not only doesn't hang, it even apparently works
(at least I seem to get IR data from the receiver).
Hey, awesome, we got lucky! :)
As it happens, I'm *just* about to submit the lirc patch series to lkml for hopeful upstream inclusion, so this is great news. If you don't mind, I'd like to add you to the lirc_imon portion with a Tested-by: line.
>If you don't mind, I'd like
>to add you to the lirc_imon portion with a Tested-by: line.
Sounds OK to me.