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: Wed, 2 Aug 2006 22:25:53 +1000 (EST)

 On Tue, 1 Aug 2006, Jo Rhett wrote:
 
 >> On Tue, 25 Jul 2006, Jo Rhett wrote:
 >>> 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.
 >
 > On Jul 31, 2006, at 2:55 AM, Bruce Evans wrote:
 >> I think you just need to swap the ports in /boot/device.hints?  Consoles
 >> are mostly low-level, and console initialization is very low level.
 >> The initialization is supposed to run before ACPI, etc. have had a
 >> chance to change the resource values dynamically (so that ACPI, etc.
 >> can print messages and otherwise be debugged), so when sio console
 >> initialization uses the apparently-higher-level resource access functions
 >> it is actually just using the hints, so the hints had better be correct
 >> -- they are more than hints.
 >
 > The hints are normal/standard but not working.  Here's proof:
 >
 > root at arran 23# grep sio device.hints
 > hint.sio.0.at="isa"
 > hint.sio.0.port="0x3F8"
 > hint.sio.0.flags="0x10"
 > hint.sio.0.irq="4"
 > hint.sio.1.at="isa"
 > hint.sio.1.port="0x2F8"
 > hint.sio.1.irq="3"
 >
 > root at arran 24# dmesg |grep sio
 > sio0: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 flags 0x10 on acpi0
 > sio0: type 16550A, console
 > sio1: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 on acpi0
 > sio1: type 16550A
 >
 > Heh?  Hints says 0x3f8 should be sio0 and console...
 
 I can duplicate this.  After swapping vanilla com ports in the BIOS on
 an A7N8X-E (Asus nForce2), ACPI in the 6.0-RELEASE kernel uses the flags
 hint but not the port or irq hints), gives the same inconsistent
 configuration:
 
 sio0: irq maps: 0x821 0x829 0x821 0x821
 sio0: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 flags 0x90 on acpi0
 sio0: type 16550A
 sio1: irq maps: 0x821 0x831 0x821 0x821
 sio1: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 on acpi0
 sio1: type 16550A
 
 I think this indicates a workaround.  Just configure sio1 with flags 0x90
 in device.hints.  I think acpi will use this hint but still ignore the
 others, so you would end up with the console port on the right hardware.
 The unit numbers of high-level sio ports ({cua,tty}d[0-1]) would be swapped
 but this wouldn't matter at all if you only the console port for a console.
 
 I think the fix for ACPI (and/or other "buses") would involve matching
 on all relevant hints for a given unit number.  The port number is clearly
 relevant here (it is still "at" isa like device.hints says, although the
 above says "on acpi").  However, the irq number is irrelevant.
 
 >> I don't know exactly what happens with ACPI.  Ideally, ACPI should set
 >> the resource values to match the BIOS, and this might involve ignoring
 >> most hints and this changing the values from their defaults, but for
 >> consoles any changes in the values would be wrong and might result in
 >> the high-level console (/dev/console) being attached to a different
 >> device than the low-level console (the one used for kernel printfs).
 >
 > It appears that ACPI is setting the sio order to match the order that the 
 > BIOS lists them, which is completely arbitrary and downright wrong.
 
 Yes, the list order is bogus, but not very different from bus and/or
 probe order which tends to move disk drives around.  Sio console
 configuration itself is documented to depend on a list order, but this
 was broken long ago.  Partial fix for the documentation but not the bug:
 
 % Index: NOTES
 % ===================================================================
 % RCS file: /home/ncvs/src/sys/conf/NOTES,v
 % retrieving revision 1.1233
 % diff -u -2 -r1.1233 NOTES
 % --- NOTES	22 Jun 2004 22:02:57 -0000	1.1233
 % +++ NOTES	7 Apr 2005 20:27:21 -0000
 % @@ -1520,10 +1520,18 @@
 %  #	0x10	enable console support for this unit.  Other console flags
 %  #		(if applicable) are ignored unless this is set.  Enabling
 % -#		console support does not make the unit the preferred console.
 % -#		Boot with -h or set boot_serial=YES in the loader.  For sio(4)
 % +#		console support does not make a serial device the
 % +#		preferred console.
 % +#		Boot with -h or set boot_serial=YES in the loader for that.
 % +#		For sio(4)
 %  #		specifically, the 0x20 flag can also be set (see above).
 %  #		Currently, at most one unit can have console support; the
 % -#		first one (in config file order) with this flag set is
                  ^^^^^      ^^^^^^^^^^^^^^^^^^^^
 % -#		preferred.  Setting this flag for sio0 gives the old behaviour.
 % +#		last one (in unit number order) that has the 0x10 flag set
                  ^^^^      ^^^^^^^^^^^^^^^^^^^^
 % +#		is selected.
 % +#		Setting the 0x20 flag for _any_ sio unit that also has the
 % +#		0x10 flag set then makes the selected unit the preferred
 % +#		console.
 % +#		Setting the 0x40 flag for an sio unit cancels any settings
 % +#		of the 0x10 and 0x20 flags (and most other flags) for that
 % +#		unit.
 %  #	0x80	use this port for serial line gdb support in ddb.  Also known
 %  #		as debug port.
 
 This is missing documentation of the breakage of the search over all entries
 in the config file.  The search is now limited unit numbers 0-15.
 
 In other words, precedence was determined by config file list order
 but is now determined by inverse unit number order except unit numbers
 >= 16 are now ignored.  These bugs make putting an 0x10 flag on more
 than 1 port (with 0x20 to give extra precedence) even less useful than
 before.  It used to be easy to control the order by moving lines in
 the config file, but unit numbers depend on hardware or firmware
 configuration which is harder to change.
 
 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.
 
 Bruce