boot logo/menu corruption
koitsu at FreeBSD.org
Fri Aug 10 11:24:08 PDT 2007
On Fri, Aug 10, 2007 at 11:53:21AM -0400, Charles Shannon Hendrix wrote:
> Does anyone have any idea why the second/third stage has trouble?
> Is it possible this is because the loader is writing to the console and
> the video BIOS is doing it also?
A purely speculative guess: depending upon how you have boot0
boot2/loader configured, they may or may not touch the serial port (try
to initalise it) and do some funky stuff with some interrupts.
Serial console output at the BIOS level makes the BIOS tie in to a
particular interrupt (I can't remember which one, INT 13h?), and it
starts to act as a middle-man (although I think the behaviour depends
upon how the BIOS code is written; some may hijack the interrupt and
serial port entirely, while others may act like the equivalent of a
read-write-capable network tap).
For example: on most of my Supermicro boards, there's a BIOS option
named something like "Leave Agent Running After Boot". By default this
is OFF, which means you'll get BIOS-level serial console during the
intial POST and BIOS status screen, but nothing past that -- unless the
OS (or bootloader) supports it. If you turn it ON, the BIOS attempts to
handle all output from start (boot) to finish (pre and post OS).
With most of the boards, if I set the Leave Agent Running option to ON,
the instant FreeBSD hits boot2/loader I lose all serial output from that
point on. On one board (different model than the others), if I do the
same, it works all the way through boot0/boot2/loader, but the instant
the kernel begins loading, there's no more serial output.
The doubling of characters might be explained by either sporadic
interrupt issues (since the BIOS and FreeBSD may both be handling the
requests). I cannot explain the escape character problem you're seeing,
but possibly your BIOS manufacturer is filtering those "for safety"
(it's very possible). The missing characters may be due to the
interrupt issue metnioned above, or incorrect handshaking (or lack
Here's the method I use on our systems here which have BIOS-level serial
redirect, which gets me the ability to control the BIOS remotely, serial
support in boot2/loader, serial output while the kernel loads, and the
ability to log in to the box via serial console (getty on serial port).
I've never cared about boot0. Note that we use true CTS/RTS handshaking
* Enable "Console Redirect"
* Point "Console Redirect" to COM1, 115200 8N1, VT100 or ANSI emulation
* Set "Console Redirect" to use RTS/CTS handshaking
* Disable "Leave Agent Running After Boot"
* Put the following into /boot.config:
Can replace -h with -P if one wants serial console to be disabled
when a keyboard is plugged in to the box.
* Edit /etc/make.conf and add the following:
This appears to make the kernel initialise the serial port when loaded
to use 115200. (Always seemed to me like this was an unnecessary
requirement, since I'd rather the kernel not tinker with any of that
and just let boot2/loader handle the initialisation)
* Rebuild world (follow all instructions in /usr/src/Makefile), and
of course install it.
* Before the final reboot, do disklabel -B on the boot slice, e.g.
disklabel -B ad0s1.
Hope this helps.
| Jeremy Chadwick jdc at parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. PGP: 4BD6C0CB |
More information about the freebsd-stable