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

[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

[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

EDD results (was Re: Weird: 30 sec delay during early boot)

[Jeff Garzik]

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


Ok, here are some EDD results, as described by a script (edd-report.sh, 
attached) cut-n-pasted from the EDD web page 
http://linux.dell.com/edd/results.html


First report:
HP workstation, ICH5-based
ICH5 PATA (boot drive)
ICH5 SATA
Adaptec 1210SA (aka SiI 3112) SATA


Second report, the one with the 30-second delay:
MSI whitebox, VIA-based, Athlon64
Promise 203xx SATA (boot drive)
VIA SATA




[-- Attachment #2: edd-report.sh --]
[-- Type: application/x-sh, Size: 247 bytes --]

[-- Attachment #3: edd-results-hp-ich5.txt.bz2 --]
[-- Type: application/x-bzip2, Size: 9705 bytes --]

[-- Attachment #4: edd-results-via-amd64.txt.bz2 --]
[-- Type: application/x-bzip2, Size: 7927 bytes --]

Re: EDD results (was Re: Weird: 30 sec delay during early boot)

[Jeff Garzik]

Jeff Garzik wrote:
> Second report, the one with the 30-second delay:
> MSI whitebox, VIA-based, Athlon64
> Promise 203xx SATA (boot drive)
> VIA SATA

This box also has VIA PATA, but I have disabled the controller in BIOS. 
  Also, nothing is connected to the PATA controller.

(I'm guessing this detail may be related to the delay)