acpi on msi-9218 (-current) swaps sio0 and sio1
Jung-uk Kim
jkim at FreeBSD.org
Thu Jul 6 21:23:22 UTC 2006
On Thursday 06 July 2006 04:15 pm, Nate Lawson wrote:
> othermark wrote:
> > John Baldwin wrote:
> >> On Wednesday 05 July 2006 14:14, othermark wrote:
> >>> John Baldwin wrote:
> >>>> On Thursday 29 June 2006 17:51, othermark wrote:
> >>>>> With acpi loaded on a msi-9218 motherboard, I'm seeing sio0
> >>>>> and sio1 get 'swapped.' Even though the kernel is compiled
> >>>>> for console on 0x3f8, I've had to change the /etc/ttys to use
> >>>>> ttyd1 so login is displayed when the system is booted.
> >>>>>
> >>>>> Empirically, this tells me that 0x3f8 is correct for sio0
> >>>>> (since the kernel and boot loader display fine using it as
> >>>>> comconsole).
> >>>>>
> >>>>> Is there a way to force this to be consistant? This is
> >>>>> -current from Jun
> >>>>> 8. I will try a more recent kernel soon. The following is
> >>>>> a verbose boot log.
> >>>>
> >>>> This is because your BIOS lists them backwards in the ASL.
> >>>> There isn't a workaround currently short of fixing your ASL to
> >>>> list them in the COM1/COM2 order and building a custom dsdt.
> >>>
> >>> Many thanks for your input,
> >>>
> >>> So would it be sufficient in the _INI method, just to swap the
> >>> order of initialization (I'm guessing here) for the COMA and
> >>> COMB sections? COMA and COMB both have full resource templates
> >>> for all possible legal settings.
> >>
> >> No, you have to swap the COMA and COMB devices themselves.
> >
> > Ahh ok. You must forgive me if I seem dense since this is the
> > first time I've looked at repairing these types of instruction
> > files. Are you saying that the order that they appear in the
> > .asl is important?
>
> Yes, that's what he means. Move the whole Device (COMA) { ... }
> section before COMB if that's what you want.
>
> Ultimate solution is probably to implement _SRS support (set
> resource) so that we can reconfigure the devices according to their
> desired order. That's not even on anyone's todo list I think.
I had to deal with something similar like this:
http://docs.freebsd.org/cgi/mid.cgi?200607032340.k63NewqE054013
Another ugly hack is in fdc(4) probing. If anyone can fix these
issues properly, I am all ears.
It's amazing that ISA devices are still haunting us. :-/
Jung-uk Kim
More information about the freebsd-acpi
mailing list