Red Hat Bugzilla – Bug 378321
Regression: Dell D820 fails to boot with kernel 126.96.36.199-49
Last modified: 2007-12-04 01:43:54 EST
Description of problem:
After updating the kernel to 188.8.131.52-49, my Dell D820 laptop does not boot
with the new kernel. It works fine with previous one 184.108.40.206-42.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Try to boot with kernel-220.127.116.11-49
Boot fails (hangs after displaying "OK, Booting the kernel")
I haven't tried any boot option since the previous version works.
My HP nx9010 doesn't boot with kernel-18.104.22.168-49 either. I'm getting an
endless string of segfault's after the init message. Version -42 was (is) fine.
(In reply to comment #0)
> Description of problem:
> After updating the kernel to 22.214.171.124-49, my Dell D820 laptop does not boot
> with the new kernel. It works fine with previous one 126.96.36.199-42.
> Version-Release number of selected component (if applicable):
> How reproducible:
> Steps to Reproduce:
> 1. Try to boot with kernel-188.8.131.52-49
> Actual results:
> Boot fails (hangs after displaying "OK, Booting the kernel")
Remove the "quiet" option from the entry in /etc/grub.conf for the new kernel
and boot it to see what messages if any it prints before stopping.
I removed the quiet option, and the boot stopped just after the line
"Serial: 8250/16550 driver... IRQ sharing enabled"
I will attach a digital picture of the boot, and separately a text file with
the corresponding portion of the messages during a boot with 184.108.40.206-42.
Created attachment 258931 [details]
Digital picture of failed boot
Created attachment 258941 [details]
Messages from working kernel
Does adding the option "serial.nr_uarts=0" make any difference?
I tried serial.nr_uarts=0 which didn't do any thing.
Since Google didn't find any reference for this option, but mentioned
8250.nr_uarts=0, I tried that too. This helped go a bit further in the boot
(three or your more messages onscreen, up to
Yenta O2: enabling read prefetch/write burst
then it hanged as before.
The bug seems to be fixed in the new kernel