R3000Z Laptop Status

[John Baldwin]

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 at FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org