From nobody@FreeBSD.org  Tue Jul 25 20:36:54 2006
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id F3D0616A4DE
	for <freebsd-gnats-submit@FreeBSD.org>; Tue, 25 Jul 2006 20:36:53 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (www.freebsd.org [216.136.204.117])
	by mx1.FreeBSD.org (Postfix) with ESMTP id CFD2B43D69
	for <freebsd-gnats-submit@FreeBSD.org>; Tue, 25 Jul 2006 20:36:49 +0000 (GMT)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (localhost [127.0.0.1])
	by www.freebsd.org (8.13.1/8.13.1) with ESMTP id k6PKanGA072594
	for <freebsd-gnats-submit@FreeBSD.org>; Tue, 25 Jul 2006 20:36:49 GMT
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.13.1/8.13.1/Submit) id k6PKanFd072593;
	Tue, 25 Jul 2006 20:36:49 GMT
	(envelope-from nobody)
Message-Id: <200607252036.k6PKanFd072593@www.freebsd.org>
Date: Tue, 25 Jul 2006 20:36:49 GMT
From: Jo Rhett <jrhett@svcolo.com>
To: freebsd-gnats-submit@FreeBSD.org
Subject: sio ignores BIOS information about serial ports - bounty offered
X-Send-Pr-Version: www-2.3

>Number:         100831
>Category:       i386
>Synopsis:       [sio] sio ignores BIOS information about serial ports - bounty offered
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    freebsd-i386
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Jul 25 20:40:14 GMT 2006
>Closed-Date:    Wed Oct 12 14:39:54 UTC 2011
>Last-Modified:  Wed Oct 12 14:39:54 UTC 2011
>Originator:     Jo Rhett
>Release:        6.0-REL
>Organization:
svcolo
>Environment:
FreeBSD arran 6.0-RELEASE FreeBSD 6.0-RELEASE #4: Fri Nov 11 13:29:33 PST 2005     root@barrel.svcolo.com:/usr/obj/usr/src/sys/GENERIC  i386
>Description:
For our motherboard, "Serial A" in hardwired on the board with a 9-pin
connector.  "Serial B" is a normal serial connector that can be wired
anywhere.  Rackable uses this connector to connect to their out-of-band
management interface.

So in the BIOS configuration, we assign COM1 = "Serial B" and COM2 =
"Serial A".  This works perfectly for the POST console redirection and
FreeBSD boot process.

/boot.config contains "-Dh" and /boot/loader.rc contains "console=comconsole"

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.

>How-To-Repeat:
Connect consoles to both com1 and com2.  Put "-Dh" in /boot.config and
"console=comconsole" in /boot/loader.rc.  Boot.  Observe that all console
output goes to the same port.

Go into BIOS. Change COM1 assignment from it's natural assignment to the
reverse.  Boot again.  Watch the console output change monitors in the
middle of the boot process.

>Fix:
sio needs to observe the BIOS flags.

Note that I've tested this on dozens of systems which different chipsets
and BIOSs and this appears to be true in all environments.  com1 only works
properly if it is assigned to the first serial port that the bios reports
to the system.

BOUNTY:  This problem is serious enough that SVcolo is willing to pay an
individual to determine the problem and get it committed to the main tree.
Contact me for more information.
>Release-Note:
>Audit-Trail:

From: Bruce Evans <bde@zeta.org.au>
To: Jo Rhett <jrhett@svcolo.com>
Cc: freebsd-gnats-submit@FreeBSD.org, freebsd-i386@FreeBSD.org
Subject: Re: i386/100831: sio ignores BIOS information about serial ports -
 bounty offered
Date: Mon, 31 Jul 2006 19:55:42 +1000 (EST)

 On Tue, 25 Jul 2006, Jo Rhett wrote:
 
 >> Description:
 > For our motherboard, "Serial A" in hardwired on the board with a 9-pin connector.  "Serial B" is a normal serial connector that can be wired anywhere.  Rackable uses this connector to connect to their out-of-band management interface.
 >
 > So in the BIOS configuration, we assign COM1 = "Serial B" and COM2 = "Serial A".  This works perfectly for the POST console redirection and FreeBSD boot process.
 >
 > /boot.config contains "-Dh" and /boot/loader.rc contains "console=comconsole"
 >
 > 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 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.
 
 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).
 
 Bruce

From: Jo Rhett <jrhett@svcolo.com>
To: Bruce Evans <bde@zeta.org.au>
Cc: freebsd-gnats-submit@FreeBSD.org, freebsd-i386@FreeBSD.org
Subject: Re: i386/100831: sio ignores BIOS information about serial ports - bounty offered
Date: Mon, 31 Jul 2006 08:30:53 -0700

 On Mon, Jul 31, 2006 at 07:55:42PM +1000, Bruce Evans wrote:
 > On Tue, 25 Jul 2006, Jo Rhett wrote:
 > >>Description:
 > >For our motherboard, "Serial A" in hardwired on the board with a 9-pin 
 > >connector.  "Serial B" is a normal serial connector that can be wired 
 > >anywhere.  Rackable uses this connector to connect to their out-of-band 
 > >management interface.
 > >
 > >So in the BIOS configuration, we assign COM1 = "Serial B" and COM2 = 
 > >"Serial A".  This works perfectly for the POST console redirection and 
 > >FreeBSD boot process.
 
 > I think you just need to swap the ports in /boot/device.hints?
 
 device.hints contains what you expect.  0x3f8 should be sio0, but its not.
 This is apparently ignored.
 
 > 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.
  
 Sure, but they aren't working.  That's the nature of this beast/bug.
 
 > 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).
 
 Exactly what I'm worried about.
 
 -- 
 Jo Rhett
 senior geek
 SVcolo : Silicon Valley Colocation

From: Jo Rhett <jrhett@svcolo.com>
To: Bruce Evans <bde@zeta.org.au>
Cc: freebsd-gnats-submit@FreeBSD.org, freebsd-i386@FreeBSD.org
Subject: Re: i386/100831: sio ignores BIOS information about serial ports - bounty offered
Date: Tue, 1 Aug 2006 13:59:44 -0700

 > 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@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@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 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.
 
 -- 
 Jo Rhett
 senior geek
 Silicon Valley Colocation
 

From: Jo Rhett <jrhett@svcolo.com>
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: i386/100831: [sio] sio ignores BIOS information about serial ports - bounty offered
Date: Tue, 1 Aug 2006 17:10:42 -0700

 This bug might have the subject changed to
 	"sio orders ports by BIOS order regardless of device.hints"
 
 -- 
 Jo Rhett
 senior geek
 Silicon Valley Colocation
 

From: Bruce Evans <bde@zeta.org.au>
To: Jo Rhett <jrhett@svcolo.com>
Cc: freebsd-gnats-submit@FreeBSD.org, freebsd-i386@FreeBSD.org,
        njl@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@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@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

From: Bruce Evans <bde@zeta.org.au>
To: Jo Rhett <jrhett@svcolo.com>
Cc: freebsd-gnats-submit@FreeBSD.org, freebsd-i386@FreeBSD.org,
        njl@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

From: Jo Rhett <jrhett@svcolo.com>
To: Bruce Evans <bde@zeta.org.au>
Cc: freebsd-gnats-submit@freebsd.org, freebsd-i386@freebsd.org,
        njl@freebsd.org
Subject: Re: i386/100831: sio ignores BIOS information about serial ports - bounty offered
Date: Wed, 2 Aug 2006 08:06:56 -0700

 On Thu, Aug 03, 2006 at 12:42:00AM +1000, Bruce Evans wrote:
 > 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.
  
 Okay, I'm going to restate this in really simple terms.  Tell me if I have
 it right.
 
 1. We can't/won't fix the sio0<->sio1 problem because fixing ACPI is hard
 
 2. The sio units are thus going to swap when entering high-level sio mode
 
 3. The workaround is to put flags 0x10 (or 0x90) on sio1
 
 4. There should be no ill effect from doing this.  Console will never break
 and go to the wrong port.
 
 #4 is crucial to us.  Many of these machines are completely unavailable to
 me for an emergency.  This console is our "last chance access"
 
 -- 
 Jo Rhett
 senior geek
 SVcolo : Silicon Valley Colocation

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

 On Wed, 2 Aug 2006, Jo Rhett wrote:
 
 > Okay, I'm going to restate this in really simple terms.  Tell me if I have
 > it right.
 >
 > 1. We can't/won't fix the sio0<->sio1 problem because fixing ACPI is hard
 
 _I_ can't/won't fix it because not just the above :-).  Swapping of consoles
 only could be fixed within the driver (so that ACPI is not involved and
 you don't have to change device.hints) since consoles have to be hard-wired
 in some way and the hints are good enough for wiring the unit number to
 the i/o address (provided it's an old ISA port -- otherwise hints based
 on the i/o address don't work).
 
 > 2. The sio units are thus going to swap when entering high-level sio mode
 >
 > 3. The workaround is to put flags 0x10 (or 0x90) on sio1
 
 It also needs the port numbers swapped (for consoles to work) and other hints
 swapped (to be consistent, so as to work if there is no ACPI so the other
 hints are actually used).
 
 > 4. There should be no ill effect from doing this.  Console will never break
 > and go to the wrong port.
 >
 > #4 is crucial to us.  Many of these machines are completely unavailable to
 > me for an emergency.  This console is our "last chance access"
 
 Yes, "should be".  The wiring should be fairly deterministic once you
 get it to work.  I think it will continue to work even if someone fixes
 (?) ACPI to prefer the hints order to the ACPI order.  However, it would
 break if someone fixes (?) ACPI to prefer the BIOS order to both the hints
 order and the ACPI order (I think ACPI is using its own order and doesn't
 know that you've swapped the order in the BIOS).
 
 I just happened to boot an early version of 5.x for other reasons, and
 notices that it doesn't print the flags for sio devices on acpi0.  This
 is because flags weren't propagated to sub-buses/devices at all until
 a year or two ago.  njl fixed this.  Not propagating flags mainly broke
 the non-console case since the console flags are mostly used at levels
 below the bus level.
 
 Bruce

From: Jo Rhett <jrhett@svcolo.com>
To: Bruce Evans <bde@zeta.org.au>
Cc: freebsd-gnats-submit@freebsd.org, freebsd-i386@freebsd.org,
        njl@freebsd.org
Subject: Re: i386/100831: sio ignores BIOS information about serial ports - bounty offered
Date: Wed, 2 Aug 2006 10:40:49 -0700

 > On Wed, 2 Aug 2006, Jo Rhett wrote:
 >> 1. We can't/won't fix the sio0<->sio1 problem because fixing ACPI  
 >> is hard
 
 On Aug 2, 2006, at 10:25 AM, Bruce Evans wrote:
 > _I_ can't/won't fix it because not just the above :-).  Swapping of  
 > consoles
 > only could be fixed within the driver (so that ACPI is not involved  
 > and
 > you don't have to change device.hints) since consoles have to be  
 > hard-wired
 > in some way and the hints are good enough for wiring the unit  
 > number to
 > the i/o address (provided it's an old ISA port -- otherwise hints  
 > based
 > on the i/o address don't work).
 
 Sorry, color me dumb.  I'm getting lost here.  The problem I was  
 observing is that device hints is being (mostly) ignored by ACPI and  
 thus this is the root problem to fix.  I'm not sure what you're  
 trying to say here.
 
 >> 2. The sio units are thus going to swap when entering high-level  
 >> sio mode
 >> 3. The workaround is to put flags 0x10 (or 0x90) on sio1
 >
 > It also needs the port numbers swapped (for consoles to work) and  
 > other hints
 > swapped (to be consistent, so as to work if there is no ACPI so the  
 > other
 > hints are actually used)
 
 Can you provide a clear list of instructions then?  I have no idea  
 what you mean by "port numbers swapped".  Swapped where?
 
 I was assuming
 	/boot.config has -Dh
 	/boot/loader.conf has console="comconsole"
 	/boot/device.hints comment out #hint.sio.0.flags="0x10"
 	/boot/device.hints add hint.sio.1.flags="0x10"
 	/etc/ttys - put a getty on ttyd1
 
 What am I missing?
 
 If I understand correctly, the boot loader compiled in option sio0 on  
 0x3f8 flags 0x10 will be in effect until the higher level sio driver  
 is loaded, at which point it reassigns all the ports based on ACPI  
 and device.hints and the two changes to device.hints above will take  
 effect, yes?
 
 >> 4. There should be no ill effect from doing this.  Console will  
 >> never break
 >> and go to the wrong port.
 >
 > Yes, "should be".  The wiring should be fairly deterministic once you
 > get it to work.  I think it will continue to work even if someone  
 > fixes
 > (?) ACPI to prefer the hints order to the ACPI order.  However, it  
 > would
 > break if someone fixes (?) ACPI to prefer the BIOS order to both  
 > the hints
 > order and the ACPI order (I think ACPI is using its own order and  
 > doesn't
 > know that you've swapped the order in the BIOS).
 
 I'm not sure I understand the difference.  The ACPI order is the  
 order that the BIOS presents them in when querying it via ACPI, yes?
 
 -- 
 Jo Rhett
 senior geek
 Silicon Valley Colocation
 

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

 On Wed, 2 Aug 2006, Jo Rhett wrote:
 
 >> On Wed, 2 Aug 2006, Jo Rhett wrote:
 >>> 1. We can't/won't fix the sio0<->sio1 problem because fixing ACPI is hard
 >
 > On Aug 2, 2006, at 10:25 AM, Bruce Evans wrote:
 >> _I_ can't/won't fix it because not just the above :-).  Swapping of 
 >> consoles
 >> only could be fixed within the driver (so that ACPI is not involved and
 >> you don't have to change device.hints) since consoles have to be hard-wired
 >> in some way and the hints are good enough for wiring the unit number to
 >> the i/o address (provided it's an old ISA port -- otherwise hints based
 >> on the i/o address don't work).
 >
 > Sorry, color me dumb.  I'm getting lost here.  The problem I was observing is 
 > that device hints is being (mostly) ignored by ACPI and thus this is the root 
 > problem to fix.  I'm not sure what you're trying to say here.
 
 Console drivers have to and do use the hints directly so as to work before
 bus stuff like ACPI is initializated.  After bus stuff is initialized, they
 could keep using the working configuration read from device.hints.  sio
 already does this in most places, but in one place it neither checks for
 nor fixes up inconsistencies caused by ACPI ignoring the hints.
 
 >>> 2. The sio units are thus going to swap when entering high-level sio mode
 >>> 3. The workaround is to put flags 0x10 (or 0x90) on sio1
 >> 
 >> It also needs the port numbers swapped (for consoles to work) and other 
 >> hints
 >> swapped (to be consistent, so as to work if there is no ACPI so the other
 >> hints are actually used)
 >
 > Can you provide a clear list of instructions then?  I have no idea what you 
 > mean by "port numbers swapped".  Swapped where?
 
 Since it is too hard to change ACPI to use the hints, change the hints to
 give the same configuration as ACPI will give.  For 2 ports, you've already
 swapped them in the BIOS, but ACPI doesn't see that so they must be swapped
 back in device.hints to match.  This loses the benefits of the swapping
 inside FreeBSD but keeps them outside of FreeBSD including in the boot loader.
 I don't know if this is enough for you or if the benefits of the swapping
 are larger enough for it to be worth doing when you lose them inside
 FreeBSD.
 
 > I was assuming
 > 	/boot.config has -Dh
 > 	/boot/loader.conf has console="comconsole"
 
 Not changes to booting -- it keeps using COM1.
 
 > 	/boot/device.hints comment out #hint.sio.0.flags="0x10"
 > 	/boot/device.hints add hint.sio.1.flags="0x10"
 
 Swap all sio.0 entries, with the corresponding sio.1 entries, or if you
 only need to use the port at 0x3f8, then comment out or remove all sio.0
 entries and change all sio.1 entries to have the previous values of the
 sio.0 entries.  If both units had a console flag like 0x10 set for some
 reason, then to avoid complications, remove the one that you don't want
 instead of swapping it.
 
 > 	/etc/ttys - put a getty on ttyd1
 
 Yes, since ttyd* is a logically separate device from the console, it is not
 affected by changing device.hints.
 
 > What am I missing?
 >
 > If I understand correctly, the boot loader compiled in option sio0 on 0x3f8 
 > flags 0x10 will be in effect until the higher level sio driver is loaded, at
 
 Right.  At this point, unit numbers are only partly used.  I think they are
 used by sio0 to talk to the BIOS and there is a numerical unit number 0 or
 1 to talk to the BIOS on COM1 (or whatever is configured), but this is a
 bug -- the BIOS is limited to 9600 bps but everyone/everything should use
 115200 bps or larger.  Then in boot2, there is only an i/o port address to
 select the port, and 115200 bps has always been supported.
 
 > which point it reassigns all the ports based on ACPI and device.hints and the 
 > two changes to device.hints above will take effect, yes?
 
 Not quite.  The sio driver first initializes the low-level parts of
 the console driver (if the console is on sio) using device.hints, and
 some other subsystems and/or drivers print messages on the console.
 At this point, the unit number is only used to associate the hint for
 sio.N's flags with the hint for sio.N's port.  Eventually the ACPI
 subsystem runs and sets up a different association.  ACPI also uses
 the console to print messages about itself (ACPI).  Some time later, the
 sio driver initializes high-level parts of itself including high-level
 parts of the console driver.  This gives an inconsistency because the
 ACPI unit number association is different and the difference is not
 detected or fixed up.  The high-level parts are not used at this point,
 and sio uses the console driver uses itself to print messages about
 itself (including the console part of itself).  Next, other subsystems
 and drivers print messages on the low-level console.  Eventually, the
 high-level console is used and i/o to it will go to an inconsistent
 plays if ACPI disagrees with device.hints about the unit numbers.
 Changes to device.hints take effect in the first step by avoiding
 inconsistencies later, but the effects of the inconsistencies are not
 visible until the last step.
 
 >>> 4. There should be no ill effect from doing this.  Console will never 
 >>> break
 >>> and go to the wrong port.
 >> 
 >> Yes, "should be".  The wiring should be fairly deterministic once you
 >> get it to work.  I think it will continue to work even if someone fixes
 >> (?) ACPI to prefer the hints order to the ACPI order.  However, it would
 >> break if someone fixes (?) ACPI to prefer the BIOS order to both the hints
 >> order and the ACPI order (I think ACPI is using its own order and doesn't
 >> know that you've swapped the order in the BIOS).
 >
 > I'm not sure I understand the difference.  The ACPI order is the order that 
 > the BIOS presents them in when querying it via ACPI, yes?
 
 I don't completely understand this either.  I think there is a non-ACPI part
 of the BIOS that FreeBSD (or all OS's doesn't see).  As I understand your
 configuration, you start with COM1 and COM2 at the usual places but don't
 want to use COM1 so you change the BIOS settings for COM2 to the usual ones
 for COM1 and maybe vice versa.  This changes soft jumpers or whatever is
 needed for FreeBSD to see it.  Then you use a BIOS option to swap the ports
 so that everything is supposed to see COM2 as COM1.  The boot loader sees
 this but ACPI in FreeBSD doesn't.  I think this changes is only made in
 some BIOS table that ACPI in FreeBSD doesn't know about.  In my test, I
 only swapped the settings of COM1 and COM2 in the BIOS, since I couldn't
 find a BIOS option to swap the unit number assignments, so it was not
 completely incorrect for ACPI in FreeBSD to swap the settings.
 
 Bruce

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

 On Thu, 3 Aug 2006, Bruce Evans wrote:
 
 > On Wed, 2 Aug 2006, Jo Rhett wrote:
 >>>> 4. There should be no ill effect from doing this.  Console will never 
 >>>> break
 >>>> and go to the wrong port.
 >>> 
 >>> Yes, "should be".  The wiring should be fairly deterministic once you
 >>> get it to work.  I think it will continue to work even if someone fixes
 >>> (?) ACPI to prefer the hints order to the ACPI order.  However, it would
 >>> break if someone fixes (?) ACPI to prefer the BIOS order to both the hints
 >>> order and the ACPI order (I think ACPI is using its own order and doesn't
 >>> know that you've swapped the order in the BIOS).
 >> 
 >> I'm not sure I understand the difference.  The ACPI order is the order that 
 >> the BIOS presents them in when querying it via ACPI, yes?
 >
 > I don't completely understand this either.  I think there is a non-ACPI part
 > of the BIOS that FreeBSD (or all OS's doesn't see).  As I understand your
 > configuration, you start with COM1 and COM2 at the usual places but don't
 > want to use COM1 so you change the BIOS settings for COM2 to the usual ones
 > for COM1 and maybe vice versa.  This changes soft jumpers or whatever is
 > needed for FreeBSD to see it.  Then you use a BIOS option to swap the ports
 > so that everything is supposed to see COM2 as COM1.  The boot loader sees
 > this but ACPI in FreeBSD doesn't.  I think this changes is only made in
 > some BIOS table that ACPI in FreeBSD doesn't know about.  In my test, I
 > only swapped the settings of COM1 and COM2 in the BIOS, since I couldn't
 > find a BIOS option to swap the unit number assignments, so it was not
 > completely incorrect for ACPI in FreeBSD to swap the settings.
 
 More details on my test:
 - after swapping the settings of COM1 and COM2, both FreeBSD-ACPI and WinXP
     see only the settings swapped.  WinXP didn't report any changes to the
     devices.  I now think this is completely correct.  Swapping like this
     requires swapping in device.hints to keep the same assignment of physical
     devices to unit numbers.
 - after swapping the settings and then disabling COM1, FreeBSD-ACPI moves
     COM2 down to COM1 (sio0) and sio1 goes away, while WinXP doesn't change
     unit numbers and COM1 goes away.  I think the WinXP behaviour is correct
     and FreeBSD-ACPI just allocates unit numbers starting at 0.
 
 Bruce

From: Marcel Moolenaar <marcel@xcllnt.net>
To: Bruce Evans <bde@zeta.org.au>
Cc: Jo Rhett <jrhett@svcolo.com>, 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
Date: Wed, 2 Aug 2006 13:33:19 -0700

 On Aug 2, 2006, at 12:32 PM, Bruce Evans wrote:
 
 > On Wed, 2 Aug 2006, Jo Rhett wrote:
 >
 >>> On Wed, 2 Aug 2006, Jo Rhett wrote:
 >>>> 1. We can't/won't fix the sio0<->sio1 problem because fixing  
 >>>> ACPI is hard
 >>
 >> On Aug 2, 2006, at 10:25 AM, Bruce Evans wrote:
 >>> _I_ can't/won't fix it because not just the above :-).  Swapping  
 >>> of consoles
 >>> only could be fixed within the driver (so that ACPI is not  
 >>> involved and
 >>> you don't have to change device.hints) since consoles have to be  
 >>> hard-wired
 >>> in some way and the hints are good enough for wiring the unit  
 >>> number to
 >>> the i/o address (provided it's an old ISA port -- otherwise hints  
 >>> based
 >>> on the i/o address don't work).
 >>
 >> Sorry, color me dumb.  I'm getting lost here.  The problem I was  
 >> observing is that device hints is being (mostly) ignored by ACPI  
 >> and thus this is the root problem to fix.  I'm not sure what  
 >> you're trying to say here.
 >
 > Console drivers have to and do use the hints directly so as to work  
 > before
 > bus stuff like ACPI is initializated.
 
 It is a mistake for console drivers to use the hints. It's a mistake
 even to use hints for anything else. The fundamental problem with hints
 is that they use a device numbering for identification. This is totally
 wrong for low-level consoles, because device numbers mean nothing at
 that time and are mostly wrong during bus enumeration, because you
 cannot generally predict device numbers.
 
 Low-level console drivers should only use I/O port or memory mapped I/O
 information to get to the hardware and hints for non-enumerating busses
 should only provide resource information. During bus enumeration this
 will eventually be mapped to device numbers and one can establish the
 logical connection between low-level consoles and high-level devices.
 
 Thus: hints are not hints, but a convoluted mix of enforced settings
 and suggestions that are partially and inconsistently used and there-
 fore much sooner the cause of problems that a solution to it.
 
 -- 
   Marcel Moolenaar         USPA: A-39004          marcel@xcllnt.net
 
 

From: Jo Rhett <jrhett@svcolo.com>
To: Bruce Evans <bde@zeta.org.au>
Cc: freebsd-gnats-submit@freebsd.org, freebsd-i386@freebsd.org,
        njl@freebsd.org
Subject: Re: i386/100831: sio ignores BIOS information about serial ports - bounty offered
Date: Wed, 2 Aug 2006 14:42:43 -0700

 On Thu, Aug 03, 2006 at 05:32:35AM +1000, Bruce Evans wrote:
 > I don't completely understand this either.  I think there is a non-ACPI part
 > of the BIOS that FreeBSD (or all OS's doesn't see).  As I understand your
 > configuration, you start with COM1 and COM2 at the usual places but don't
 > want to use COM1 so you change the BIOS settings for COM2 to the usual ones
 > for COM1 and maybe vice versa.  This changes soft jumpers or whatever is
 > needed for FreeBSD to see it.  Then you use a BIOS option to swap the ports
 > so that everything is supposed to see COM2 as COM1.  The boot loader sees
 > this but ACPI in FreeBSD doesn't.  I think this changes is only made in
 > some BIOS table that ACPI in FreeBSD doesn't know about.  In my test, I
 > only swapped the settings of COM1 and COM2 in the BIOS, since I couldn't
 > find a BIOS option to swap the unit number assignments, so it was not
 > completely incorrect for ACPI in FreeBSD to swap the settings.
  
 Huh?  I separated this to make it clear.
 
 You can't make COM1 be COM2.  What you're saying is nonsense. 
 (not an insult, it just doesn't make sense)
 
 There are two serial ports: A and B.  I can assign 03f8 irq 4 to either of
 them, and 02f8 irq 3 to the other.  (or com3 or com4 doesn't matter)
 
 FreeBSD is currently assigning sio0 to serial A, regardless of the IO and
 IRQ settings.  Likewise sio1 to Serial B, regardless of configuration.  It
 appears likely that they are assigned based entirely on the order that they
 are presented via ACPI, and device hints are ignored entirely.
 
 However, the boot loader console does use device hints and does work 
 properly.
 
 -- 
 Jo Rhett
 senior geek
 SVcolo : Silicon Valley Colocation

From: Jo Rhett <jrhett@svcolo.com>
To: Bruce Evans <bde@zeta.org.au>
Cc: freebsd-gnats-submit@freebsd.org, freebsd-i386@freebsd.org,
        njl@freebsd.org
Subject: Re: i386/100831: sio ignores BIOS information about serial ports - bounty offered
Date: Wed, 2 Aug 2006 14:47:01 -0700

 > >4. There should be no ill effect from doing this.  Console will never break
 > >and go to the wrong port.
 > >
 > >#4 is crucial to us.  Many of these machines are completely unavailable to
 > >me for an emergency.  This console is our "last chance access"
 
 On Thu, Aug 03, 2006 at 03:25:28AM +1000, Bruce Evans wrote:
 > Yes, "should be".  The wiring should be fairly deterministic once you
 > get it to work.  I think it will continue to work even if someone fixes
 > (?) ACPI to prefer the hints order to the ACPI order.  However, it would
 > break if someone fixes (?) ACPI to prefer the BIOS order to both the hints
 > order and the ACPI order (I think ACPI is using its own order and doesn't
 > know that you've swapped the order in the BIOS).
  
 Actually, it doesn't work right now.  I just tested it.
 /boot/device.hints: hint.sio.1.flags="0x90"
 
 If you change the flags in device hints, the low-level (boot loader 2?)
 console gets moved to wherever you put the flags.
 
 So now I have the exact reverse behavior.  The initialization part of the
 console goes to the wrong port, and then halfway through booting I
 suddently get console on the right port.
 
 I think I have to agree with Marcel on this -- device hints aren't used
 consistently, and having two different processes read it with two
 completely different interpretations of it is nonsense.  I can't fix one
 without breaking the other.
 
 --  
 Jo Rhett
 senior geek
 SVcolo : Silicon Valley Colocation

From: Nate Lawson <nate@root.org>
To: Bruce Evans <bde@zeta.org.au>
Cc: Jo Rhett <jrhett@svcolo.com>, freebsd-gnats-submit@freebsd.org,
        freebsd-i386@freebsd.org
Subject: Re: i386/100831: sio ignores BIOS information about serial ports
 - bounty offered
Date: Wed, 02 Aug 2006 18:31:11 -0700

 Bruce Evans wrote:
 > On Thu, 3 Aug 2006, Bruce Evans wrote:
 >> I don't completely understand this either.  I think there is a 
 >> non-ACPI part
 >> of the BIOS that FreeBSD (or all OS's doesn't see).  As I understand your
 >> configuration, you start with COM1 and COM2 at the usual places but don't
 >> want to use COM1 so you change the BIOS settings for COM2 to the usual 
 >> ones
 >> for COM1 and maybe vice versa.  This changes soft jumpers or whatever is
 >> needed for FreeBSD to see it.  Then you use a BIOS option to swap the 
 >> ports
 >> so that everything is supposed to see COM2 as COM1.  The boot loader sees
 >> this but ACPI in FreeBSD doesn't.  I think this changes is only made in
 >> some BIOS table that ACPI in FreeBSD doesn't know about.  In my test, I
 >> only swapped the settings of COM1 and COM2 in the BIOS, since I couldn't
 >> find a BIOS option to swap the unit number assignments, so it was not
 >> completely incorrect for ACPI in FreeBSD to swap the settings.
 > 
 > More details on my test:
 > - after swapping the settings of COM1 and COM2, both FreeBSD-ACPI and WinXP
 >    see only the settings swapped.  WinXP didn't report any changes to the
 >    devices.  I now think this is completely correct.  Swapping like this
 >    requires swapping in device.hints to keep the same assignment of 
 > physical
 >    devices to unit numbers.
 > - after swapping the settings and then disabling COM1, FreeBSD-ACPI moves
 >    COM2 down to COM1 (sio0) and sio1 goes away, while WinXP doesn't change
 >    unit numbers and COM1 goes away.  I think the WinXP behaviour is correct
 >    and FreeBSD-ACPI just allocates unit numbers starting at 0.
 > 
 > Bruce
 
 Please see the thread titled "acpi on msi-9218 (-current) swaps sio0 and 
 sio1" on the freebsd-acpi@ list.  John Baldwin's approach is the one I 
 like, where hints can be used to wire device unit numbers to a 
 particular device with a bus-specific string.  For instance, 
 hint.fxp.0.location="0:4:0" would mean a bus/slot/function to PCI and be 
 meaningless to other busses.  Another example: 
 hint.sio.0.location="COMA" would mean a Device node in ACPI named "COMA" 
 would be wired to sio0 and meaningless to other devices.
 
 As marcel@ pointed out, for serial ports in particular, you want the 
 resource of I/O port as the primary identifier.  So the default hint 
 would be something like hint.sio.0.location="io=0x3f8".
 
 Other than some minor logic to allocate device units in newbus, the only 
 change would be to decide on location naming schemes for the relevant 
 bus types.  Something like "io=0x3f8" might always match resources via 
 RIDs and be bus-independent.  I haven't thought much about the best 
 naming scheme but I like the general idea of attaching a named ID to a 
 unit to wire it to a known device, where the name means something to 
 only a particular bus.
 
 -- 
 Nate

From: Warner Losh <imp@bsdimp.com>
To: nate@root.org
Cc: bde@zeta.org.au, jrhett@svcolo.com, freebsd-gnats-submit@freebsd.org,
        freebsd-i386@freebsd.org
Subject: Re: i386/100831: sio ignores BIOS information about serial ports -
 bounty offered
Date: Thu, 03 Aug 2006 11:12:43 -0600 (MDT)

 > Please see the thread titled "acpi on msi-9218 (-current) swaps sio0 and 
 > sio1" on the freebsd-acpi@ list.  John Baldwin's approach is the one I 
 > like, where hints can be used to wire device unit numbers to a 
 > particular device with a bus-specific string.  For instance, 
 > hint.fxp.0.location="0:4:0" would mean a bus/slot/function to PCI and be 
 > meaningless to other busses.  Another example: 
 > hint.sio.0.location="COMA" would mean a Device node in ACPI named "COMA" 
 > would be wired to sio0 and meaningless to other devices.
 
 I have patches that implement the parts of John's ideas that will
 actually work.  I have pci wiring working.  I have some ACPI wiring
 working, but not all of it.
 
 > As marcel@ pointed out, for serial ports in particular, you want the 
 > resource of I/O port as the primary identifier.  So the default hint 
 > would be something like hint.sio.0.location="io=0x3f8".
 
 I hate this notation, since the hints functions don't search that
 space well.
 
 > Other than some minor logic to allocate device units in newbus, the only 
 > change would be to decide on location naming schemes for the relevant 
 > bus types.  Something like "io=0x3f8" might always match resources via 
 > RIDs and be bus-independent.  I haven't thought much about the best 
 > naming scheme but I like the general idea of attaching a named ID to a 
 > unit to wire it to a known device, where the name means something to 
 > only a particular bus.
 
 The "minor logic" in newbus is actually kicking my ass right now.  I
 have stuff in p4 that should implement all the things we need, but the
 unit allocation is kicking my butt.  I fear that the only real way is
 to subclass isa three times: hints-only, pnp+hint-augment,
 acpi+hint-augment.  In the latter two, how does one tell a 'this hint
 is for a card that's there' versus a 'this hint is a wiring hint'?
 And for the wiring hints, how much of the device matching do you do?
 If the I/O matches, but the IRQ doesn't, is that a match?  What about
 vice versa?
 
 The main problem right now is that hints are designed either to
 populate a bus, or to look up stuff after unit numbers are assigned.
 If you want to do something before unit numbers are assigned, it gets
 a lot harder.  Many of the ideas that you've suggested require
 extensive, and expensive, algorithims to find what the right DWIM is
 for this situation.
 
 When a bus adds a device, there are no resources associated with it.
 The bus might be in a position to assign specific device names/units
 to individual devices at the time it adds it, but not always.  ACPI,
 for example, adds the device, then uses that device to parse the
 resources.  This means that looking things up in the hints table
 before adding them is hard.  It also means that the bus has to
 necessarily get into the middle of pre-assigning device/units.
 
 Anyway, like I said, I'll post something when I get the last bit of
 the unit matching working.
 
 Warner

From: Marcel Moolenaar <marcel@xcllnt.net>
To: Warner Losh <imp@bsdimp.com>
Cc: nate@root.org, jrhett@svcolo.com, freebsd-gnats-submit@freebsd.org,
        freebsd-i386@freebsd.org
Subject: Re: i386/100831: sio ignores BIOS information about serial ports - bounty offered
Date: Thu, 3 Aug 2006 11:46:54 -0700

 On Aug 3, 2006, at 10:12 AM, Warner Losh wrote:
 
 > The "minor logic" in newbus is actually kicking my ass right now.  I
 > have stuff in p4 that should implement all the things we need, but the
 > unit allocation is kicking my butt.  I fear that the only real way is
 > to subclass isa three times: hints-only, pnp+hint-augment,
 > acpi+hint-augment.  In the latter two, how does one tell a 'this hint
 > is for a card that's there' versus a 'this hint is a wiring hint'?
 > And for the wiring hints, how much of the device matching do you do?
 > If the I/O matches, but the IRQ doesn't, is that a match?  What about
 > vice versa?
 
 Like I said before: hints are abused for way too many purposes.
 It's better to come up with a new scheme where you clearly separate
 the different functions we're looking for and design *as many*
 different mechanisms to implement these functions.
 
 One approach would be to make ACPI unconditional, as it's there
 to describe the existence of legacy devices and thus serves the
 same purpose as our current hints and define hints to *only*
 allow wiring down hardware to unit numbers. These can be called
 hints because I'm sure we can not always guarantee it.
 
 Marking devices as special, like the sio flags is an entirely
 different function alltogether and should therefore not be done
 with the same hints. That would just create the convolution, so
 you create different hints for that.
 
 -- 
   Marcel Moolenaar         USPA: A-39004          marcel@xcllnt.net
 
 

From: Warner Losh <imp@bsdimp.com>
To: marcel@xcllnt.net
Cc: nate@root.org, jrhett@svcolo.com, freebsd-gnats-submit@freebsd.org,
        freebsd-i386@freebsd.org
Subject: Re: i386/100831: sio ignores BIOS information about serial ports -
 bounty offered
Date: Thu, 03 Aug 2006 15:28:16 -0600 (MDT)

 > On Aug 3, 2006, at 10:12 AM, Warner Losh wrote:
 > 
 > > The "minor logic" in newbus is actually kicking my ass right now.  I
 > > have stuff in p4 that should implement all the things we need, but the
 > > unit allocation is kicking my butt.  I fear that the only real way is
 > > to subclass isa three times: hints-only, pnp+hint-augment,
 > > acpi+hint-augment.  In the latter two, how does one tell a 'this hint
 > > is for a card that's there' versus a 'this hint is a wiring hint'?
 > > And for the wiring hints, how much of the device matching do you do?
 > > If the I/O matches, but the IRQ doesn't, is that a match?  What about
 > > vice versa?
 > 
 > Like I said before: hints are abused for way too many purposes.
 > It's better to come up with a new scheme where you clearly separate
 > the different functions we're looking for and design *as many*
 > different mechanisms to implement these functions.
 
 The only thing that's not well suited for hints is the 'what is my
 console' function.  The others can be made to work well with only a
 few engineering compromises :-).  I'll agree that the flags in sio
 used to specify which UNIT is the console is lame and should be
 replaced with a generalization of the uart method.
 
 > One approach would be to make ACPI unconditional, as it's there
 > to describe the existence of legacy devices and thus serves the
 > same purpose as our current hints and define hints to *only*
 > allow wiring down hardware to unit numbers. These can be called
 > hints because I'm sure we can not always guarantee it.
 
 ACPI unconditional can't happen.  There are many machines being made
 today that simply do not implement ACPI.  I have several boards at
 work that implement PNPBIOS, but don't implement ACPI.  These are
 boards that are brand new.  I think ACPI is an extra cost option, but
 I might be confusing things.  We do need to deal with cases like this
 because they are common enough that we'll alienate folks embedding
 FreeBSD if we take such a course.
 
 > Marking devices as special, like the sio flags is an entirely
 > different function alltogether and should therefore not be done
 > with the same hints. That would just create the convolution, so
 > you create different hints for that.
 
 Agreed.  However, the sio flags to designate a unit as console is the
 only thing that doesn't fit well with hints, as presently implemented.
 It should really be something like: console.type={serial,video}
 console.location=<io=xxx,mem=yyy>
 
 so that would could use a video card not mapped to the default address
 as the console, etc.  It would be up to the driver at attach time to
 look at the available console meta-information to see if this driver
 matches that information.  Then it wouldn't matter for a serial
 console point of view what driver unit is assigned.  It might matter
 for other reasons...
 
 Warner

From: Marcel Moolenaar <marcel@xcllnt.net>
To: Warner Losh <imp@bsdimp.com>
Cc: nate@root.org, jrhett@svcolo.com, freebsd-gnats-submit@freebsd.org,
        freebsd-i386@freebsd.org
Subject: Re: i386/100831: sio ignores BIOS information about serial ports - bounty offered
Date: Thu, 3 Aug 2006 15:16:22 -0700

 On Aug 3, 2006, at 2:28 PM, Warner Losh wrote:
 
 > Agreed.  However, the sio flags to designate a unit as console is the
 > only thing that doesn't fit well with hints, as presently implemented.
 > It should really be something like: console.type={serial,video}
 > console.location=<io=xxx,mem=yyy>
 >
 > so that would could use a video card not mapped to the default address
 > as the console, etc.  It would be up to the driver at attach time to
 > look at the available console meta-information to see if this driver
 > matches that information.  Then it wouldn't matter for a serial
 > console point of view what driver unit is assigned.  It might matter
 > for other reasons...
 
 This is exactly what I implemented for uart(4). As long as the I/O
 location used by the low-level console is actually being "found"
 during bus-enumeration and the right driver is being attached,
 then you always have a working console for going to single-user
 mode. Not to mention that the firmware typically exports console
 information in terms of I/O location (see DIG64 HCDP or Microsoft
 SPCR), so you can trivially use that too (see for a real example
 src/sys/dev/uart/uart_cpu_ia64.c).
 
 -- 
   Marcel Moolenaar         USPA: A-39004          marcel@xcllnt.net
 
 

From: Bruce Evans <bde@zeta.org.au>
To: Jo Rhett <jrhett@svcolo.com>
Cc: freebsd-gnats-submit@freebsd.org, freebsd-i386@freebsd.org,
        njl@freebsd.org
Subject: Re: i386/100831: sio ignores BIOS information about serial ports -
 bounty offered
Date: Fri, 4 Aug 2006 22:29:40 +1000 (EST)

 On Wed, 2 Aug 2006, Jo Rhett wrote:
 
 > On Thu, Aug 03, 2006 at 05:32:35AM +1000, Bruce Evans wrote:
 >> I don't completely understand this either.  I think there is a non-ACPI part
 >> of the BIOS that FreeBSD (or all OS's doesn't see).  As I understand your
 >> configuration, you start with COM1 and COM2 at the usual places but don't
 >> want to use COM1 so you change the BIOS settings for COM2 to the usual ones
 >> for COM1 and maybe vice versa.  This changes soft jumpers or whatever is
 >> needed for FreeBSD to see it.  Then you use a BIOS option to swap the ports
 >> so that everything is supposed to see COM2 as COM1.  The boot loader sees
 >> this but ACPI in FreeBSD doesn't.  I think this changes is only made in
 >> some BIOS table that ACPI in FreeBSD doesn't know about.  In my test, I
 >> only swapped the settings of COM1 and COM2 in the BIOS, since I couldn't
 >> find a BIOS option to swap the unit number assignments, so it was not
 >> completely incorrect for ACPI in FreeBSD to swap the settings.
 >
 > Huh?  I separated this to make it clear.
 >
 > You can't make COM1 be COM2.  What you're saying is nonsense.
 > (not an insult, it just doesn't make sense)
 >
 > There are two serial ports: A and B.  I can assign 03f8 irq 4 to either of
 > them, and 02f8 irq 3 to the other.  (or com3 or com4 doesn't matter)
 
 It makes perfects sense when you understand that the unit number may be
 assigned at many levels, starting with the BIOS.  Whether you can make
 COM1 be COM2 at the BIOS level depends on BIOS support for this.  I've
 never seen a BIOS that supports this but thought that you had one with
 this feature and were using it (actually to make COMB be COM1), since
 you said that it works for booting and I forgot that boot2 doesn't use
 the BIOS.
 
 Later we mentioned boot0.  boot0 does use the BIOS and has COM1
 hard-wired, so assignment of COMB to COM1 at the BIOS level is the
 only way to make boot0 use COM1.
 
 Whether you can make COMB be COM1 at other levels depends on the other
 level's support for this.  Whether settings at lower levels are honored
 at higher levels also depends on the other levels' support for this.
 
 > FreeBSD is currently assigning sio0 to serial A, regardless of the IO and
 > IRQ settings.  Likewise sio1 to Serial B, regardless of configuration.  It
 > appears likely that they are assigned based entirely on the order that they
 > are presented via ACPI, and device hints are ignored entirely.
 
 This now seems a reasonable thing to do.  WinXP behaves similarly here
 (see another reply).  The hints are only hints, so they shouldn't be
 used if the hardware has been reconfigured but not moved.  Only something
 stronger than a hint should move the unit numbers if the hardware hasn't
 moved.  The problems are that the hints get used partially and there is
 nothing stronger.
 
 > However, the boot loader console does use device hints and does work
 > properly.
 
 Actually, the boot loader doesn't use hints:
 - boot0 has COM1 hard-coded in the source
 - boot2 has i/o port address 0x3f8 not so hard-coded in the Makefile.
    This can be changed using make.conf.
 - loader seems to be the same as boot2.
 There has been some discussion of propagating the settings used by the
 boot loader (at all stages) to subsequent stages, but nothing related
 seems to be implemented for the port/unit number.  Some of the settings
 (mainly the speed) are inherited by the sio console from the previous
 stage (boot2 or loader) provided the stages agree on the port/unit.
 
 Bruce

From: Bruce Evans <bde@zeta.org.au>
To: Warner Losh <imp@bsdimp.com>
Cc: marcel@xcllnt.net, jrhett@svcolo.com, freebsd-gnats-submit@freebsd.org,
        freebsd-i386@freebsd.org, nate@root.org
Subject: Re: i386/100831: sio ignores BIOS information about serial ports -
 bounty offered
Date: Sat, 5 Aug 2006 02:20:12 +1000 (EST)

 On Thu, 3 Aug 2006, Warner Losh wrote:
 
 >> On Aug 3, 2006, at 10:12 AM, Warner Losh wrote:
 
 [Warner Losh didn't write:]
 >> Like I said before: hints are abused for way too many purposes.
 >> It's better to come up with a new scheme where you clearly separate
 >> the different functions we're looking for and design *as many*
 >> different mechanisms to implement these functions.
 >
 > The only thing that's not well suited for hints is the 'what is my
 > console' function.  The others can be made to work well with only a
 
 Hints are actually almost perfectly suited to specifying the console,
 though not for other things.  This is because the console wiring must
 be decided early so whatever specifies the wiring must be simple and
 non-ambiguous.  Then whatever wiring is used for the console must be
 respected by more general wiring in ACPI etc.  It doesn't matter much
 whether the console wiring is determined by hints that are actually
 "forces" or by "forces" that have to have precedence over other wiring
 possibilities later.  It is just clearer for hints to never be forces.
 
 > few engineering compromises :-).  I'll agree that the flags in sio
 > used to specify which UNIT is the console is lame and should be
 > replaced with a generalization of the uart method.
 
 I'll disagree with this.  The flags actually work almost perfectly
 for specifying which physical device is the console, but not for other
 things.  This is again because the console wiring must be decided
 early, etc., and because the unit number is mostly used only to
 correlate the hint that specifies flags with the hint that specifies
 the i/o port address.  Low-level consoles are associated in this way
 with the i/o port address, and work because the unit number is only
 used in similar ways at a low level (it used to be an index, but is
 now more like a cookie, and it still works at low levels because the
 cookie is always the same although it is different from the high-level
 logical unit number in broken cases).
 
 Problems occur if ACPI etc., associates a different unit number with
 the i/o port address being used for the console.  High-level sio
 probe/attach matches on the port address to avoid problems, but a
 critical part of high-level console attachment happens too early, and
 sio neither detects nor fixes up the problem.  uart fixes up the problem
 using a partially delayed attachment ("Yedi trick").  This helps a bit
 for consoles but has no effect for non-consoles.  Even for consoles,
 non-console flags don't work when the unit numbers are inconsistently
 chosen -- all flags remain on the original unit number where they
 probably no longer apply since flags are more associated with port
 addresses than with logical unit numbers; the flags for sio consoles
 have almost no effect when they are on a wrong unit (they are just
 printed in the boot messages), but the flags for non-consoles on
 any device are misapplied.
 
 >> One approach would be to make ACPI unconditional, as it's there
 >> to describe the existence of legacy devices and thus serves the
 >> same purpose as our current hints and define hints to *only*
 >> allow wiring down hardware to unit numbers. These can be called
 >> hints because I'm sure we can not always guarantee it.
 >
 > ACPI unconditional can't happen.  There are many machines being made
 > today that simply do not implement ACPI.  I have several boards at
 > work that implement PNPBIOS, but don't implement ACPI.  These are
 > boards that are brand new.  I think ACPI is an extra cost option, but
 
 I thought that the idea was to use ACPI's configuration format even if
 the BIOS doesn't support it.
 
 >> Marking devices as special, like the sio flags is an entirely
 >> different function alltogether and should therefore not be done
 >> with the same hints. That would just create the convolution, so
 >> you create different hints for that.
 >
 > Agreed.  However, the sio flags to designate a unit as console is the
 > only thing that doesn't fit well with hints, as presently implemented.
 > It should really be something like: console.type={serial,video}
 > console.location=<io=xxx,mem=yyy>
 >
 > so that would could use a video card not mapped to the default address
 > as the console, etc.  It would be up to the driver at attach time to
 > look at the available console meta-information to see if this driver
 > matches that information.  Then it wouldn't matter for a serial
 > console point of view what driver unit is assigned.  It might matter
 > for other reasons...
 
 Marcel wrote in a reply:
 
 % This is exactly what I implemented for uart(4). As long as the I/O
 % location used by the low-level console is actually being "found"
 % during bus-enumeration and the right driver is being attached,
 % then you always have a working console for going to single-user
 % mode. Not to mention that the firmware typically exports console
 % information in terms of I/O location (see DIG64 HCDP or Microsoft
 % SPCR), so you can trivially use that too (see for a real example
 % src/sys/dev/uart/uart_cpu_ia64.c).
 
 sio mostly uses the i/o location too.
 
 Something higher-level should really be used.  The firmware may decide
 to put the location in a different place on each boot.  Memory mapped
 i/o locations tend to change when new hardware is added.  It takes
 something like a dummy boot and reading the boot messages just to see
 where things moved to.
 
 Bruce

From: Jo Rhett <jrhett@svcolo.com>
To: Bruce Evans <bde@zeta.org.au>
Cc: freebsd-gnats-submit@freebsd.org, freebsd-i386@freebsd.org,
        njl@freebsd.org
Subject: Re: i386/100831: sio ignores BIOS information about serial ports - bounty offered
Date: Fri, 4 Aug 2006 11:29:12 -0700

 On Aug 4, 2006, at 5:29 AM, Bruce Evans wrote:
 > It makes perfects sense when you understand that the unit number  
 > may be
 > assigned at many levels, starting with the BIOS.  Whether you can make
 > COM1 be COM2 at the BIOS level depends on BIOS support for this.  I've
 
 Sorry, saying nonsense like this confuses the issue.  COM1 is a CPM/ 
 DOS designation that means 0x3f8 irq 4.
 
 Saying COM1 = COM2 means "IO 0x3f8 irq 4 == 0x2f8 irq 3".  Can you  
 understand that this makes no sense?
 
 Physical port ordering has no meaning with regards to COM1 ports.   
 Even on the original IBM hardware you could set jumpers and swap  
 which physical port was COM1 and which was COM2.  I spent years doing  
 this! :-)
 
 -- 
 Jo Rhett
 senior geek
 Silicon Valley Colocation
 

From: Jo Rhett <jrhett@svcolo.com>
To: Bruce Evans <bde@zeta.org.au>
Cc: freebsd-gnats-submit@freebsd.org, freebsd-i386@freebsd.org,
        njl@freebsd.org
Subject: Re: i386/100831: sio ignores BIOS information about serial ports - bounty offered
Date: Fri, 4 Aug 2006 11:36:56 -0700

 On Aug 4, 2006, at 5:29 AM, Bruce Evans wrote:
 > Later we mentioned boot0.  boot0 does use the BIOS and has COM1
 > hard-wired, so assignment of COMB to COM1 at the BIOS level is the
 > only way to make boot0 use COM1.
 >
 > Whether you can make COMB be COM1 at other levels depends on the other
 > level's support for this.  Whether settings at lower levels are  
 > honored
 > at higher levels also depends on the other levels' support for this.
 >
 >> FreeBSD is currently assigning sio0 to serial A, regardless of the  
 >> IO and
 >> IRQ settings.  Likewise sio1 to Serial B, regardless of  
 >> configuration.  It
 >> appears likely that they are assigned based entirely on the order  
 >> that they
 >> are presented via ACPI, and device hints are ignored entirely.
 >
 > This now seems a reasonable thing to do.  WinXP behaves similarly here
 > (see another reply).  The hints are only hints, so they shouldn't be
 > used if the hardware has been reconfigured but not moved.  Only  
 > something
 > stronger than a hint should move the unit numbers if the hardware  
 > hasn't
 > moved.  The problems are that the hints get used partially and  
 > there is
 > nothing stronger.
 
 I'd like to note for the record that all of this is goobly-gook.   
 None of what you're saying rhymes with the documentation, and even  
 you guys talking about this on the thread seem to have different  
 views of what is happening here.
 
 I am finding this conversation nearly impossible to follow.  Not  
 because it's technically difficult -- this stuff is fairly simple! --  
 but because I have no useful reference documentation, and it's not  
 always clear that everyone in the conversation is on the same page to  
 start with.
 
 In particular, I'd like to argue this point:
 
 > This now seems a reasonable thing to do.  WinXP behaves similarly here
 
 Absolutely not.  0x3f8 is ALWAYS COM1 to Windows, no matter what  
 version and no matter what physical port 0x3f8 is assigned to.
 
 If you'd like to argue that assigning sio numbers based on physical  
 hardware ordering makes sense -- I can't argue with that.  Except to  
 point out that if each and every level of the boot process does it  
 differently then it becomes impossible to have a serial console  
 except in the one condition that 0x3f8 is assigned to the first port  
 provided via acpi.
 
 ^^ Note that this latter condition has been possible in less than 50%  
 of the production environments on which I have worked over the last  
 17 years.
 
 -- 
 Jo Rhett
 senior geek
 Silicon Valley Colocation
 
State-Changed-From-To: open->feedback 
State-Changed-By: remko 
State-Changed-When: Wed Jul 14 06:12:04 UTC 2010 
State-Changed-Why:  
Dear Jo, 

Can you please confirm that this is still a problem on 
recent FreeBSD versions? 

http://www.freebsd.org/cgi/query-pr.cgi?pr=100831 
State-Changed-From-To: feedback->closed 
State-Changed-By: remko 
State-Changed-When: Wed Oct 12 14:39:53 UTC 2011 
State-Changed-Why:  
Feedback timeout 

http://www.freebsd.org/cgi/query-pr.cgi?pr=100831 
>Unformatted:
