i386/100831: sio ignores BIOS information about serial ports - bounty offered

[Bruce Evans]

The following reply was made to PR i386/100831; it has been noted by GNATS.

From: Bruce Evans <bde at zeta.org.au>
To: Jo Rhett <jrhett at svcolo.com>
Cc: freebsd-gnats-submit at FreeBSD.org, freebsd-i386 at FreeBSD.org,
        njl at FreeBSD.org
Subject: Re: i386/100831: sio ignores BIOS information about serial ports -
 bounty offered
Date: Thu, 3 Aug 2006 00:42:00 +1000 (EST)

 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