lkml.org 
[lkml]   [2004]   [Jun]   [23]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
FromDavid Balazic <>
SubjectRE: EDD code causes long boot delay
DateWed, 23 Jun 2004 10:05:51 +0200
> From: 	Matt Domsch[SMTP:Matt_Domsch@dell.com]
> 
> On Tue, Jun 22, 2004 at 08:45:00AM +0200, David Balazic wrote:
> > I use the commands ( in the grub shell that boots from my HD ):
> > root (hd0,0)
> > kernel /vmlinuz-2.6.xxx ro root=dev/hda2
> > initrd /initrd-2.xxx
> > boot
> > 
> > After entering the "boot" command, the screen is cleared and then
> nothing
> > happens for 93 seconds.
> > After that linux boot normally ( beginning with the message
> "Uncompressing
> > linux..." and so on ).
> > If I trim the kernel command line to only "kernel /vmlinuz-2.6.xxx ro" ,
> > then the delay is 10 seconds.
> 
> Wow.  That's really interesting, and gives a good starting point to
> look at, where the command line is stored.  But the EDD code shouldn't
> be using any of the space that the command line occupies, ever...  
> 
Did some investigation in this area :

grub line                               |  delay between "boot" and
"Uncompressing linux...."
----------------------------------------------------------------------------
-------------
"kernel (hd0,0)/bzImage-2.6.7"                     10 seconds
"kernel (hd0,0)/bzImage-2.6.7 a"                  10 seconds
"kernel (hd0,0)/bzImage-2.6.7 a b"               10 seconds
"kernel (hd0,0)/bzImage-2.6.7 a b c d"          10 seconds
"kernel (hd0,0)/bzImage-2.6.7 a b c d e"       1 minute  54 seconds
"kernel (hd0,0)/bzImage-2.6.7 a b c de"        10 seconds
"kernel (hd0,0)/bzImage-2.6.7 a b c def"       1 minute  54 seconds
"kernel (hd0,0)/bzImage-2.6.7 abcdefgh"       10 seconds
"kernel (hd0,0)/bzImage-2.6.7 abcdefghi"      10 seconds
"kernel (hd0,0)/bzImage-2.6.7 abcdefghij"     1 minute  30 seconds
"kernel (hd0,0)/bzImage-2.6.7 abcdefghijk"   1 minute 30 seconds

> 
> > If I change the operating mode of the IDE adapter in BIOS to RAID,
> > then the delay is infinite ( I waited 8 hours and it still did not
> > print "Uncompressing linx ...." ). Note that with this option, there
> > is no real difference, since the disks are not mirrored or striped
> > or anything. GRUB can read everything just fine.
> 
> > I tested all kernels ( vanilla Linus release from kernel.org ) from
> > 2.6.0 to 2.6.7 and saw that the problem appeared in 2.6.3. Then I
> > found out that that the cause is the CONFIG_EDD option, if I turn it
> > off, then linux-2.6.7 boot without the mentioned delay.
> >
> > So, is there some bug in the EDD code ? A BIOS bug ? Any other comment ?
> > My hardware is a Gigabyte GA-7 VAXP Ultra motherboard ( see 
> >
> http://www.giga-byte.com/MotherBoard/Products/Products_GA-7VAXP%20Ultra.ht
> m
> > )
> > BIOS version is F6.
> > Disks : 
> >  - Quantum lct20 20 GB
> >  - IBM Deskstar 120GXP 60 GB
> > Both on the Promise PDC 20276 on-board controller, each on its own
> > channel(cable).
> 
> It *feels* like a BIOS bug (or bugs), as you're the first to report
> such a problem.  I've got one success report with this motherboard
> dated 8 Feb 2004.
> 
I downgraded thje BIOS to version F4 and then there is no delay :-(

> Motherboard:  Gigabyte GA-7IXE4
> BIOS version: FAd  (that's a beta version)
> Kernel:       2.6.2-mm1
> 
> The question is, which of the int13 calls is messing up your BIOS?
> The "read MBR sector and save the 4-byte MBR signature" code was added
> there at 2.6.3, which is quite coincident.
> 
> This is the code, in arch/i386/boot/setup.S, which makes that int13
> call.  Can you try #if 0'ing this chunk out and see if this helps?
> 
> +# Read the first sector of device 80h and store the 4-byte signature
> +       movl    $0xFFFFFFFF, %eax
> +       movl    %eax, (DISK80_SIG_BUFFER)       # assume failure
> +       movb    $READ_SECTORS, %ah
> +       movb    $1, %al                         # read 1 sector
> +       movb    $0x80, %dl                      # from device 80
> +       movb    $0, %dh                         # at head 0
> +       movw    $1, %cx                         # cylinder 0, sector 0
> +       pushw   %es
> +       pushw   %ds
> +       popw    %es
> +       movw    $EDDBUF, %bx
> +       int     $0x13
> +       jc      disk_sig_done
> +       movl    (EDDBUF+MBR_SIG_OFFSET), %eax
> +       movl    %eax, (DISK80_SIG_BUFFER)       # store success
> +disk_sig_done:
> +       popw    %es
> +
> 
My version (linux-2.6.7) has three additional lines around the int 13 call,
commented as a workaround for buggy BIOS-es ( they are mov, cli and sti
IIRC).

If I #if 0 out this block, then the delay disappears. I also tried to
comment out the buggy-BIOS
workaround code, but that did not make any difference ( the boot delay was
still
there ).

> If so, then I'd like to believe that it's definitely a BIOS bug, as
> int13 reads to the MBR had better work (gee, that's how the boot
> loader got loaded in the first place, right?)
> 
Maybe the linux code does something that confuses the BIOS before the EDD
code
is run ??? Guessing ...

> Thanks,
> Matt
> 
> -- 
> Matt Domsch
> Sr. Software Engineer, Lead Engineer
> Dell Linux Solutions linux.dell.com & www.dell.com/linux
> Linux on Dell mailing lists @ http://lists.us.dell.com
> 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:04    [from the cache]
©2003-2008