From owner-freebsd-current Mon Feb 3 12:50:19 2003 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0729137B401; Mon, 3 Feb 2003 12:50:17 -0800 (PST) Received: from heron.mail.pas.earthlink.net (heron.mail.pas.earthlink.net [207.217.120.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id A30A643E4A; Mon, 3 Feb 2003 12:50:10 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from pool0144.cvx21-bradley.dialup.earthlink.net ([209.179.192.144] helo=mindspring.com) by heron.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 18fnXV-0006uw-00; Mon, 03 Feb 2003 12:50:02 -0800 Message-ID: <3E3ED594.EC05289B@mindspring.com> Date: Mon, 03 Feb 2003 12:48:20 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Lucky Green Cc: freebsd-current@FreeBSD.ORG, dwhite@freebsd.org Subject: Re: L440gx+ serial BIOS needs text mode References: <002f01c2cbc0$22a2d010$6601a8c0@VAIO650> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4223004040b78597b2be9f15421e62b6c3ca473d225a0f487350badd9bab72f9c350badd9bab72f9c Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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 majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message