acpi on msi-9218 (-current) swaps sio0 and sio1
Marcel Moolenaar
marcel at xcllnt.net
Sun Jul 9 18:05:28 UTC 2006
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 at xcllnt.net
More information about the freebsd-acpi
mailing list