Date: Sun, 9 Jul 2006 11:05:15 -0700 From: Marcel Moolenaar <marcel@xcllnt.net> To: "M. Warner Losh" <imp@bsdimp.com> Cc: freebsd-acpi@freebsd.org, atkin901@yahoo.com Subject: Re: acpi on msi-9218 (-current) swaps sio0 and sio1 Message-ID: <F7150813-BC0D-454A-A374-BA91D6603E78@xcllnt.net> In-Reply-To: <20060709.014658.-460542464.imp@bsdimp.com> References: <e8jalv$rs9$1@sea.gmane.org> <44AD6F67.9060804@root.org> <200607071240.57062.jhb@freebsd.org> <20060709.014658.-460542464.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Jul 9, 2006, at 12:46 AM, M. Warner Losh wrote: > Finally, there's the redundant specification problem. People want > sio0 to attach to this thing in the back of the computer that's > labeled COMA, and whose resources are this or that. They know from > their computer's documentation that this is COM1, and windows assigns > it to COM1. This desire is due in part to it being the way we've > always selected sio0. It traditionally has been the serial port at > address 0x3f8. There's also the problem that the low level kernel > console driver wants to talk to the port by address, while the newbus > system wants to talk to it by how it probed. So you get odd > cross-threading when these two don't agree. If the cross threading > didn't exist, and the right thing happened, users wouldn't care how > that happened. uart(4) has this problem solved already. It seems to me from following the various mailing lists that it's probably time to think about phasing out sio(4), because problems tend to come up with sio(4) from time to time that have already been solved with uart(4). > ... The third problem could > also be solved with hints and some minor adjustments to newbus. I disagree. It's misusing hints that's causing the cross-threading. If hints were to be used for enumeration only and you have a different means to select the low-level serial console then cross-threading is avoided. This is exactly what uart(4) does. As such, you can even pick a port on a multi-I/O PCI card for the low-level serial console without causing interference with any of the other problems you mentioned. The reason is simply that you select the low-level serial console by the one attribute that matters: the I/O address (either I/O port or memory mapped I/O). -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?F7150813-BC0D-454A-A374-BA91D6603E78>