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
