Date: Thu, 3 Aug 2006 00:42:00 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Jo Rhett <jrhett@svcolo.com> 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 Message-ID: <20060802234330.J1249@epsplex.bde.org> In-Reply-To: <20060802205230.N90692@delplex.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>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <root-device>",
>* 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 <root-device>" 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060802234330.J1249>