From owner-freebsd-stable@FreeBSD.ORG Tue Oct 24 14:41:47 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5009216A40F for ; Tue, 24 Oct 2006 14:41:47 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from sccrmhc15.comcast.net (sccrmhc15.comcast.net [204.127.200.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id D117D43D5F for ; Tue, 24 Oct 2006 14:41:35 +0000 (GMT) (envelope-from jdc@koitsu.dyndns.org) Received: from icarus.home.lan (c-67-174-220-97.hsd1.ca.comcast.net[67.174.220.97]) by comcast.net (sccrmhc15) with ESMTP id <2006102414413401500mc578e>; Tue, 24 Oct 2006 14:41:34 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 264291FA037; Tue, 24 Oct 2006 07:41:34 -0700 (PDT) Date: Tue, 24 Oct 2006 07:41:34 -0700 From: Jeremy Chadwick To: Vivek Khera Message-ID: <20061024144134.GA72596@icarus.home.lan> Mail-Followup-To: Vivek Khera , FreeBSD Stable References: <6196E612-1611-4D81-BF50-8E54DED00480@khera.org> <911B338C-38E0-4952-986C-F9DBC82E99BE@lassitu.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-PGP-Key: http://jdc.parodius.com/pubkey.asc User-Agent: Mutt/1.5.13 (2006-08-11) Cc: FreeBSD Stable Subject: Re: kernel ignores kenv comconsole_speed? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2006 14:41:47 -0000 On Tue, Oct 24, 2006 at 09:41:57AM -0400, Vivek Khera wrote: > >Am 23.10.2006 um 17:46 schrieb Vivek Khera: > >>On Oct 20, 2006, at 6:59 AM, Stefan Bethke wrote: > >>>I have -DS115200 in /boot.config, and boot and loader are happily > >>>using this speed. However, the kernel appears to be hardwired to > >>>9600. > >> > >>I've only ever gotten it to work when /boot.config looks like "-D - > >>S115200". I don't think you can merge the -S flag with the > >>others, at least according to my read of the man page. > > > >As I said, boot and loader are happily using 115200, but the kernel > >uses the compiled-in default. I'll file a PR the next few days, > >hopefully with a patch. > > As I said, "works for me". I wonder what it is you are going to > patch? Did you try it with the separate -S option? Did it work? I think what Stefan refers to is the complex nature of how the serial port is initialised/"tinkered with" in stages. boot0, boot2/loader, and the kernel all mess with the serial port, depending upon numerous aspects (/boot.config for boot0, loader.conf for boot2/loader, and CONSPEED in one's kernel config). Based upon what I've seen (and this is somewhat historic; this may have been changed within the past couple of years): * If you're using -S115200 in boot.config, or set BOOT_COMCONSOLE_SPEED=115200 in make.conf, boot0 will initialise the serial port to 115200. Otherwise, 9600. * Using "comconsole" in loader.conf for boot2/loader doesn't change speed of the serial port (AFAIK), but it does do some internal setup/configuration prior to the kernel loading. Just making note of that here. * If you've set CONSPEED=115200 in your kernel config, once the kernel loads, it'll initialise the serial port and use 115200. Otherwise, 9600. (This also appears to have the side-effect of limiting the "maximum serial port speed" possible on that serial port to whatever CONSPEED is. This may have been changed recently, as I've seen proof of CONSPEED defaulting to 9600 and being able to do things like tip -115200 or edit /etc/ttys and use std.115200 without any issues) What I'd like to propose is similar to Stefan's recommendation: is there any way possible to: * Not touch the serial port AT ALL, EVER (in boot0, boot2/loader, or the kernel) -- so that systems which have BIOS-level serial console/serial redirection will work? On all of our Supermicro boxes, the BIOS serial redirection works fine until some code touches the serial port. Once that happens, the interrupt the BIOS has tied itself to gets munged in some bad way, which results in the serial port no longer working. (Using hint.sio.0.disabled="1" and hint.sio.1.disabled="1" does not address my above request. The kernel still does something with the serial ports) -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB |