Date: Mon, 21 Mar 2005 14:11:58 -0500 From: Jung-uk Kim <jkim@niksun.com> To: freebsd-amd64@freebsd.org Subject: Re: R3000Z Laptop Status Message-ID: <200503211411.58425.jkim@niksun.com> In-Reply-To: <423F1236.4000401@samsco.org> References: <2fd864e05032105366eaf8b2c@mail.gmail.com> <2fd864e05032109304c2ad323@mail.gmail.com> <423F1236.4000401@samsco.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Monday 21 March 2005 01:28 pm, Scott Long wrote:
> Astrodog wrote:
> >>>>>>>I was wondering if the R3000Z fixes have been committed to
> >>>>>>> the RELENG_5 branch, I don't see anything on the lists
> >>>>>>> about it. Should I expect 5.4 to work with the R3000 line?
> >>>>>>
> >>>>>>Yes. hint.atkbd.0.flags="0x9" is all you need now. Try the
> >>>>>>latest snapshot and let us know.
> >>>>>>
> >>>>>>Thanks,
> >>>>>>
> >>>>>>Jung-uk Kim
> >>>>>
> >>>>>Is there any way that these systems can be detected at runtime
> >>>>>and have the work-arounds be automatically activated?
> >>>>
> >>>>I believe DMI-based quirk table is the only way but we don't
> >>>> want to do that, right?
> >>>>
> >>>>Jung-uk Kim
> >>>>
> >>>>>Scott
> >>>
> >>>Well, it's gross, but it's not impossible to do. Is there a
> >>>technical reason why we wouldn't want this?
> >>
> >>The only technical reason that I can think of is some systems (e.
> >> g., IBM e345 and e346 Opteron servers) have DMI structures in
> >> ACPI NVS area, which is not accessible from early stage. If you
> >> want to do something like that, you will have to add gross hack
> >> in pmap.c to temporarily map it, I think.
> >>
> >>>Are there any alternatives, like detecting a signature in ACPI,
> >>>either a text string or a certain bit of ASL bytecode?
> >>
> >>We already have the quirk for this broken BIOS. However,
> >> keyboard probing happens way earlier to use this quirk. :-(
> >>
> >>Jung-uk Kim
> >>
> >>>Scott
> >
> > Something that came up originally, when this issue was first
> > noticed, was trying to figure out what, if any platforms, would
> > have problems if this was made to apply to all AMD64 machines,
> > and use the flag to drive an opt-out. In as far as I'm aware, no
> > AMD64-based machines are effected if you just "break" the
> > keyboard test functionality, though I'm not certain this is a
> > path worth looking at, since its still a bit ugly.
>
> My number 1 concern is that 5.4-RELEASE 'Just Works' when you load
> it onto a machine. Undocumented and under-documented work-arounds
> are very hard to manage and don't help users that aren't intimately
> familiar with the problem. This is a place where ("Alert! Don the
> asbestos skivvies now!") adding an option to ("I'm warning you!
> Prepare for flamage!") beastie.4th might be a good idea.
One possibility is adding DMI scan code in loader and passing BIOS ID
strings to kernel because loader can easily call BIOS function calls.
This won't require ugly hack in kernel space.
Jung-uk Kim
> Scott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200503211411.58425.jkim>