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

[Jo Rhett]

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

From: Jo Rhett <jrhett at svcolo.com>
To: Bruce Evans <bde at zeta.org.au>
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 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