Hi YH and list,
I've been playing with the boot prompt timeouts for Etherboot/filo on my setup.
I've noticed that if I set the combined timeout (the etherboot ASK_BOOT and filo AUTOBOOT_DELAY) to less than about 3 seconds, the system won't boot because filo doesn't see the SATA drives. This example has ASK_BOOT set to -1 (i.e. disabled), and AUTOBOOT_DELAY set to 2 seconds.
--------------------------- Welcome to elfboot, the open sourced starter. January 2002, Eric Biederman. Version 1.3
33:stream_init() - rom_stream: 0xfffc0000 - 0xfffdffff Found ELF candiate at offset 0 Loading Etherboot version: 5.4.1 Dropping non PT_LOAD segment New segment addr 0x10000 size 0x49090 offset 0x0 filesize 0xf7f0 (cleaned up) New segment addr 0x10000 size 0x49090 offset 0x0 filesize 0xf7f0 Loading Segment: addr: 0x00000000bff90000 memsz: 0x0000000000032000 filesz: 0x000000000000f7f0 Clearing Segment: addr: 0x00000000bff9f7f0 memsz: 0x0000000000022810 Loading Segment: addr: 0x0000000000042000 memsz: 0x0000000000017090 filesz: 0x0000000000000000 Clearing Segment: addr: 0x0000000000042000 memsz: 0x0000000000017090 Jumping to boot code at 0x100b0 CPU 2064 Mhz Etherboot 5.4.1 (GPL) http://etherboot.org Drivers: TG3 FILO Images: NBI ELF Protocols: DHCP TFTP Relocating _text from: [000100e0,00059090) to [bfeb7050,bff00000) Probing pci disk... [FILO]FILO version 0.4.1 (root@countzero.vandewege.net) Fri Apr 21 18:47:00 EDT 2006 Press <Enter> for default boot, or <Esc> for boot prompt... 2^H ^H1^H ^Htimed out boot: hde1:/linuxbios.elf No drive detected on IDE channel 2 boot: hde1:/linuxbios.elf^H ^H^H ^Hlf Drive 4 does not exist boot: hde1:/linuxbios.elf ---------------------------
This is only a problem for a cold boot, i.e. from power off. If I do a warm reboot, the system boots fine.
Is there something that can be done about this? It seems silly to have to introduce delays in the bootup sequence to make booting from SATA possible, particularly since fast bootup is one of LinuxBIOS's strengths.
Thanks, Ward.
Ward Vandewege wrote:
This is only a problem for a cold boot, i.e. from power off. If I do a warm reboot, the system boots fine.
Is there something that can be done about this? It seems silly to have to introduce delays in the bootup sequence to make booting from SATA possible, particularly since fast bootup is one of LinuxBIOS's strengths.
this problem goes back to our very first boot some six years ago. Amazing.
ATA has outrageous boot delays. I'm sorry to see that SATA has them too. I have no good idea how to fix this, unless we can train FILO to know that we're coming into boot from power on reset.
ron
* Ronald G Minnich rminnich@lanl.gov [060425 00:02]:
this problem goes back to our very first boot some six years ago. Amazing.
ATA has outrageous boot delays. I'm sorry to see that SATA has them too. I have no good idea how to fix this, unless we can train FILO to know that we're coming into boot from power on reset.
What's needed here? Just keep on polling until either a couple more seconds are gone or we finally start seeing the drive?
What features does the etherboot filo have that the official one does not? I'd like to merge those, as file-pre-0.5 has a lot of interesting stuff that never went into etherboot (and etherboot is a pita to build compared to filo at least)
Stefan
On Tue, Apr 25, 2006 at 12:21:44AM +0200, Stefan Reinauer wrote:
- Ronald G Minnich rminnich@lanl.gov [060425 00:02]:
this problem goes back to our very first boot some six years ago. Amazing.
ATA has outrageous boot delays. I'm sorry to see that SATA has them too. I have no good idea how to fix this, unless we can train FILO to know that we're coming into boot from power on reset.
What's needed here? Just keep on polling until either a couple more seconds are gone or we finally start seeing the drive?
What features does the etherboot filo have that the official one does not? I'd like to merge those, as file-pre-0.5 has a lot of interesting stuff that never went into etherboot (and etherboot is a pita to build compared to filo at least)
Can we have SATA support directly in filo? That would simplify things greatly!
Ward.
* Ward Vandewege ward@gnu.org [060425 00:25]:
On Tue, Apr 25, 2006 at 12:21:44AM +0200, Stefan Reinauer wrote:
- Ronald G Minnich rminnich@lanl.gov [060425 00:02]:
this problem goes back to our very first boot some six years ago. Amazing.
ATA has outrageous boot delays. I'm sorry to see that SATA has them too. I have no good idea how to fix this, unless we can train FILO to know that we're coming into boot from power on reset.
What's needed here? Just keep on polling until either a couple more seconds are gone or we finally start seeing the drive?
What features does the etherboot filo have that the official one does not? I'd like to merge those, as file-pre-0.5 has a lot of interesting stuff that never went into etherboot (and etherboot is a pita to build compared to filo at least)
Can we have SATA support directly in filo? That would simplify things greatly!
The latest Subversion revision at
svn://openbios.org/filo/trunk/filo-0.5
should have working S-ATA. I have no S-ATA here so I could not test it. It's the version that also comes with the GRUB user interface.
It still lacks two things:
- reading syslinux.cfg from cdroms/dvds to allow really easy CD booting - zelf support
Stefan
Hi Stefan,
On Sat, Apr 29, 2006 at 01:16:17AM +0200, Stefan Reinauer wrote:
The latest Subversion revision at
svn://openbios.org/filo/trunk/filo-0.5
should have working S-ATA. I have no S-ATA here so I could not test it. It's the version that also comes with the GRUB user interface.
It still lacks two things:
- reading syslinux.cfg from cdroms/dvds to allow really easy CD booting
- zelf support
Not sure what happened, but it seems we're not 100% there yet. I've attached a boot log, and my filo Config file. It hangs after saying 'IDE channel 2 not found'.
I wonder if this is because it ignored (!) the AUTOBOOT_DELAY, which would mean the SATA drives would not be fully ready yet. This was a cold boot.
Suggestions? Ward.
* Ward Vandewege ward@gnu.org [060501 17:55]:
Hi Stefan,
should have working S-ATA. I have no S-ATA here so I could not test it. It's the version that also comes with the GRUB user interface.
Not sure what happened, but it seems we're not 100% there yet. I've attached a boot log, and my filo Config file. It hangs after saying 'IDE channel 2 not found'.
I wonder if this is because it ignored (!) the AUTOBOOT_DELAY, which would mean the SATA drives would not be fully ready yet. This was a cold boot.
AUTOBOOT_DELAY is a different one, it waits for user interaction before trying to start the kernel..
drive startup times could be an issue though
Could you try some things:
* update to the latest svn revision (17 as I write this) and make sure you enabled the following option (which is new)
# Add a short delay when polling status registers # (required on some broken SATA controllers) IDE_DISK_POLL_DELAY = 1
* if that doesnt help: try whether the disk is detected as hda instead of hde. This might happen with the current code.
* enable the two options: DEBUG_PCI and DEBUG_IDE in the config file.
Stefan
On Fri, May 05, 2006 at 03:47:09PM +0200, Stefan Reinauer wrote:
AUTOBOOT_DELAY is a different one, it waits for user interaction before trying to start the kernel..
Right - FILO never even gets to that point.
drive startup times could be an issue though
Could you try some things:
- update to the latest svn revision (17 as I write this) and make sure you enabled the following option (which is new)
I've tried rev 19.
# Add a short delay when polling status registers # (required on some broken SATA controllers) IDE_DISK_POLL_DELAY = 1
I've tried this; the boot log is attached (minicom-20060505.cap) with DEBUG_PCI, DEBUG_IDE and DEBUG_LINUXBIOS enabled. Didn't help.
- if that doesnt help: try whether the disk is detected as hda instead of hde. This might happen with the current code.
I've tried that too, the bootlog is also attached (minicom-20060505-2.cap). Still no luck; though here it does seem to find the IDE controller. But not the drive...
Ward.
* Ward Vandewege ward@gnu.org [060505 23:38]:
I've tried this; the boot log is attached (minicom-20060505.cap) with DEBUG_PCI, DEBUG_IDE and DEBUG_LINUXBIOS enabled. Didn't help.
- if that doesnt help: try whether the disk is detected as hda instead of hde. This might happen with the current code.
I've tried that too, the bootlog is also attached (minicom-20060505-2.cap). Still no luck; though here it does seem to find the IDE controller. But not the drive...
Aha! It shows a floating IDE bus... Does anyone have an idea what's wrong exactly if this shows up? It might just be an issue of waiting just a little bit longer..
Sorry, what board was this again?
Stefan
On Sat, May 06, 2006 at 02:39:13PM +0200, Stefan Reinauer wrote:
- Ward Vandewege ward@gnu.org [060505 23:38]:
I've tried this; the boot log is attached (minicom-20060505.cap) with DEBUG_PCI, DEBUG_IDE and DEBUG_LINUXBIOS enabled. Didn't help.
- if that doesnt help: try whether the disk is detected as hda instead of hde. This might happen with the current code.
I've tried that too, the bootlog is also attached (minicom-20060505-2.cap). Still no luck; though here it does seem to find the IDE controller. But not the drive...
Aha! It shows a floating IDE bus... Does anyone have an idea what's wrong exactly if this shows up? It might just be an issue of waiting just a little bit longer..
Sorry, what board was this again?
Tyan s2881; onboard sata controller.
Ward.
* Ward Vandewege ward@gnu.org [060506 15:11]:
On Sat, May 06, 2006 at 02:39:13PM +0200, Stefan Reinauer wrote:
- Ward Vandewege ward@gnu.org [060505 23:38]:
I've tried this; the boot log is attached (minicom-20060505.cap) with DEBUG_PCI, DEBUG_IDE and DEBUG_LINUXBIOS enabled. Didn't help.
- if that doesnt help: try whether the disk is detected as hda instead of hde. This might happen with the current code.
I've tried that too, the bootlog is also attached (minicom-20060505-2.cap). Still no luck; though here it does seem to find the IDE controller. But not the drive...
Aha! It shows a floating IDE bus... Does anyone have an idea what's wrong exactly if this shows up? It might just be an issue of waiting just a little bit longer..
Hm. can you set the timeout from 20ms to 200ms?
Does it work with the etherboot filo btw?
Stefan
On Fri, May 12, 2006 at 12:11:43AM +0200, Stefan Reinauer wrote:
- Ward Vandewege ward@gnu.org [060506 15:11]:
On Sat, May 06, 2006 at 02:39:13PM +0200, Stefan Reinauer wrote:
- Ward Vandewege ward@gnu.org [060505 23:38]:
I've tried this; the boot log is attached (minicom-20060505.cap) with DEBUG_PCI, DEBUG_IDE and DEBUG_LINUXBIOS enabled. Didn't help.
- if that doesnt help: try whether the disk is detected as hda instead of hde. This might happen with the current code.
I've tried that too, the bootlog is also attached (minicom-20060505-2.cap). Still no luck; though here it does seem to find the IDE controller. But not the drive...
Aha! It shows a floating IDE bus... Does anyone have an idea what's wrong exactly if this shows up? It might just be an issue of waiting just a little bit longer..
Hm. can you set the timeout from 20ms to 200ms?
Do you mean this line
timeout = currticks() + 20 * TICKS_PER_SEC / 1000;
in ide_bus_floating() in drivers/ide.c?
Does it work with the etherboot filo btw?
Yes; that's what I've been using. But it _only_ works if I guarantee at least 3 to 4 seconds of bootup delay; that's why I have the AUTOBOOT_DELAY set to 5. But that doesn't work for Filo 0.5 - maybe it tries to find the disks before doing the AUTOBOOT_DELAY?
Ward.
On Thu, May 11, 2006 at 06:40:47PM -0400, Ward Vandewege wrote:
On Fri, May 12, 2006 at 12:11:43AM +0200, Stefan Reinauer wrote:
- Ward Vandewege ward@gnu.org [060506 15:11]:
On Sat, May 06, 2006 at 02:39:13PM +0200, Stefan Reinauer wrote:
- Ward Vandewege ward@gnu.org [060505 23:38]:
I've tried this; the boot log is attached (minicom-20060505.cap) with DEBUG_PCI, DEBUG_IDE and DEBUG_LINUXBIOS enabled. Didn't help.
- if that doesnt help: try whether the disk is detected as hda instead of hde. This might happen with the current code.
I've tried that too, the bootlog is also attached (minicom-20060505-2.cap). Still no luck; though here it does seem to find the IDE controller. But not the drive...
Aha! It shows a floating IDE bus... Does anyone have an idea what's wrong exactly if this shows up? It might just be an issue of waiting just a little bit longer..
Hm. can you set the timeout from 20ms to 200ms?
Do you mean this line
timeout = currticks() + 20 * TICKS_PER_SEC / 1000;
in ide_bus_floating() in drivers/ide.c?
I've modified that to 200, but to no avail. Still the same problem after a cold boot (see attached boot log - minicom-20060511-coldboot.cap).
A warm boot works fine though (minicom-20060511-warmboot.cap).
Ward.
* Ward Vandewege ward@gnu.org [060512 00:40]:
On Fri, May 12, 2006 at 12:11:43AM +0200, Stefan Reinauer wrote:
- Ward Vandewege ward@gnu.org [060506 15:11]:
On Sat, May 06, 2006 at 02:39:13PM +0200, Stefan Reinauer wrote:
- Ward Vandewege ward@gnu.org [060505 23:38]:
I've tried this; the boot log is attached (minicom-20060505.cap) with DEBUG_PCI, DEBUG_IDE and DEBUG_LINUXBIOS enabled. Didn't help.
- if that doesnt help: try whether the disk is detected as hda instead of hde. This might happen with the current code.
I've tried that too, the bootlog is also attached (minicom-20060505-2.cap). Still no luck; though here it does seem to find the IDE controller. But not the drive...
Aha! It shows a floating IDE bus... Does anyone have an idea what's wrong exactly if this shows up? It might just be an issue of waiting just a little bit longer..
Hm. can you set the timeout from 20ms to 200ms?
Do you mean this line
timeout = currticks() + 20 * TICKS_PER_SEC / 1000;
in ide_bus_floating() in drivers/ide.c?
Does it work with the etherboot filo btw?
Yes; that's what I've been using. But it _only_ works if I guarantee at least 3 to 4 seconds of bootup delay; that's why I have the AUTOBOOT_DELAY set to 5. But that doesn't work for Filo 0.5 - maybe it tries to find the disks before doing the AUTOBOOT_DELAY?
Yes, it immediately tries to load the menu.lst file. If you dont want a grub style menu you can disable USE_GRUB to get the old behavior
Stefan
On Fri, May 12, 2006 at 01:13:20AM +0200, Stefan Reinauer wrote:
Does it work with the etherboot filo btw?
Yes; that's what I've been using. But it _only_ works if I guarantee at least 3 to 4 seconds of bootup delay; that's why I have the AUTOBOOT_DELAY set to 5. But that doesn't work for Filo 0.5 - maybe it tries to find the disks before doing the AUTOBOOT_DELAY?
Yes, it immediately tries to load the menu.lst file. If you dont want a grub style menu you can disable USE_GRUB to get the old behavior
Actually, I was looking forward to having a GRUB style bootloader - for a production machine in a datacenter that's a nice thing to have.
Ward.
* Ward Vandewege ward@gnu.org [060512 02:16]:
On Fri, May 12, 2006 at 01:13:20AM +0200, Stefan Reinauer wrote:
Does it work with the etherboot filo btw?
Yes; that's what I've been using. But it _only_ works if I guarantee at least 3 to 4 seconds of bootup delay; that's why I have the AUTOBOOT_DELAY set to 5. But that doesn't work for Filo 0.5 - maybe it tries to find the disks before doing the AUTOBOOT_DELAY?
Yes, it immediately tries to load the menu.lst file. If you dont want a grub style menu you can disable USE_GRUB to get the old behavior
Actually, I was looking forward to having a GRUB style bootloader - for a production machine in a datacenter that's a nice thing to have.
can you add a delay(5); or delay(10); before grub_main(); in main/filo.c and see if that helps?
On Fri, May 12, 2006 at 02:44:12AM +0200, Stefan Reinauer wrote:
- Ward Vandewege ward@gnu.org [060512 02:16]:
On Fri, May 12, 2006 at 01:13:20AM +0200, Stefan Reinauer wrote:
Does it work with the etherboot filo btw?
Yes; that's what I've been using. But it _only_ works if I guarantee at least 3 to 4 seconds of bootup delay; that's why I have the AUTOBOOT_DELAY set to 5. But that doesn't work for Filo 0.5 - maybe it tries to find the disks before doing the AUTOBOOT_DELAY?
Yes, it immediately tries to load the menu.lst file. If you dont want a grub style menu you can disable USE_GRUB to get the old behavior
Actually, I was looking forward to having a GRUB style bootloader - for a production machine in a datacenter that's a nice thing to have.
can you add a delay(5); or delay(10); before grub_main(); in main/filo.c and see if that helps?
Yes, delay(5) does the trick. Maybe this could be made into a configurable parameter?
Thanks, Ward.
this problem goes back to our very first boot some six years ago. Amazing.
ATA has outrageous boot delays. I'm sorry to see that SATA has them too. I have no good idea how to fix this, unless we can train FILO to know that we're coming into boot from power on reset.
I don't know that they are *that* outrageous when you consider what's happening. The problem is mostly physics and economics. Consider what it takes to spin a platter from a dead stop up to 7200 rpm and position a read head on the platter with nanometer accuracy across a fairly wide temp range. Now try to do it with hardware that costs less than $10.
If you want really fast boot times you need to boot off of non-mechancial media.
-- Richard A. Smith