Weird: 30 sec delay during early boot

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.

Hi!

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         

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

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.

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

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)

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

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

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)