Bug 125607 - Kernel makes a long pause at the very begin
Kernel makes a long pause at the very begin
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
2
athlon Linux
medium Severity medium
: ---
: ---
Assigned To: Dave Jones
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-06-09 07:13 EDT by David Balažic
Modified: 2015-01-04 17:06 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-04-16 00:54:43 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
extended_read.patch (8.57 KB, patch)
2004-10-03 14:49 EDT, Matt Domsch
no flags Details | Diff
edd-for-akpm.patch (8.41 KB, patch)
2004-10-04 17:42 EDT, Matt Domsch
no flags Details | Diff

  None (edit)
Description David Balažic 2004-06-09 07:13:48 EDT
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.
Comment 1 David Balažic 2004-06-12 06:58:55 EDT
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".
Comment 2 David Balažic 2004-06-12 07:07:09 EDT
The kernel that has no problems is : kernel-2.4.22-1.2061.nptl-athlon
Comment 3 Alan Cox 2004-06-19 07:41:47 EDT
Probably timeouts probing the devices to find the right label.
Comment 4 David Balažic 2004-06-19 14:31:22 EDT
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
Comment 5 David Balažic 2004-06-22 02:16:10 EDT
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.
Comment 6 Michael Douglass 2004-08-18 18:09:41 EDT
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.
Comment 8 Michael Douglass 2004-08-19 22:52:47 EDT
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. :)
Comment 9 Michael Douglass 2004-08-20 00:29:44 EDT
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?
Comment 10 Michael Douglass 2004-08-21 23:35:10 EDT
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.
Comment 11 Michael Douglass 2004-08-23 11:42:33 EDT
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?
Comment 12 Matt Domsch 2004-08-23 11:54:13 EDT
Yes, if CONFIG_EDD=n, please file yours as a different bug.
Comment 13 Matt Domsch 2004-08-23 11:55:07 EDT
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? :-)
Comment 14 David Balažic 2004-08-24 01:28:06 EDT
"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 ! ;-)
Comment 15 Matt Domsch 2004-10-03 14:48:54 EDT
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
Comment 16 Matt Domsch 2004-10-03 14:49:47 EDT
Created attachment 104683 [details]
extended_read.patch
Comment 17 Matt Domsch 2004-10-03 15:01:19 EDT
and you can skip the Makefile hunk, it's redundant.
Comment 18 Matt Domsch 2004-10-04 17:42:21 EDT
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.
Comment 19 Matt Domsch 2004-12-08 14:32:15 EST
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.
Comment 20 Dave Jones 2005-04-16 00:54:43 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.