This is with fallback and normal LinuxBIOS images on E7500 mainboards. They're loaded with the identical etherboot image, 5.1.2rc4.eb5.
On fallback, etherboot goes right to the IDE disk after finding no good ethernet link:
Etherboot 5.1.2rc4.eb5 (GPL) ELF64 ELF (Multiboot) for [EEPRO100][IDE] Relocating _text from: [00024524,00034674) to [7ffefeb0,80000000) CPU 2469 Mhz Boot from (N)etwork (D)isk (F)loppy or from (L)ocal? Probing pci...Found EEPRO100 ROM address 0x0000 [EEPRO100]The PCI BIOS has not enabled this device! Updating PCI command 0003->0007. pci_bus 04 pci_device_fn 10 Ethernet addr: 00:30:48:23:B8:2D Valid link not established
Probing isa... Probing pci...Found IDE ROM address 0x0000 [IDE]The PCI BIOS has not enabled this device! Updating PCI command 0003->0007. pci_bus 00 pci_device_fn F9 PCI latency timer (CFLT) is unreasonably low at 0. Setting to 32 clocks. disk-1 16000k cap: 0200
Searching for image... ................................(ELF)... Loading image.
On normal, etherboot just loops forever until I tell it to go to disk:
Etherboot 5.1.2rc4.eb5 (GPL) ELF64 ELF (Multiboot) for [EEPRO100][IDE] Relocating _text from: [00024524,00034674) to [7ffefeb0,80000000) CPU 2470 Mhz Boot from (N)etwork (D)isk (F)loppy or from (L)ocal? Probing pci...Found EEPRO100 ROM address 0x0000 [EEPRO100]The PCI BIOS has not enabled this device! Updating PCI command 0003->0007. pci_bus 04 pci_device_fn 10 Ethernet addr: 00:30:48:23:AD:1B Valid link not established
Probing isa... No adapter found <sleep> Boot from (N)etwork (D)isk (F)loppy or from (L)ocal?
Note there is no 'probing pci' step.
If I hit 'D' for disk it does probe pci:
Boot from (N)etwork (D)isk (F)loppy or from (L)ocal? D
Probing pci...Found IDE ROM address 0x0000 [IDE]The PCI BIOS has not enabled this device!
I'm curious if this is correct behaviour (in which case I need to change it) or some unintended consequence of a variable setting (CMOS)? Why would etherboot probe or not probe PCI? Why would telling it to load from disk cause it to then probe PCI?
I'm guessing I'm not the first person who will hit this, hence this message to various lists.
Thanks
ron
Ronald G Minnich rminnich@lanl.gov writes:
This is with fallback and normal LinuxBIOS images on E7500 mainboards. They're loaded with the identical etherboot image, 5.1.2rc4.eb5.
On fallback, etherboot goes right to the IDE disk after finding no good ethernet link:
[snip]
On normal, etherboot just loops forever until I tell it to go to disk:
[snip]
It is a bug. And it is fixed in the etherboot source tree. Ron for your cluster I just need to make a new build of LinuxBIOS and put the new etherboot in there. The boot order code was just broken, and I don't know how it lasted as long as it did.
Ron can you check to see what your boot order is. As I recall it only happened with boot_first=Network boot_second=Network boot_third=Network
In which case there is a work around available. I need to track this down before we start building up Pink.
I'm guessing I'm not the first person who will hit this, hence this message to various lists.
The code was fixed a little while ago, when I completed the e1000 support. As the bug also it prevented fail over from one nic to another.
Eric
Eric, which etherboot do you recommend I get at this point? just cvs update from the latest?
ron