From owner-freebsd-stable@FreeBSD.ORG Fri Feb 22 04:41:22 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5C009C2D; Fri, 22 Feb 2013 04:41:22 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id BE44469A; Fri, 22 Feb 2013 04:41:21 +0000 (UTC) Received: from ur.dons.net.au (ppp14-2-9-156.lns21.adl2.internode.on.net [14.2.9.156]) (authenticated bits=0) by cain.gsoft.com.au (8.14.4/8.14.3) with ESMTP id r1M4f6iV065668 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 22 Feb 2013 15:11:11 +1030 (CST) (envelope-from doconnor@gsoft.com.au) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: IPMI serial console From: "Daniel O'Connor" In-Reply-To: <20130222042907.GA75261@icarus.home.lan> Date: Fri, 22 Feb 2013 15:11:05 +1030 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51269ABD.2040308@gmail.com> <2AF6F8E4-A45E-4D4C-9232-FF09AD4A3641@gsoft.com.au> <5126A3A1.1030208@gmail.com> <64293C7A-038A-4EA1-B394-9E80CFCBC14F@gsoft.com.au> <20130221230001.GF2598@kib.kiev.ua> <20130221232929.GA91708@icarus.home.lan> <3FE71C9F-29B2-48F5-9A51-D312B1803E14@gsoft.com.au> <20130222013258.GA93350@icarus.home.lan> <9F6E4B36-0C89-4409-91FB-08CC90848D23@gsoft.com.au> <20130222042907.GA75261@icarus.home.lan> To: Jeremy Chadwick X-Mailer: Apple Mail (2.1499) X-Spam-Score: 0.163 () BAYES_00,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.67 on 203.31.81.10 Cc: Konstantin Belousov , freebsd-stable@freebsd.org, Navdeep Parhar , John Baldwin X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 04:41:22 -0000 On 22/02/2013, at 14:59, Jeremy Chadwick wrote: >> This breaks the boot for me, boot.config has to contain more than = just >> flags it seems. In any case I believe setting boot_multicons and >> boot_serial is the same as -Dh. Not sure about the baud rate though. >=20 > Then someone broke something (parser or something else). This has > always, *always* worked (just flags). The last time I verified it was > with the release of 9.0-RELEASE. I do have a system I could test this > on, but I'd need to find a null modem cable first. Weird, this is 9.1 - I wouldn't expect any changes.. > I have seen some MFCs that touch those bits in the bootloader, but = from > my memory it didn't touch anything other than supporting /boot/config = as > an alternate location to the classic /boot.config file. I would be = very > surprised if this broke it. >=20 > I can assure you that those were the only flags that were needed, and = in > exactly that syntax. Even the Handbook has this in it, as well as > boot(8). >=20 > I believe your explanation of boot_multicons and boot_serial are = correct > and do correlate with -D and -h. I could look at the bootstrap code = to > verify. The options are described in loader(8) but not = loader.conf(5). >=20 > The drawback to using the /boot/loader.conf variables is that you = won't > get boot2 output because loader is what reads /boot/loader.conf, not > boot2. Thus you lose the ability to deal with the system via serial = at > the boot2 stage. For me, this has always been a deal-breaker. This = is > why I always advocate /boot.config. (Note to readers: if I'm wrong > about this, please correct me, and point me to the relevant code) Ah that is a fair point. >> BOOT_COMCONSOLE_SPEED=3D115200 BOOT_COMCONSOLE_PORT=3D0x3e8 and now = the >> loader talks to me without VGA to serial redirection. >=20 > Huzzah! Do you get output from the kernel now, or still just = bootstraps > and loader, then silence until getty runs? Sadly no, I just the loader then getty. >> I assumed that the separate NIC was to avoid this problem, however I >> have since found that the default on the SM boards I looked at is to >> use the dedicated port otherwise share(!). So the worst of both >> worlds, hooray! >=20 > Depends on the board and the IPMI integration. Most of the newer = boards > (past 3-4 years) I've seen have a dedicated LAN port on their IPMI > add-on board; e.g. a dual-NIC motherboard has 2 NICs, then there's a = 3rd > NIC on the IPMI card/port. I have seen the shared ones though, and > that's where the ASF stuff comes into play (ugh ugh ugh). I've always > avoided all the boards that have "on-board" IPMI of any sort. I have boards with 3 RJ45 ports, 1 IPMI & 2 normal (em devices). The = IMPI configuration has an option to use the dedicated port only, try = that first then on failure share em0, or share em0 only. The default is try the dedicate port then if that fails share em0 :( -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C