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

Bruce Evans bde at zeta.org.au
Wed Aug 2 17:30:30 UTC 2006


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 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


More information about the freebsd-i386 mailing list