Weird: 30 sec delay during early boot

Weird: 30 sec delay during early boot

[Jeff Garzik]

[-- Attachment #1: Type: text/plain, Size: 357 bytes --]


This appeared in -bk-latest in the past day or two.

BK-current on x86-64 (config/dmesg/lspci attached) will pause for 30 
wall-clock seconds immediately after being loaded by the bootloader, 
then will proceed to boot successfully and function correctly.  This is 
reproducible on every boot.

So, 30 seconds with no printk output, then boots normally.



[-- Attachment #2: config.txt.bz2 --]
[-- Type: application/x-bzip2, Size: 4820 bytes --]

[-- Attachment #3: dmesg.txt.bz2 --]
[-- Type: application/x-bzip2, Size: 4298 bytes --]

[-- Attachment #4: lspci.txt.bz2 --]
[-- Type: application/x-bzip2, Size: 2059 bytes --]

Re: Weird: 30 sec delay during early boot

[Andi Kleen]

Jeff Garzik <jgarzik@pobox.com> writes:

> This appeared in -bk-latest in the past day or two.
>
> BK-current on x86-64 (config/dmesg/lspci attached) will pause for 30
> wall-clock seconds immediately after being loaded by the bootloader,
> then will proceed to boot successfully and function correctly.  This
> is reproducible on every boot.
>
> So, 30 seconds with no printk output, then boots normally.

Boot with earlyprintk=serial,ttySx,baud or earlyprintk=vga
That should enable printk from the beginning and may give
some clues.

-Andi

Re: Weird: 30 sec delay during early boot

[Jeff Garzik]

Andi Kleen wrote:
> Jeff Garzik <jgarzik@pobox.com> writes:
> 
> 
>>This appeared in -bk-latest in the past day or two.
>>
>>BK-current on x86-64 (config/dmesg/lspci attached) will pause for 30
>>wall-clock seconds immediately after being loaded by the bootloader,
>>then will proceed to boot successfully and function correctly.  This
>>is reproducible on every boot.
>>
>>So, 30 seconds with no printk output, then boots normally.
> 
> 
> Boot with earlyprintk=serial,ttySx,baud or earlyprintk=vga
> That should enable printk from the beginning and may give
> some clues.

would early printk show something that dmesg(8) would not?

	Jeff

Re: Weird: 30 sec delay during early boot

[Andi Kleen]

> would early printk show something that dmesg(8) would not?

Yes, it's real time and you can see where the delay occurs.

-Andi

Re: Weird: 30 sec delay during early boot

[Pavel Machek]

Hi!

> This appeared in -bk-latest in the past day or two.
> 
> BK-current on x86-64 (config/dmesg/lspci attached) will pause for 30 
> wall-clock seconds immediately after being loaded by the bootloader, 
> then will proceed to boot successfully and function correctly.  This 
> is reproducible on every boot.
> 
> So, 30 seconds with no printk output, then boots normally.
> 

Search archives, there was something similar seen before.
It was related to EDD, or some similar BIOS feature, IIRC.




-- 
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms         

Re: Weird: 30 sec delay during early boot

[Jeff Garzik]

Pavel Machek wrote:
> Hi!
> 
> 
>>This appeared in -bk-latest in the past day or two.
>>
>>BK-current on x86-64 (config/dmesg/lspci attached) will pause for 30 
>>wall-clock seconds immediately after being loaded by the bootloader, 
>>then will proceed to boot successfully and function correctly.  This 
>>is reproducible on every boot.
>>
>>So, 30 seconds with no printk output, then boots normally.
>>
> 
> 
> Search archives, there was something similar seen before.
> It was related to EDD, or some similar BIOS feature, IIRC.


Thank you for the hint!

I verified that changing CONFIG_EDD=y to '# CONFIG_EDD is not set' 
removed the 30-second pause at boot.

This 30-second pause only appeared recently on my x86-64 box (VIA-based 
Athlon64), so I'll bsearch changesets when I get a free moment (sometime 
this week).

I wonder, even, if it is related to the bootsetup.h fix from Matt that I 
forwarded recently.

	Jeff

Re: Weird: 30 sec delay during early boot

[Matt Domsch]

> This 30-second pause only appeared recently on my x86-64 box (VIA-based 
> Athlon64), so I'll bsearch changesets when I get a free moment (sometime 
> this week).

It's definitely the EDD code that causes the delay, though I believe
it's a BIOS problem.

I've got one report
http://marc.theaimsgroup.com/?l=linux-kernel&m=108797825504429&w=2
from David Balazic with his  Gigabyte GA-7 VAXP Ultra motherboard.
 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).

where there was a delay, which was variable based on stuff he put on
the kernel command line. Likewise, downgrading to BIOS F4 did not
exhibit any delay.

I've got another report with this board with a different BIOS 
where this BIOS version on that board:
Motherboard:  Gigabyte GA-7IXE4
BIOS version: FAd  (that's a beta version)
Kernel:       2.6.2-mm1

worked without the delay.

Yours is the first x86-64 BIOS I've heard with a problem.  Please
provide the disk controller type and BIOS version.

> I wonder, even, if it is related to the bootsetup.h fix from Matt that I 
> forwarded recently.

Only that it's now probing more than just the first disk, but the
first 16 possible BIOS disks.  If the BIOS behaves badly to an int13
READ_SECTORS command, that'd be good to know...

I'm open to suggestions on how to know, from real mode, if a BIOS will
misbehave...

FWIW, I'm on vacation this week, with limited email access, but will
respond when I can.

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

Re: Weird: 30 sec delay during early boot

[Andries Brouwer]

On Sun, Jul 04, 2004 at 03:52:51PM -0500, Matt Domsch wrote:

> Only that it's now probing more than just the first disk, but the
> first 16 possible BIOS disks.  If the BIOS behaves badly to an int13
> READ_SECTORS command, that'd be good to know...

I recall text fragments like

 "Any device claiming compliance to ATA-3 or later as indicated in
  IDENTIFY DEVICE or IDENTIFY PACKET DEVICE data should properly
  release PDIAG- after a power-on or hardware reset upon receiving
  the first command or after 31 seconds have elapsed since the reset,
  whichever comes first."

that seem to imply that probing a nonexistent device may take 31 sec
before one is allowed to conclude that there is nothing there.

Andries


(ide_wait_hwif_ready() used to wait 35 seconds)

RE: Weird: 30 sec delay during early boot

[David Balazic]

Wouldn't the BIOS immediatelly respond with a "no such disk" error if int13
would
try to access a non-existing disk ?
This is BIOS land, not hardware land. The BIOS already has a list of
"existing" drives.
Or maybe I'm flat out wrong ;-)

Regards,
David

> ----------
> From: 	Andries Brouwer[SMTP:aebr@win.tue.nl]
> Sent: 	5. julij 2004 1:27
> To: 	Matt Domsch
> Cc: 	Jeff Garzik; Pavel Machek; Linux Kernel; Andi Kleen; Andrew Morton;
> David Balazic
> Subject: 	Re: Weird:  30 sec delay during early boot
> 
> On Sun, Jul 04, 2004 at 03:52:51PM -0500, Matt Domsch wrote:
> 
> > Only that it's now probing more than just the first disk, but the
> > first 16 possible BIOS disks.  If the BIOS behaves badly to an int13
> > READ_SECTORS command, that'd be good to know...
> 
> I recall text fragments like
> 
>  "Any device claiming compliance to ATA-3 or later as indicated in
>   IDENTIFY DEVICE or IDENTIFY PACKET DEVICE data should properly
>   release PDIAG- after a power-on or hardware reset upon receiving
>   the first command or after 31 seconds have elapsed since the reset,
>   whichever comes first."
> 
> that seem to imply that probing a nonexistent device may take 31 sec
> before one is allowed to conclude that there is nothing there.
> 
> Andries
> 
> 
> (ide_wait_hwif_ready() used to wait 35 seconds)
> 

Re: Weird: 30 sec delay during early boot

[Dave Jones]

On Mon, Jul 05, 2004 at 09:21:34AM +0200, David Balazic wrote:
 > Wouldn't the BIOS immediatelly respond with a "no such disk" error if int13
 > would
 > try to access a non-existing disk ?
 > This is BIOS land, not hardware land.

The BIOS guys get their stash from a different dealer to the hardware guys.
Screwups happen. It could just be yet another 'interesting' interpretation
of specifications.

		Dave

RE: Weird: 30 sec delay during early boot

[David Balazic]

Yes, but GRUB also uses BIOS to access the hard drive(s).
And it can get a list of drives and read them just fine, without any delays.
Either there is a bug in the linux code or it somehow triggers some weird
BIOS bug.

Maybe a newer BIOS call should be used in linux EDD code ( I believe GRUB
uses
a different call for reading sectors than EDD )

Regards,
David

> ----------
> From: 	Dave Jones[SMTP:davej@redhat.com]
> Sent: 	5. julij 2004 13:25
> To: 	David Balazic
> Cc: 	Matt Domsch; Andries Brouwer; Jeff Garzik; Pavel Machek; Linux
> Kernel; Andi Kleen; Andrew Morton
> Subject: 	Re: Weird:  30 sec delay during early boot
> 
> On Mon, Jul 05, 2004 at 09:21:34AM +0200, David Balazic wrote:
>  > Wouldn't the BIOS immediatelly respond with a "no such disk" error if
> int13
>  > would
>  > try to access a non-existing disk ?
>  > This is BIOS land, not hardware land.
> 
> The BIOS guys get their stash from a different dealer to the hardware
> guys.
> Screwups happen. It could just be yet another 'interesting' interpretation
> of specifications.
> 
> 		Dave
> 

Re: Weird: 30 sec delay during early boot

[Matt Domsch]

On Mon, 5 Jul 2004, Andries Brouwer wrote:

> On Sun, Jul 04, 2004 at 03:52:51PM -0500, Matt Domsch wrote:
> 
> > Only that it's now probing more than just the first disk, but the
> > first 16 possible BIOS disks.  If the BIOS behaves badly to an int13
> > READ_SECTORS command, that'd be good to know...
> 
> I recall text fragments like
> 
>  "Any device claiming compliance to ATA-3 or later as indicated in
>   IDENTIFY DEVICE or IDENTIFY PACKET DEVICE data should properly
>   release PDIAG- after a power-on or hardware reset upon receiving
>   the first command or after 31 seconds have elapsed since the reset,
>   whichever comes first."
> 
> that seem to imply that probing a nonexistent device may take 31 sec
> before one is allowed to conclude that there is nothing there.

I wonder if, for our purposes, we could first issue the int13 fn41 (check
extensions present) as we do before calling fn48 later.  This doesn't read
the disk itself, and hopefully can return immediately with a failure on
the nonexistant device, thus we can stop before reading the MBR.  No one
has indicated that the fn41 or fn48 code causes any delay, only the fn02
(read sectors)...

-- 
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

Re: Weird: 30 sec delay during early boot

[Matt Domsch]

[-- Attachment #1: Type: text/plain, Size: 2787 bytes --]

David, Jeff, would you mind trying the patch below on your systems
which exhibit the long delays in the EDD real-mode code?

This does a few things:
1) it uses an int13 fn15 "Get Disk Type" command prior to doing the
fn02 "Read Sectors" command, to try to determine if there is a disk
present or not before reading its signature.

2) A few registers are more fully zeroed out, in case the BIOS cared
about things it shouldn't have.

Crossing my fingers that the delays are gone...
-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

===== arch/i386/boot/edd.S 1.2 vs edited =====
--- 1.2/arch/i386/boot/edd.S	2004-06-29 09:44:48 -05:00
+++ edited/arch/i386/boot/edd.S	2004-07-13 16:48:50 -05:00
@@ -12,13 +12,31 @@
 #include <linux/edd.h>
 
 #if defined(CONFIG_EDD) || defined(CONFIG_EDD_MODULE)
-# Read the first sector of each BIOS disk device and store the 4-byte signature
 edd_mbr_sig_start:
+	xor	%ebx, %ebx
+	xor	%edx, %edx
 	movb	$0, (EDD_MBR_SIG_NR_BUF)	# zero value at EDD_MBR_SIG_NR_BUF
+       	movw	$EDD_MBR_SIG_BUF, %bx		# store buffer ptr in bx
 	movb	$0x80, %dl			# from device 80
-	movw	$EDD_MBR_SIG_BUF, %bx		# store buffer ptr in bx
+
 edd_mbr_sig_read:
-	movl	$0xFFFFFFFF, %eax
+# Do int13 fn15 first, as BIOS should know if a disk is present or not.
+# This avoids long (>30s) delays waiting for the READ_SECTORS to a non-present disk.
+	xor	%eax, %eax
+	xor	%ecx, %ecx
+       	movb	$GETDISKTYPE, %ah		# Function 15
+	pushw	%dx				# which stomps on dx
+	stc					# work around buggy BIOSes
+    	int	$0x13				# make the call
+	sti					# work around buggy BIOSes
+	popw	%dx				# so get back dx
+	jc	edd_mbr_sig_done		# no more BIOS devices
+	cmpb	$HARDDRIVEPRESENT, %ah		# is hard drive present?
+	jne	edd_mbr_sig_done		# no more BIOS devices
+
+# Read the first sector of each BIOS disk device and store the 4-byte signature
+	xor	%ecx, %ecx
+    	movl	$0xFFFFFFFF, %eax
 	movl	%eax, (%bx)			# assume failure
 	pushw	%bx
 	movb	$READ_SECTORS, %ah
===== include/linux/edd.h 1.11 vs edited =====
--- 1.11/include/linux/edd.h	2004-06-29 09:44:48 -05:00
+++ edited/include/linux/edd.h	2004-07-13 16:05:14 -05:00
@@ -49,6 +49,9 @@
 #define EDD_MBR_SIG_MAX 16        /* max number of signatures to store */
 #define EDD_MBR_SIG_NR_BUF 0x1ea  /* addr of number of MBR signtaures at EDD_MBR_SIG_BUF
 				     in boot_params - treat this as 1 byte  */
+#define GETDISKTYPE 0x15          /* int13 AH=0x15 is Get Disk Type command */
+#define HARDDRIVEPRESENT 0x03     /* int13 AH=15 return code in AH */
+
 #ifndef __ASSEMBLY__
 
 #define EDD_EXT_FIXED_DISK_ACCESS           (1 << 0)

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Weird: 30 sec delay during early boot

[Jeff Garzik]

Matt Domsch wrote:
> David, Jeff, would you mind trying the patch below on your systems
> which exhibit the long delays in the EDD real-mode code?
> 
> This does a few things:
> 1) it uses an int13 fn15 "Get Disk Type" command prior to doing the
> fn02 "Read Sectors" command, to try to determine if there is a disk
> present or not before reading its signature.
> 
> 2) A few registers are more fully zeroed out, in case the BIOS cared
> about things it shouldn't have.
> 
> Crossing my fingers that the delays are gone...

Can you attach the patch, or switch mailers?

The patch is word-wrapped and otherwise munged :(

Example:
> +# Do int13 fn15 first, as BIOS should know if a disk is present or not.
> +# This avoids long (>30s) delays waiting for the READ_SECTORS to a non-pre=
> sent disk.
> +       xor     %eax, %eax

Re: Weird: 30 sec delay during early boot

[Matt Domsch]

[-- Attachment #1: Type: text/plain, Size: 403 bytes --]

On Tue, Jul 13, 2004 at 06:35:28PM -0400, Jeff Garzik wrote:
> Can you attach the patch, or switch mailers?
> 
> The patch is word-wrapped and otherwise munged :(

That was sent with mutt-1.4.1-3 on a RHEL3 system...

Attached this time.
-- 
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

[-- Attachment #2: 30sec_delay.patch --]
[-- Type: text/plain, Size: 2062 bytes --]

===== arch/i386/boot/edd.S 1.2 vs edited =====
--- 1.2/arch/i386/boot/edd.S	2004-06-29 09:44:48 -05:00
+++ edited/arch/i386/boot/edd.S	2004-07-13 16:48:50 -05:00
@@ -12,13 +12,31 @@
 #include <linux/edd.h>
 
 #if defined(CONFIG_EDD) || defined(CONFIG_EDD_MODULE)
-# Read the first sector of each BIOS disk device and store the 4-byte signature
 edd_mbr_sig_start:
+	xor	%ebx, %ebx
+	xor	%edx, %edx
 	movb	$0, (EDD_MBR_SIG_NR_BUF)	# zero value at EDD_MBR_SIG_NR_BUF
+       	movw	$EDD_MBR_SIG_BUF, %bx		# store buffer ptr in bx
 	movb	$0x80, %dl			# from device 80
-	movw	$EDD_MBR_SIG_BUF, %bx		# store buffer ptr in bx
+
 edd_mbr_sig_read:
-	movl	$0xFFFFFFFF, %eax
+# Do int13 fn15 first, as BIOS should know if a disk is present or not.
+# This avoids long (>30s) delays waiting for the READ_SECTORS to a non-present disk.
+	xor	%eax, %eax
+	xor	%ecx, %ecx
+       	movb	$GETDISKTYPE, %ah		# Function 15
+	pushw	%dx				# which stomps on dx
+	stc					# work around buggy BIOSes
+    	int	$0x13				# make the call
+	sti					# work around buggy BIOSes
+	popw	%dx				# so get back dx
+	jc	edd_mbr_sig_done		# no more BIOS devices
+	cmpb	$HARDDRIVEPRESENT, %ah		# is hard drive present?
+	jne	edd_mbr_sig_done		# no more BIOS devices
+
+# Read the first sector of each BIOS disk device and store the 4-byte signature
+	xor	%ecx, %ecx
+    	movl	$0xFFFFFFFF, %eax
 	movl	%eax, (%bx)			# assume failure
 	pushw	%bx
 	movb	$READ_SECTORS, %ah
===== include/linux/edd.h 1.11 vs edited =====
--- 1.11/include/linux/edd.h	2004-06-29 09:44:48 -05:00
+++ edited/include/linux/edd.h	2004-07-13 16:05:14 -05:00
@@ -49,6 +49,9 @@
 #define EDD_MBR_SIG_MAX 16        /* max number of signatures to store */
 #define EDD_MBR_SIG_NR_BUF 0x1ea  /* addr of number of MBR signtaures at EDD_MBR_SIG_BUF
 				     in boot_params - treat this as 1 byte  */
+#define GETDISKTYPE 0x15          /* int13 AH=0x15 is Get Disk Type command */
+#define HARDDRIVEPRESENT 0x03     /* int13 AH=15 return code in AH */
+
 #ifndef __ASSEMBLY__
 
 #define EDD_EXT_FIXED_DISK_ACCESS           (1 << 0)

Re: Weird: 30 sec delay during early boot

[Matt Domsch]

[-- Attachment #1: Type: text/plain, Size: 643 bytes --]

On Tue, Jul 13, 2004 at 09:32:33PM -0500, Matt Domsch wrote:
> On Tue, Jul 13, 2004 at 06:35:28PM -0400, Jeff Garzik wrote:
> > Can you attach the patch, or switch mailers?

mutt-1.4.1-3 shows me the patch just fine.  What mailer are you using to read
it? ;-)

http://linux.dell.com/files/edd/linux/linux-2.6.8-rc1-edd-no-30-sec-delay.patch
http://linux.dell.com/files/edd/linux/linux-2.6.8-rc1-edd-no-30-sec-delay.patch.sign

has it now too.

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Weird: 30 sec delay during early boot

[Jeff Garzik]

No luck here with the patch.  Still a 30-second delay before booting on 
the VIA-based x86-64 box.

Any other debug/machine info I can give you?

	Jeff

RE: Weird: 30 sec delay during early boot

[David Balazic]

The same delay as before.

I built 2.6.8-rc1 first, then patched and issued a "make bzImage";
maybe it did not copile all the new stuff ?


> ----------
> From: 	Matt Domsch[SMTP:Matt_Domsch@dell.com]
> Sent: 	14. julij 2004 0:16
> To: 	David Balazic
> Cc: 	Dave Jones; Andries Brouwer; Jeff Garzik; Pavel Machek; Linux
> Kernel; Andi Kleen; Andrew Morton
> Subject: 	Re: Weird:  30 sec delay during early boot
> 
> David, Jeff, would you mind trying the patch below on your systems
> which exhibit the long delays in the EDD real-mode code?
> 
> This does a few things:
> 1) it uses an int13 fn15 "Get Disk Type" command prior to doing the
> fn02 "Read Sectors" command, to try to determine if there is a disk
> present or not before reading its signature.
> 
> 2) A few registers are more fully zeroed out, in case the BIOS cared
> about things it shouldn't have.
> 
> Crossing my fingers that the delays are gone...
> -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
> 
> ===== arch/i386/boot/edd.S 1.2 vs edited =====
> --- 1.2/arch/i386/boot/edd.S	2004-06-29 09:44:48 -05:00
> +++ edited/arch/i386/boot/edd.S	2004-07-13 16:48:50 -05:00
> @@ -12,13 +12,31 @@
>  #include <linux/edd.h>
>  
>  #if defined(CONFIG_EDD) || defined(CONFIG_EDD_MODULE)
> -# Read the first sector of each BIOS disk device and store the 4-byte
> signature
>  edd_mbr_sig_start:
> +	xor	%ebx, %ebx
> +	xor	%edx, %edx
>  	movb	$0, (EDD_MBR_SIG_NR_BUF)	# zero value at
> EDD_MBR_SIG_NR_BUF
> +       	movw	$EDD_MBR_SIG_BUF, %bx		# store buffer ptr
> in bx
>  	movb	$0x80, %dl			# from device 80
> -	movw	$EDD_MBR_SIG_BUF, %bx		# store buffer ptr in bx
> +
>  edd_mbr_sig_read:
> -	movl	$0xFFFFFFFF, %eax
> +# Do int13 fn15 first, as BIOS should know if a disk is present or not.
> +# This avoids long (>30s) delays waiting for the READ_SECTORS to a
> non-present disk.
> +	xor	%eax, %eax
> +	xor	%ecx, %ecx
> +       	movb	$GETDISKTYPE, %ah		# Function 15
> +	pushw	%dx				# which stomps on dx
> +	stc					# work around buggy BIOSes
> +    	int	$0x13				# make the call
> +	sti					# work around buggy BIOSes
> +	popw	%dx				# so get back dx
> +	jc	edd_mbr_sig_done		# no more BIOS devices
> +	cmpb	$HARDDRIVEPRESENT, %ah		# is hard drive present?
> +	jne	edd_mbr_sig_done		# no more BIOS devices
> +
> +# Read the first sector of each BIOS disk device and store the 4-byte
> signature
> +	xor	%ecx, %ecx
> +    	movl	$0xFFFFFFFF, %eax
>  	movl	%eax, (%bx)			# assume failure
>  	pushw	%bx
>  	movb	$READ_SECTORS, %ah
> ===== include/linux/edd.h 1.11 vs edited =====
> --- 1.11/include/linux/edd.h	2004-06-29 09:44:48 -05:00
> +++ edited/include/linux/edd.h	2004-07-13 16:05:14 -05:00
> @@ -49,6 +49,9 @@
>  #define EDD_MBR_SIG_MAX 16        /* max number of signatures to store */
>  #define EDD_MBR_SIG_NR_BUF 0x1ea  /* addr of number of MBR signtaures at
> EDD_MBR_SIG_BUF
>  				     in boot_params - treat this as 1 byte
> */
> +#define GETDISKTYPE 0x15          /* int13 AH=0x15 is Get Disk Type
> command */
> +#define HARDDRIVEPRESENT 0x03     /* int13 AH=15 return code in AH */
> +
>  #ifndef __ASSEMBLY__
>  
>  #define EDD_EXT_FIXED_DISK_ACCESS           (1 << 0)
> 

Re: Weird: 30 sec delay during early boot

[Matt Domsch]

[-- Attachment #1: Type: text/plain, Size: 1245 bytes --]

On Wed, Jul 28, 2004 at 02:16:19PM +0200, David Balazic wrote:
> The same delay as before.
> 
> I built 2.6.8-rc1 first, then patched and issued a "make bzImage";
> maybe it did not compile all the new stuff ?

No, it didn't work for Jeff either, and I've been gone on vacation/OLS
the past couple weeks, just now getting back into normal work mode.  I
haven't forgotten about you.

The crazy thing is, the early real mode code has issued a "Get Disk
Type" (int13 fn15) command for ages, so I suspect it's not being slow for
disk 80 or 81, but for one of the higher values.  From setup.S:

# Check that there IS a hd1 :-)
        movw    $0x01500, %ax
        movb    $0x81, %dl
        int     $0x13
        jc      no_disk1
        cmpb    $3, %ah
        je      is_disk1

This is all I was trying to accomplish with that test patch.

David, you had said before that by downgrading your BIOS you no longer
saw the delay.  Is this not still true?

You also mentioned that Grub made different calls.  I'll check that
out too.

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

RE: Weird: 30 sec delay during early boot

[David Balazic]

> From: 	Matt Domsch[SMTP:Matt_Domsch@dell.com]
> 
> On Wed, Jul 28, 2004 at 02:16:19PM +0200, David Balazic wrote:
> > The same delay as before.
> > 
> > I built 2.6.8-rc1 first, then patched and issued a "make bzImage";
> > maybe it did not compile all the new stuff ?
> 
> No, it didn't work for Jeff either, and I've been gone on vacation/OLS
> the past couple weeks, just now getting back into normal work mode.  I
> haven't forgotten about you.
> 
> The crazy thing is, the early real mode code has issued a "Get Disk
> Type" (int13 fn15) command for ages, so I suspect it's not being slow for
> disk 80 or 81, but for one of the higher values.  From setup.S:
> 
> # Check that there IS a hd1 :-)
>         movw    $0x01500, %ax
>         movb    $0x81, %dl
>         int     $0x13
>         jc      no_disk1
>         cmpb    $3, %ah
>         je      is_disk1
> 
> This is all I was trying to accomplish with that test patch.
> 
> David, you had said before that by downgrading your BIOS you no longer
> saw the delay.  Is this not still true?
> 
Still true, downgrading removes the delay.

> You also mentioned that Grub made different calls.  I'll check that
> out too.
> 
Can you make a patch, that only accesses hd0 and hd1 ?
Or one which prints what is it doing, on each step ?
( I tried this one myself, but it did not work :blush: , IA32 assembler
is not my strong side )

> 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
> 

Re: Weird: 30 sec delay during early boot

[Matt Domsch]

[-- Attachment #1: Type: text/plain, Size: 1056 bytes --]

On Thu, Jul 29, 2004 at 03:05:10PM +0200, David Balazic wrote:
> > David, you had said before that by downgrading your BIOS you no longer
> > saw the delay.  Is this not still true?
> > 
> Still true, downgrading removes the delay.

OK, then I'm inclined to believe it's a BIOS bug really...

> > You also mentioned that Grub made different calls.  I'll check that
> > out too.
> > 
> Can you make a patch, that only accesses hd0 and hd1 ?

Reduce the value of
#define EDD_MBR_SIG_MAX 16

in include/linux/edd.h  to whatever value you like, e.g. 2.

> Or one which prints what is it doing, on each step ?
> ( I tried this one myself, but it did not work :blush: , IA32 assembler
> is not my strong side )

That's more PITA - it's in real mode, before anything's ever been
printed.  I'd prefer not to have to figure that out if I can avoid it.

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

RE: Weird: 30 sec delay during early boot

[David Balazic]

> ----------
> From: 	Matt Domsch[SMTP:Matt_Domsch@dell.com]
> Sent: 	29. julij 2004 18:02
> To: 	David Balazic
> Cc: 	Dave Jones; Andries Brouwer; Jeff Garzik; Pavel Machek; Linux
> Kernel; Andi Kleen; Andrew Morton
> Subject: 	Re: Weird:  30 sec delay during early boot
> 
> On Thu, Jul 29, 2004 at 03:05:10PM +0200, David Balazic wrote:
> > > David, you had said before that by downgrading your BIOS you no longer
> > > saw the delay.  Is this not still true?
> > > 
> > Still true, downgrading removes the delay.
> 
> OK, then I'm inclined to believe it's a BIOS bug really...
> 
> > > You also mentioned that Grub made different calls.  I'll check that
> > > out too.
> > > 
> > Can you make a patch, that only accesses hd0 and hd1 ?
> 
> Reduce the value of
> #define EDD_MBR_SIG_MAX 16
> 
> in include/linux/edd.h  to whatever value you like, e.g. 2.
> 
I set this to "1" and got the same delay ... :-(

> > Or one which prints what is it doing, on each step ?
> > ( I tried this one myself, but it did not work :blush: , IA32 assembler
> > is not my strong side )
> 
> That's more PITA - it's in real mode, before anything's ever been
> printed.  I'd prefer not to have to figure that out if I can avoid it.
> 
> 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
>