Date: Mon, 21 Mar 2005 14:40:21 -0500 From: John Baldwin <jhb@FreeBSD.org> To: freebsd-amd64@FreeBSD.org Subject: Re: R3000Z Laptop Status Message-ID: <200503211440.21752.jhb@FreeBSD.org> In-Reply-To: <200503211411.58425.jkim@niksun.com> References: <2fd864e05032105366eaf8b2c@mail.gmail.com> <423F1236.4000401@samsco.org> <200503211411.58425.jkim@niksun.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Monday 21 March 2005 02:11 pm, Jung-uk Kim wrote:
> 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.
I like this approach better. We already provide hints to ACPI via the loader.
--
John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve" = http://www.FreeBSD.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200503211440.21752.jhb>