From owner-freebsd-i386@FreeBSD.ORG Wed Aug 2 14:42:10 2006 Return-Path: X-Original-To: freebsd-i386@FreeBSD.org Delivered-To: freebsd-i386@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 376A216A4DE; Wed, 2 Aug 2006 14:42:10 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout2.pacific.net.au (mailout2.pacific.net.au [61.8.0.115]) by mx1.FreeBSD.org (Postfix) with ESMTP id B93AB43D72; Wed, 2 Aug 2006 14:42:04 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.2.163]) by mailout2.pacific.net.au (Postfix) with ESMTP id 35E68209356; Thu, 3 Aug 2006 00:42:03 +1000 (EST) Received: from epsplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailproxy2.pacific.net.au (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k72Eg01L004661; Thu, 3 Aug 2006 00:42:01 +1000 Date: Thu, 3 Aug 2006 00:42:00 +1000 (EST) From: Bruce Evans X-X-Sender: bde@epsplex.bde.org To: Jo Rhett In-Reply-To: <20060802205230.N90692@delplex.bde.org> Message-ID: <20060802234330.J1249@epsplex.bde.org> References: <200607252036.k6PKanFd072593@www.freebsd.org> <20060731191302.S1172@epsplex.bde.org> <6EFF87DF-280C-402C-8C2A-10F3144CF41F@svcolo.com> <20060802205230.N90692@delplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: njl@FreeBSD.org, freebsd-gnats-submit@FreeBSD.org, freebsd-i386@FreeBSD.org Subject: Re: i386/100831: sio ignores BIOS information about serial ports - bounty offered X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2006 14:42:10 -0000 On Wed, 2 Aug 2006, Bruce Evans wrote: > ... > I'm still surprised that ACPI seems to affect the low-level sio console. > The above boot messages are for high-level probes that don't do much > with the console except avoid clobbering it and print where it is. If > low-level console initialization used the correct flags hint but ACPI > moved the hint later, then things would be very confusing. The code > that avoids clobbering the decides where the console is by comparing > the port number already decided from the flags earlier by lower-level > code, while the code that prints where the console is use the current > flags. If ACPI moves the flags hint late, then moving this hint to > a consistently wrong port in device.hints like I suggested above would > fix it for non-console flags but break it for most console flags. > Non-console flags are rarely set so using the wrong flags hint would > rarely affect non-consoles. In fact, ACPI doesn't affect the low-level console. The low-level unit and port are set to 0 and 0x3f8 here even after the swap. This is consistent with with what you reported: >* In the middle of the boot process, right after saying "Mounting ", >* com1 becomes com2 and vice versa. The console output suddenly starts going >* to Serial A -- which is connected to a modem. Not useful. >* During the shutdown process, console output reverts to the proper com1 >* assignment. I missed that the switch occurs quite late. I think it doesn't occur for the boot messages before "Mounting " and doesn't occur at all for low-level messages from kernel printfs (messages in the shutdown are a special case of these). I now think I understand the bug: - low-level console output works because low-level initialization just uses the hints and confusion between unit numbers later doesn't cause any relevant problems - high-level output doesn't work because low-level initialization decides the unit number for both the low level and the high level. It is typically 0 for port 0x3f8. High level i/o is then done on a different physical device (perhaps a nonexistent one) if high level initialization associates the relevant port with a different unit number. ACPI does this for swapped ports. ACPI also leaves the flags hint on the unit number specified in device.hints. This gives less obvious bugs. So only a limited workaround seems to be possible. There is currently no way to control ACPI's assignment of unit numbers, so device.hints must match that assignment. ACPI will use BIOS list order which associates unit 1 with port 0x3f8 in your preferred configuration. device.hints must match that to avoid later confusion but can't affect the unit numbers. You could keep COM1 == 0x3f8 in the boot loader and outside of FreeBSD but would have to swap unit numbers in device.hints and in all references to {tty,cua}d[0-1] in FreeBSD. Consoles actually cause the fewest problems here, since they can be refered to without using a unit number in most places and nothing except device.hints (or the driver) should need to be changed to make the references consistent. Bruce