Re: DSDT/ASL compiler error

Thomas Renninger
2006-08-20T14:35:05Z

Am So 20.08.2006 12:22 schrieb Bruno Ducrot <ducrot@poupinou.org>:
>
>> On Sat, Aug 19, 2006 at 02:50:12PM +0200, Thomas Renninger wrote:
>> > On Fri, 2006-08-18 at 22:18 +0200, Bruno Ducrot wrote:
>> > > On Fri, Aug 18, 2006 at 03:09:56PM +0200, Thomas Renninger wrote:
>> > > > (unfortunately, I hoped that was the missing hint to fix some
>> > > > things on
>> > > > this system).
>> > >
>> > > What things need to be fixed? I'm just curious.
>> >
>> > - _PPC always returns 1, therefore highest freq cannot be set
>> > (also reported recently on cpufreq list)
>> > https://bugzilla.novell.com/show_bug.cgi?id=179702
>> >
>> > - The other one could be an EC issue:
>> > battery and AC status is not updated.
>> > May be an interference with the mouse driver from the comments,
>> > no idea yet.
>> > https://bugzilla.novell.com/show_bug.cgi?id=200169
>> >
>> > Any hints are greatly appreciated...
>> > AFAIK both (at least first on several Core Duo models) phenomenons
>> > seem
>> > to happen on several (all?) new HP models.
>> >
>>
>> Also I'm wondering why there is a _PR.CPU0.INI() method. I'm
>> wondering
>> if it should be a _INI instead. But it seems it's a workaround for
>> some
>> others OSs and I'm not sure if we have to call the SMM implied by
>> that
>> _INI in order to fix that since Linux should have done something
>> similar
>> already?
>>
>> Strange.
>
>The _INI funcs are declared in SSDT(s) just invoking INI().
>The SMM stuff in _INI seems to be called if _OSI function only returns
>true for "Windows 2001" (don't have the table here right now, but it
>was for a specific _OSI string setting C014 to 0x4 which is checked
>there). It didn't help, it even made things worse, slowing the whole
>system down extremly.
>
>    Thomas
>

-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html