Re: L440gx+ serial BIOS needs text mode
On Mon, 3 Feb 2003, Terry Lambert wrote: Lucky Green wrote: However, the Intel L440gx+ motherboard I have (it came in a VA Linux rackmount) seems to have a separate CPU performing all kinds of monitoring tasks, watchdog, etc, so I was hoping this separate CPU was actually performing the serial console task. According to Doug's Intel page: http://people.freebsd.org/~dwhite/ipmi/setup_intel_scb2.html It's possible that it is, and that what's happening is some probe is writing to the port address on the I/O bus, causing the problem. If this is the case, then the only way to deal with it is to write a real driver for the thing (not the user space driver), and have the kernel claim it early, which would (should) keep other drivers from trying to poke it in the eye to see if their own hardware is there. That'd be nice if the L440GX+ was IPMI compliant. It isn't. :-) You're better off trying to use the intpm driver to talk to the old-style monitoring chips. Several IPMI features came from features implemented on the BMC on the L440GX, but it still uses the proprietary smbus interface. I never fiddled with the BMC features of the L440GX board. Linux's monitoring driver does talk to it though, you might be able to port it over. On the current generation Intel boards, serial redirection is handled by the BIOS. Once the kernel starts and the kernel takes over output, that redirection ceases to function. By that point, though, you have the usual FreeBSD serial console facilities and thus have a smooth transition. I suspect the same applies for any other Intel motherboard that supports serial redirection. You can confirm support for serial redirection by downloading the Technical Product Specifications for the Intel board you're interested in through support.intel.com. We have Tyan boards at my current employer with serial redirection and they work the same way. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: L440gx+ serial BIOS needs text mode
On Tue, 4 Feb 2003, Andrew Gordon wrote: - On the latest machines featuring 'serial over LAN', you can persuade the management CPU to subvert the serial port and pass the data over one of the ethernet ports. This seems to use a proprietary protocol, but if you have one Windows machine somewhere with the Intel management software loaded on it, you can use that to proxy the protocol for any number of managed machines - ie. telnet to port 623 on the Windows machine, then connect back to the target machine and get attached to the serial console (and so get a FreeBSD login, if that's what is running on COM2). I'd love to get the spec on this -- its a proprietary Intel feature and they won't cough up the spec unless you're a high volume integrator or have money and NDAs. - Medium-aged machines seem to have all the hardware to subvert the serial and ethernet ports, but won't do serial redirection apart from controlling the BIOS. Upgrading the BMC software didn't help on the machine I had in this category. No big loss for FreeBSD of course :) -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: L440gx+ serial BIOS needs text mode
Hello, The sense of the -P option was changed, and it makes it so you have to do extra work to get the console driver to do the right thing from inside FreeBSD proper, on a machine that could have its keyboard removed (or not). It's because the -h is implied, and it's a toggle. Oh, I see now. I didn't even noticed that option. Anyway, it was a particular problem with the SuperMicro motherboards with the AMI BIOS that's been the subject of the rest of this discussion (i.e. the ones that kick out the escape sequence at the end, for no good reason, except to screw up non-monochrome VTxxx emulators, and make it hard to use a UNIX box as the serial console). If I understood correctly, the original post was indeed a misunderstanding about the console redirection of the BIOS, which is only effective until the kernel boots. From that point one must enable the serial console in kernel and I think this is what was omitted. Don't know. I remember that I had no special problems with my L440GX when last tried this, only the above one (enable serial console, which is trivial). Anyways, thanks for the clarification! --[ Free Software ISOs - http://www.fsn.hu/?f=download ]-- Attila Nagy e-mail: [EMAIL PROTECTED] Free Software Network (FSN.HU)phone @work: +361 210 1415 (194) cell.: +3630 306 6758 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: L440gx+ serial BIOS needs text mode
Hello, 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 think you need to read the Serial Console section of the Handbook. You will find it here: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/serialconsole-setup.html The reason that you lost the serial console after the kernel started is that you BIOS from that point is launched to the nearest galaxy's trashcan via hyperspace, I mean is not functional. You have to set up the serial console. --[ Free Software ISOs - http://www.fsn.hu/?f=download ]-- Attila Nagy e-mail: [EMAIL PROTECTED] Free Software Network (FSN.HU)phone @work: +361 210 1415 (194) cell.: +3630 306 6758 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: L440gx+ serial BIOS needs text mode
From: Lucky Green [mailto:[EMAIL PROTECTED]] 1) Is there a way to prevent the FreeBSD kernel from ever switching 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. enable the comconsole option, set the baud rate. As for the colours etc, our machines have BIOS that do that too... I added a: set console=comconsole \ What's all this about then? It resets the console (to fix up the bios \ colour change), and outputs a banner. cr .( ^[c) to the start of /boot/loader.rc which is a vt100 reset code. This isn't a general purpose solution, but works for me. Our BIOS also changes the colour just as it exits, leaving it black on black :) --don To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: L440gx+ serial BIOS needs text mode
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
Re: L440gx+ serial BIOS needs text mode
Attila Nagy wrote: I think you need to read the Serial Console section of the Handbook. You will find it here: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/serialconsole-setup.html This is actually no longer accurate. PHK changed the defaults, and it no longer does correct autodetection from the boot loader config file. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: L440gx+ serial BIOS needs text mode
Hello, This is actually no longer accurate. PHK changed the defaults, and it no longer does correct autodetection from the boot loader config file. It may be my fault, but I could set up a serial console to a 5.0-RELEASE box using this page. 5.0 uses hints, I think this is the only change, I noted. What do you mean under autodetection? --[ Free Software ISOs - http://www.fsn.hu/?f=download ]-- Attila Nagy e-mail: [EMAIL PROTECTED] Free Software Network (FSN.HU)phone @work: +361 210 1415 (194) cell.: +3630 306 6758 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: L440gx+ serial BIOS needs text mode
Attila Nagy wrote: This is actually no longer accurate. PHK changed the defaults, and it no longer does correct autodetection from the boot loader config file. It may be my fault, but I could set up a serial console to a 5.0-RELEASE box using this page. 5.0 uses hints, I think this is the only change, I noted. What do you mean under autodetection? The sense of the -P option was changed, and it makes it so you have to do extra work to get the console driver to do the right thing from inside FreeBSD proper, on a machine that could have its keyboard removed (or not). It's because the -h is implied, and it's a toggle. See also the last two sentences of the documentation for the -D option, as well. I guess the intent was to force someone to put in the effort in FreeBSD itself to make the -D option work in the kernel, as well as in the boot loader. Anyway, it was a particular problem with the SuperMicro motherboards with the AMI BIOS that's been the subject of the rest of this discussion (i.e. the ones that kick out the escape sequence at the end, for no good reason, except to screw up non-monochrome VTxxx emulators, and make it hard to use a UNIX box as the serial console). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: L440gx+ serial BIOS needs text mode
From: Terry Lambert [mailto:[EMAIL PROTECTED]] ... Anyway, it was a particular problem with the SuperMicro motherboards with the AMI BIOS that's been the subject of the rest of this discussion (i.e. the ones that kick out the escape sequence at the end, for no good reason, except to screw up non-monochrome VTxxx emulators, and make it hard to use a UNIX box as the serial console). FYI, I've found that running under 'screen' fixes the problem with the odd escape sequences. One type of system we have puts out an escape sequence that is escape followed by 12 [. Not sure what that is :) The other works just great, except it switches to black on black just as it switches to the OS :) --don To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: L440gx+ serial BIOS needs text mode
Don Bowman wrote: Anyway, it was a particular problem with the SuperMicro motherboards with the AMI BIOS that's been the subject of the rest of this discussion (i.e. the ones that kick out the escape sequence at the end, for no good reason, except to screw up non-monochrome VTxxx emulators, and make it hard to use a UNIX box as the serial console). FYI, I've found that running under 'screen' fixes the problem with the odd escape sequences. One type of system we have puts out an escape sequence that is escape followed by 12 [. Not sure what that is :) The other works just great, except it switches to black on black just as it switches to the OS :) I guess we don't get to escape from the gory details... 8-). The 12 ['s are compressed into a single [, for fully ANSI compliant state machines, because they are in the wrong column of the old DEC-published ASCII chart to terminate an escape sequence, so the real question is what comes after the last [?. If you are seeing the 12 ['s, then your ANSI 3.64 state machine is not compliant. 8-). Back to the color change... The issue is support for the ISO ESC [ 3 n m and the ISO ESC [ 4 n m set foreground/set background color sequences. Windows Telnet doesn't support these, and neither does the terminal program that comes with Windows by default, but UNIX consoles do, and so does xterm, so running a dumb tty pipe like tip or cu on one of these passes them through. Running screen like you are, the emulation is a dumb VT100, and the escape sequences are interpreted by the screen program, instead of by the terminal window in which screen is running (screen is a terminal emulator that runs in a virtual terminal window, as an implementation detail for it being able to maintain multiple instances of display memory). The xterm didn't use to do this, by default, actually, and if you run your xterm with the -cm -dc options, or put: xterm.colorMode=false xterm.dynamicColors=false in your .Xdefaults file. I imagine this change is a result of some idiot wanting colorls to work by default, just as the BIOS spitting out the sequence was added at the request of some idiot to give people one more reason not to use UNIX. 8-). If it really bothers you, you can disassemble, modify, reassemble, and then re-flash your BIOS to get rid of it (it bothered me, but not enough to do that, just enough to make me make an icon that started xterm with the color disabling arguments, which ran telnet to the terminal server connected to the serial consoles in the server room as it's -e argument). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: L440gx+ serial BIOS needs text mode
Attila wrote: The reason that you lost the serial console after the kernel started is that you BIOS from that point is launched to the nearest galaxy's trashcan via hyperspace, I mean is not functional. You have to set up the serial console. A good answer on your average PC. (And perhaps even for this one :) However, the Intel L440gx+ motherboard I have (it came in a VA Linux rackmount) seems to have a separate CPU performing all kinds of monitoring tasks, watchdog, etc, so I was hoping this separate CPU was actually performing the serial console task. As I read it on page 64 of the manual (download from Intel), the second serial port is actually connected through a multiplexer to the Baseboard Management Controller (Dallas 82CH10) in my configuration. ftp://download.intel.com/support/motherboards/server/l440gx/254151-003.p df On page 36, the EMP 'always active mode' I selected suggests that console redirection remains active, and the OS can not see the port (or by extension take control of it). Which would seem to leaves the graphics mode issue. FreeBSD should be oblivious to the fact that this re-direction is even going on, but the kernel seems to do /something/ that impacts the built-in serial console. I guess the idea is to not have to use the FreeBSD software serial console, but use the hardware serial console out that comes with the motherboard. [FYI, there is a FreeBSD project to access the IMPI functions of these motherboards. http://people.freebsd.org/~dwhite/ipmi/, but it seems to address a slightly different question. Thanks in advance, --Lucky Green To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: L440gx+ serial BIOS needs text mode
Lucky Green wrote: However, the Intel L440gx+ motherboard I have (it came in a VA Linux rackmount) seems to have a separate CPU performing all kinds of monitoring tasks, watchdog, etc, so I was hoping this separate CPU was actually performing the serial console task. According to Doug's Intel page: http://people.freebsd.org/~dwhite/ipmi/setup_intel_scb2.html It's possible that it is, and that what's happening is some probe is writing to the port address on the I/O bus, causing the problem. If this is the case, then the only way to deal with it is to write a real driver for the thing (not the user space driver), and have the kernel claim it early, which would (should) keep other drivers from trying to poke it in the eye to see if their own hardware is there. It may also be that Intel has done the Metolius thing that Doug has indicated that they are pushing on his web page. If that's true, then the thing to do is to not load acpi.ko, and see if that fixes it for you. As I read it on page 64 of the manual (download from Intel), the second serial port is actually connected through a multiplexer to the Baseboard Management Controller (Dallas 82CH10) in my configuration. ftp://download.intel.com/support/motherboards/server/l440gx/254151-003.p df That's page 64 in the document, which is page 76 in the PDF reader, not page 64 in the PDF reader, which is the mechanical specification. 8-). On page 36, the EMP 'always active mode' I selected suggests that console redirection remains active, and the OS can not see the port (or by extension take control of it). 5.3.5 #3 suggests the same thing, on page 64[76]. I guess the real question is whether or not ``the O/S cannot see the port'' is true or not. FreeBSD's serial port probing is, uh, aggressive. It could have poked it and changed settings (e.g. from 19200, the EMP speed that the document wants to 9600, which FreeBSD wants, etc.). Which would seem to leaves the graphics mode issue. FreeBSD should be oblivious to the fact that this re-direction is even going on, but the kernel seems to do /something/ that impacts the built-in serial console. Does it work in Linux? FreeBSD's console driver does flip the video mode, and that could be an issue, if the hardware operates on the basis of screen scraping. There are a number of serial console cards that work by noticing differences in screen memory contents, and then dumping the necessary escape-sequenced byte-stream out to make a VT100 screen contain the same contents in the same locations (quoted because console displays in PC's are 25 lines and a real VT100 is only 24 lines). If it's a screen scraper, then you should look at PCVT or some other alternate console driver, or you're not going to get what you want, as the thing loses it's marbles after the first video mode change. Or you could just interfere with the detection code in the current console driver. I guess the idea is to not have to use the FreeBSD software serial console, but use the hardware serial console out that comes with the motherboard. Typical rack-mount use. That's what most of the screen-scraper cards try to do. FreeBSD by default isn't screen-scraper friendly. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: L440gx+ serial BIOS needs text mode
On Mon, 3 Feb 2003, Lucky Green wrote: However, the Intel L440gx+ motherboard I have (it came in a VA Linux rackmount) seems to have a separate CPU performing all kinds of monitoring tasks, watchdog, etc, so I was hoping this separate CPU was actually performing the serial console task. As I read it on page 64 of the manual (download from Intel), the second serial port is actually connected through a multiplexer to the Baseboard Management Controller (Dallas 82CH10) in my configuration. ftp://download.intel.com/support/motherboards/server/l440gx/254151-003.p df I've used several generations of these intel boards, though not the exact one which you have, most recently the se7500wv2. All of them are more conventional than it might appear: - The 'screen scraper' for serial access to the BIOS works from software on the main (i386) CPU. The earlier machines didn't have on-board video, so mapped in some ordinary RAM to the video area if you ran them without a video card fitted; later machines have video hardware and the console redirection polls this RAM. Either way, it's BIOS software generating ANSI escapes out of the ordinary serial port, and this stops when the OS boots. - The management CPU sits between the external serial port connector and the UART in the main CPU's chipset. Hence the OS running on the main CPU always thinks it's got a standard COM port, it's just a question of whether data sent to/from that port makes it to the external connector or gets subverted by the management CPU. - On the latest machines featuring 'serial over LAN', you can persuade the management CPU to subvert the serial port and pass the data over one of the ethernet ports. This seems to use a proprietary protocol, but if you have one Windows machine somewhere with the Intel management software loaded on it, you can use that to proxy the protocol for any number of managed machines - ie. telnet to port 623 on the Windows machine, then connect back to the target machine and get attached to the serial console (and so get a FreeBSD login, if that's what is running on COM2). - Medium-aged machines seem to have all the hardware to subvert the serial and ethernet ports, but won't do serial redirection apart from controlling the BIOS. Upgrading the BMC software didn't help on the machine I had in this category. Disclaimer: the above is just from playing with the machines and reading the documentaton, so I may be wrong. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
