Two new acpi modules, acpi_wmi and acpi_hp

[Paul B. Mahol]

On 6/27/09, Michael Gmelin <freebsdusb at bindone.de> wrote:
> Paul B. Mahol wrote:
>> On 6/27/09, Michael <freebsdusb at bindone.de> wrote:
>>> Paul B. Mahol wrote:
>>>> On 6/26/09, Michael <freebsdusb at bindone.de> wrote:
>>>>> Paul B. Mahol wrote:
>>>>>> On 6/24/09, Michael <freebsdusb at bindone.de> wrote:
>>>>>>> Besides the other information requested, maybe you can also tell me
>>>>>>> your
>>>>>>> exact HP model number
>>>>>> Here is information you requested.
>>>>>>
>>>>> Hi Paul,
>>>>>
>>>>> please find attached a patch against the current version of the acpi_hp
>>>>> driver in CURRENT (source and manpage). It might need some tweaking if
>>>>> you're testing on 7.2 (headers). I also provided the full acpi_hp.c and
>>>>> acpi_hp.4 versions in case you can't patch.
>>>>>
>>>>> Patch:
>>>>> patch -d /usr/src < /path/to/acpi_hp.patch
>>>>>
>>>>> This patch adds the sysctl dev.acpi_hp.0.verbose (as you suggested) and
>>>>> should fix /dev/hpcmi on your machine.
>>>>>
>>>>> Please tell me if this works, so I can send it to Raul.
>>>> It works.
>>>> But I still get acpica error:
>>>>
>>>> ACPI Error: Field [C2CA] at 336 exceeds Buffer [C281] size 328 (bits)
>>>> 20090521 dsopcode-697
>>>> ACPI Error (psparse-0633): Method parse/execution failed
>>>> [\\_SB_.C241.WQBC] (Node 0xc3dcfb60), AE_AML_BUFFER_LIMIT
>>>>
>>> This is a bug in the DSDT provided by HP. The error is emitted in the
>>> underlying acpi layers while reading a buffer that contains more data
>>> then it should. The only thing you could do about this is patching your
>>> DSDT.
>>
>> How, what to modify?
>> I already modified and use custom DSTD, because one of thermal sensors
>> reported absurd temperature most of time ...
>>
>>
>
> Search for the field C281.
> Modify C281 to say 336 bits instead of 328.
> (this should be line 7498 in your DSDT:
>             Name (C281, Buffer (0x29) {})
> should be changed to
>             Name (C281, Buffer (0x2A) {})
> )
>
> That's the theory, I can't tell if that has any negative side effects.
> It seems like that's the last BIOS entry instance in the DSDT (same
> here, my machine provides 57, yours 41 if I recall correctly). So
> changing this is absolutely your own risk + I don't think it make sense
> to require all users to change their DSDT anyway.
>
> If I had more evidence that this is happening with all HPs I could
> change the acpi_wmi kernel interface to allow querying the number of
> instances of the GUID and iterate only over numberofinstances-1
> instances to avoid this error.

I think this is best solution on long run.

> What do you think of the following plan:
> - Extend acpi_emi to provide a method to query the number of instances
>   of a GUID. This way acpi_hp could know the number of instances
>   and avoid hitting the last instance

If querying number of instances of GUID is possible go for it.

> - Make acpi_hp only iterate over maxinstances-1 instances
> - Extend cmi_detail to have an additional bit that disables this
>   behaviour (so it behaves like it did before, assuming that there
>   are HP notebooks that don't have these issues)
> - Document all of this in the man page

Also if possible, it would be nice if acpi_hp doesn't output
entries which are not available on certain laptops.

-- 
Paul