Date: Thu, 3 Aug 2006 03:25:28 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Jo Rhett <jrhett@svcolo.com> Cc: 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 Message-ID: <20060803024810.X1573@epsplex.bde.org> In-Reply-To: <20060802150656.GB47835@svcolo.com> References: <200607252036.k6PKanFd072593@www.freebsd.org> <20060731191302.S1172@epsplex.bde.org> <6EFF87DF-280C-402C-8C2A-10F3144CF41F@svcolo.com> <20060802205230.N90692@delplex.bde.org> <20060802234330.J1249@epsplex.bde.org> <20060802150656.GB47835@svcolo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060803024810.X1573>