Date: Mon, 21 Mar 2005 11:28:06 -0700 From: Scott Long <scottl@samsco.org> To: Astrodog <astrodog@gmail.com> Cc: freebsd-amd64@freebsd.org Subject: Re: R3000Z Laptop Status Message-ID: <423F1236.4000401@samsco.org> In-Reply-To: <2fd864e05032109304c2ad323@mail.gmail.com> References: <2fd864e05032105366eaf8b2c@mail.gmail.com> <200503211113.52233.jkim@niksun.com> <423EF3D2.9050205@samsco.org> <200503211141.40409.jkim@niksun.com> <2fd864e05032109304c2ad323@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Scott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?423F1236.4000401>