Dave Belfer-Shevett dbs@stonekeep.com writes:
We're in the process of deploying Linuxbios to boot a cluster of Opteron based blade servers. I built a new kernel, put it in /tftpboot after using:
mkelf-linux --rootdir=rom --ip=rom ./bzImage > vmlinuz.tyan
This is your first problem.
mkelf-linux does not know how to bypass the BIOS calls so it will not work under LinuxBIOS.
Please get mkelfImage 2.5
ftp://ftp.lnxi.com/pub/mkelfImage.
and cycled the blade. Wen booting, I get:
Searching for server (DHCP) Me: 192.168.1.200, Server: 192.168.1.200, Gateway 192.168.1.1 Loading 192.168.1.200:vmlinuz.tyan (ELF)... done
LinuxBIOS-1.1.62.0_Fallback [date date] starting... Unknown Trwt
I would not expect to see this message after a triple fault, but stranger things have happened.
Looking at an old message to this list, there's this snippet: http://www.mail-archive.com/linuxbios@clustermatic.org/msg03174.html
where the following line(s) are, in set_Trwt()... if ((clocks < DTH_TRWT_MIN) || (clocks > DTH_TRWT_MAX)) { die("Unknown Trwt"); }
What is this, and why is it happening?
I don't know the why. This bit is simply a sanity check that the information coming from your serial EEPROM on your dimms is fine.
Is there a patch needed for LinuxBIOS to work properly on modern Opterons?
One should not be needed.
Thanks, I'm in dire straights here, any help would be appreciated.
If you still have problems after you start using mkelfImage ask again.
Eric