Red Hat Bugzilla – Bug 125607
Kernel makes a long pause at the very begin
Last modified: 2015-01-04 17:06:52 EST
Description of problem: When booting, there is along pause ( 1 and half minute ) before starting the kernel. Version-Release number of selected component (if applicable): grub-0.94-5 kernel-2.6.5-1.358 How reproducible: always Details : - select fedora in the grub boot menu ( by pressing the ENTER key ) - the gfx screen is wiped and in text mode the boot command list appears ( with their results ) : root , kernel, initrd - then it stops there, "Uncompressing linux ..." should appear, but does not I did some testing, by manualy entering grub commands : - root (hd0,0) ; kernel /vmlinuz-2.x.x.x ; initrd /initrd-2.x.x.x This hangs as described for 10 seconds, then boots normally. - root (hd0,0) ; kernel /vmlinuz-2.x.x.x ro ; initrd /initrd-2.x.x.x same as before ( 10 sec hang ) - root (hd0,0) ; kernel /vmlinuz-2.x.x.x root=LABEL=/ ; initrd /initrd-2.x.x.x The hang now takes 1 minute and 32 seconds, then it goes on normally. - kernel /vmlinuz ro rhgb -> 10 seconds hang - kernel /vmlinuz ro rhgb quiet -> 1:32 hang - kernel /vmlinuz ro root=LABEL=1 rhgb -> 1:33 - kernel /vmlinuz ro root=LABEL=1 rhgb quiet -> 1:33 Another thing: if I switch in BIOS the IDE mode to RAID ( it is a single HD, so there is no "real world" change ), then GTUB loads, it loads the kernel, initrd, but after the "boot" command it hangs forever ( I waited 8 hours ). It there a way to see what is grub doing ? I tried the "debug on" command, but saw no effect.
I tried an older grub ( 0.93-something ) and it was the same. Then I tried to boot an older 2.4.x redhat kernel, and it did not have any problems. Switching component to "kernel".
The kernel that has no problems is : kernel-2.4.22-1.2061.nptl-athlon
Probably timeouts probing the devices to find the right label.
The label for the root FS ? Isn't that done _after_ the kernel is uncompressed ? I also teste more : no delay : 2.6.0-test10 delay : 2.6.7 , 2.6.6 , 2.6.6-1.435
Aha, the CONFIG_EDD option is the culprit. I tried linux-2.6.7 with the 2.6.6-1.435 config file and it has the delay, but after turning CONFIG_EDD off it has no delay at boot.
I don't know if this is related, but I did some searching on EDD and was interested when I saw Dell have some information since I am seeing something similar with my Dell. Note I don't know if mine is ever booting because I haven't waited the 1.5 minutes or so to see (I will tonight). While searching around dell's site, I found this patch: http://linux.dell.com/edd/linux/linux-2.6.8-rc1-edd-no-30-sec-delay.patch Which just by your previous information in this bugzilla and by the name of the patch make me suspect that this will fix the issue w/o having to disable EDD. Though disabling EDD doesn't seem to be a bad idea unless you are going to use it.
I already tried that patch, no change. See http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&frame=right&th=977b4b8b026ca361&seekm=2ezZk-7sc-5%40gated-at.bofh.it#link17
Well, sadly that did not help me at all... My system doesn't boot. I've waited as long as five minutes and still nothing happens. It's very sad and very disheartening. I've had more problems this week with FC2 than any previous release. I'm going to try a few things like checking on BIOS upgrades and the like. Maybe I'll get lucky, who knows. :)
My BIOS is up-to-date. I've tried reinstalling from ISOs off of my second hard drive (thinking maybe the burn was bad). That still failed to boot. I then double checked the md5sum output for the .iso files and they are clean. Thinking maybe a newer kernel might help, I reinstalled FC2 from scratch, booted into rescue mode and installed kernel-2.6.7-1.494.2.2.i686.rpm. Still nothing. I'm running out of things to try. There's not much to the Dell Dimension XPS T500 BIOS in the way of advanced settings. I'm at my wits end. Anything else I can try?
Okay, moved the hard drive I installed FC2 onto into a Dimension XPS R450 (P2 450) system and it had the same problem. Putting that same hard drive in my home grown P4 system (Intel mobo D845PESV) the system boots up just fine. Got with a friend of mine who has an XPS T600 (same as my T500 only he has a faster processor) and compared BIOS settings. He is running FC2 without any problems. I made my BIOS settings match his, no go. I even DOWNGRADED my BIOS by one revision to match his, no go. However, I found that if I enter the grub command line and issue the commands by hand, the system DOES timeout and eventually boot within 5 minutes or so (I haven't sat next to it to see it boot yet). I am downloading the latest kernel source and am going to recompile it with the EDD disabled to see if that clears up my problem. Strange that it won't timeout and boot when I select the item in the grub menu -- but does when I enter it by hand. Coincidence? Probably. I will post here the results of my disabling EDD shortly.
Recompiled without CONFIG_EDD and I still get the hangup. Mine is so very different though. I've seen the system actually boot twice (no idea the length of pause since that's usually when I throw my hands up and just leave it sit there). I know that I've waited 15-20 minutes before and not seen any progress on booting. (Thankfully I have a second system so waiting 15-20 minutes isn't that painful.) So to recap I have a Dell XPS T___ and a Dell XPS R___ with the same hang problem. However, I'm beginning to believe it is something different from yours -- should I branch out and make a separate bug report?
Yes, if CONFIG_EDD=n, please file yours as a different bug.
I've seen two BIOSes reported which don't like EDD's read sector zero functionality. I'm open to suggestions, as I don't have a way to know which BIOSes will behave badly (i.e. pause for a while) and which won't. In one instance, using a different version of the BIOS solved it. I'm inclined to say it's a BIOS problem and to take it up with your BIOS manufacturer in each case, but that isn't very satisfying. I see now that GRUB uses int13 fn42 (Read LBA) if the BIOS claims to support LBA, and falls back to fn2 (Read CHS) if not. The BIOSes that all have this problem are very new, and likely all support LBA. Anyone want to help code this up for EDD? :-)
"take it up with your BIOS manufacturer" You think it's worth it ? ( Will they listen at all to an end user ? ) "Anyone want to help code this up for EDD?" C'mon, it's only a few lines of code ! ;-)
David, Alan, and Jeff: each of you have reported to me separate controllers which either pause (Jeff, David), or hang completely with CONFIG_EDD=[ym]. I'll attach a patch I'd like you to try if possible. This causes EDD to use int13 fn42 EXTENDED READ rather that int13 fn02 READ SECTORS if the BIOS reports it can do so. There's also a Kconfig addition (which will likely clash with Alan's recent patch) for CONFIG_EDD_SKIP_MBR which *should* allow the use of the fn41 and fn48 aspects, without causing disk sector reads. Hopefully that won't be necessary to set to y, but I think the option may be helpful. Please post test results in this bugzilla. Thanks, Matt
Created attachment 104683 [details] extended_read.patch
and you can skip the Makefile hunk, it's redundant.
Created attachment 104753 [details] edd-for-akpm.patch Attached is what I'm sending to akpm. It fixes a few bugs in the previous patch I had posted. In particular, it decides when to issue int13 fn48 correctly now, it zeros out the edd_info block just in case, and it stops using the zero-page for the device address parameter buffer, using the stack instead. Works for me on x86, code path is identical for x86-64.
David B - I posted a patch to lkml last week which provides two new command line options: edd=off disables EDD completely, edd=skipmbr disables the MBR probing (which is what affects you). I expect akpm to include this after 2.6.10 is out.
Fedora Core 2 has now reached end of life, and no further updates will be provided by Red Hat. The Fedora legacy project will be producing further kernel updates for security problems only. If this bug has not been fixed in the latest Fedora Core 2 update kernel, please try to reproduce it under Fedora Core 3, and reopen if necessary, changing the product version accordingly. Thank you.