Lucky Green wrote:
> I have a dual PIII Intel L440gx+ (VA Linux) server. I am running CURRENT
> cvsupped a few hours ago.
> 
> This motherboard provides access to the BIOS via sio1. When booting, the
> serial BIOS shows everything that's happening until the point of booting
> the kernel (where it seems to switch video modes to have a bright white
> character set rather than the dull white/grey characters used
> initially).

I've seen this as well, FWIW.  A previous employer had the same
BIOS, and (mostly) refused to enable it in serial console mode,
to "hide" the fact that their product was based on commodity PC
hardware (they weren't fooling anyone but themselves).

This is actually an escape sequence.  I don't know why the BIOS
stuffs out this, but the fix is to use Windows Telnet, which
emulates a VT102, rather than FreeBSD Telnet in an xterm, which
emulates an xterm.  8-(.


> 1) Is there a way to prevent the FreeBSD kernel from ever witching into
> this different video mode, thus allowing me to continue to use the
> built-in serial terminal? The machine is a headless server, I don't care
> if video works as long as I can pull out a serial terminal.

It's not a FreeBSD thing, it's a BIOS thing.  You can hack xterm to
ignore "ESC" followed by anything followed by "m" (mode switch), and
it will hide the problem.

Normally, if there's no video card and no keyboard, FreeBSD will
come up on the serial console, if you have set the console bit on
the sio flags line in your kernel config.  See "LINT" or "NOTES"
for details, depending on which version you are using.

> sio0: configured irq 4 not in bitmap of probed irqs 0
> sio0: port may not be enabled

in the BIOS.

> sio0 port 0x3f8-0x3ff irq 4 on acpi0
> sio0: type 16550A
> sio1: configured irq 3 not in bitmap of probed irqs 0
> sio1: port may not be enabled

in the BIOS.

> sio1 port 0x2f8-0x2ff irq 3 on acpi0
> sio1: type 16550A
> --------
> While Google shows several other users seeing same output, I have been
> unable to find a post that clearly explained what the cause of this "not
> in bitmap" error is.

An explicit avoidance of resources which may be shared with MACH32
devices, which erroneosly leave some I/O ports enabled that should
only be enabled if the chipset is in a particular mode.  The result
is that if you probe for a second or third serial port on machines
with PALs that emulate the chipset, you get your video stomped.

-- Terry

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to