Two new acpi modules, acpi_wmi and acpi_hp

Michael Gmelin freebsdusb at bindone.de
Sun Jun 28 11:15:37 UTC 2009


Paul B. Mahol wrote:
> 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.
> 

Do you mean BIOS entries? Can you give me an example?


More information about the freebsd-acpi mailing list