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
