Red Hat Bugzilla – Bug 168026
kernel panic on boot with kernel-smp-2.6.13-1.1547_FC5
Last modified: 2015-01-04 17:22:02 EST
Description of problem:
panic on boot.
Version-Release number of selected component (if applicable):
kernel-smp-2.6.13-1.1547_FC5 doesn't boot
Attached is a screenshot of the panic message
Please let me know if you need any additional information
Created attachment 118686 [details]
screenshot of kernel panic on boot
can you boot with vga=791 and try again. This will get more lines of text on the
console, so we can see the top of that message.
Created attachment 118703 [details]
boot with vga=791
my camera doesn't seem to want to focus very well on the monitor. If this
isn't legible I can try again tomorrow night.
hmm, can just about make out 5a5a5a5a in the registers, which is using memory
after its been freed. There was a bug fixed today in the IO scheduler that may
be the cause of this. You can try booting with a different one (boot with
elevator=as to try this).
That fix got checked in this afternoon, so will end up in tomorrows -git tree,
and thus, Tuesdays rawhide kernel.
If this is a different bug, a better screen shot would be appreciated :)
booting with elevator=as didnt help at all... it was a different traceback.
I'm going to have to try to get some different lighting at the moniter the
autofocus isnt working very well. I can't get anything readable with the camera
at the moment. I'll try to get a better image and report back.
Still getting panics...even with kernel-smp-2.6.13-1.1553_FC5 from today's
rawhide. The panic is happening right after the
"Initializing hardware... " messages about ide scsi network audio other
I'm going to try my best to get better digital shots of the panic...stay tuned.
Created attachment 118822 [details]
Top portion of screen for kernel-smp-2.6.13-1.1553_FC5 panic
stupid digital camera... i think i can do a little better if i try to do part
of the screen at a time. This is the top half.
Created attachment 118823 [details]
Bottom portion of screen during kernel-smp-2.6.13-1.1553_FC5 panic
I hope these 2 screen portions are better
I think i have made some progress with this.
I am able to boot using "nousb" as a boot time parameter.
Now that I can get the kernel to boot, I'm going to spend some boot cycles
trying to see if i can narrow it down to a specific usb device or driver.
Any suggestions off the top of your head?
my modprobe.conf has
alias usb-controller ohci-hcd
alias usb-controller1 ehci-hcd
ah.. more progress.
I have narrowed the kernel panic down to my microtek slimscan c6 usb scanner
which uses the microtek kernel module.
kernel-smp-2.6.13-1.1561_FC5 boots fine if that usb device is not plugged in.
And then repeatable panics if i plugin the scanner at any point before or after
Is there any specific logging you would like me to provide?
the last kernel to successfully work with this scanner was
kernel-smp-2.6.13-1.1542_FC5. I could boot into that 1542 kernel and give you
information with the device logged in. I'm just not sure what information would
is this still happening ?
First chance to test this with the latest rawhide kernel will be tonight
~14hours or so from now I'll report back this evening or tomorrow morning.
kernel 2.6.13-1.1597_FC5smp still has a kernel panic when i plug my usb scanner
in and the microtek kernel module is loaded.
has this got any better ?
The puzzling thing is, during the window of works/dont-work kernels, there were
only some really benign changes to the microtek driver. So this may be
introduced through changes elsewhere.
No not any better.
Every kernel i've booted all the way through
2.6.14-1.1642_FC5smp has kernel panic when i plug in this usb scanner of if the
scanner is plugged in at boot.
Just a heads up, 2.6.14-1.1674_FC5smp still has the kernel panic behavior with
the microtek sub scanner.
i was sort of hoping usb_hfc was going to be magically responsible for this too,
but alas I am not so lucky.
2.6.14-1.1720_FC5smp seems to be the magic bullet for all my problems.
the microtek module is now loading and the scanner actually seems to work again.
I'm closing this bug out as resolved.