Re: dsdt buggy acpi

Re: dsdt buggy acpi

[Rafael J. Wysocki]

On Tuesday, 1 of July 2008, Justin Mattock wrote:
> With not knowing what I'm doing, I think I need assistance. With looking at acpi
> I decided to have a try at the dsdt.dat bit(pretty easy so far) except
> I'm being confronted with some errors, in of which
> I don't know how to resolve(still Googling for the answer) If anybody
> has any answers it would sure be appreciated.
> errors below:
> 
> Intel ACPI Component Architecture
> ASL Optimizing Compiler version 20051216 [Jan  9 2006]
> Copyright (C) 2000 - 2005 Intel Corporation
> Supports ACPI Specification Revision 3.0
> 
> No back ptr to Op: type 8
> No back ptr to Op: type 8
> dsdt.dsl   511:             If (And (PDC0, 0x08))
> Error    1061 -   Object does not exist ^  (PDC0)
> 
> dsdt.dsl   514:                 If (And (PDC0, 0x10))
> Error    1061 -       Object does not exist ^  (PDC0)
> 
> dsdt.dsl   521:             If (And (PDC1, 0x08))
> Error    1065 -                         ^ Object not accessible from
> this scope (PDC1)
> 
> dsdt.dsl   524:                 If (And (PDC1, 0x10))
> Error    1065 -                             ^ Object not accessible
> from this scope (PDC1)
> 
> ASL Input:  dsdt.dsl - 5040 lines, 171343 bytes, 1814 keywords
> Compilation complete. 4 Errors, 0 Warnings, 0 Remarks, 609 Optimizations
> 
> I'm figuring if I can at least fix this, then maybe this will help
> with: http://bugzilla.kernel.org/show_bug.cgi?id=10724
> acpi gpe storm regression.(or at least get me this much closer to
> figuring out what is up with that).

Please have a look at http://www.lesswatts.org/projects/acpi/

Thanks,
Rafael

Re: dsdt buggy acpi

[Justin Mattock]

On Tue, Jul 1, 2008 at 2:19 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> On Tuesday, 1 of July 2008, Justin Mattock wrote:
>> With not knowing what I'm doing, I think I need assistance. With looking at acpi
>> I decided to have a try at the dsdt.dat bit(pretty easy so far) except
>> I'm being confronted with some errors, in of which
>> I don't know how to resolve(still Googling for the answer) If anybody
>> has any answers it would sure be appreciated.
>> errors below:
>>
>> Intel ACPI Component Architecture
>> ASL Optimizing Compiler version 20051216 [Jan  9 2006]
>> Copyright (C) 2000 - 2005 Intel Corporation
>> Supports ACPI Specification Revision 3.0
>>
>> No back ptr to Op: type 8
>> No back ptr to Op: type 8
>> dsdt.dsl   511:             If (And (PDC0, 0x08))
>> Error    1061 -   Object does not exist ^  (PDC0)
>>
>> dsdt.dsl   514:                 If (And (PDC0, 0x10))
>> Error    1061 -       Object does not exist ^  (PDC0)
>>
>> dsdt.dsl   521:             If (And (PDC1, 0x08))
>> Error    1065 -                         ^ Object not accessible from
>> this scope (PDC1)
>>
>> dsdt.dsl   524:                 If (And (PDC1, 0x10))
>> Error    1065 -                             ^ Object not accessible
>> from this scope (PDC1)
>>
>> ASL Input:  dsdt.dsl - 5040 lines, 171343 bytes, 1814 keywords
>> Compilation complete. 4 Errors, 0 Warnings, 0 Remarks, 609 Optimizations
>>
>> I'm figuring if I can at least fix this, then maybe this will help
>> with: http://bugzilla.kernel.org/show_bug.cgi?id=10724
>> acpi gpe storm regression.(or at least get me this much closer to
>> figuring out what is up with that).
>
> Please have a look at http://www.lesswatts.org/projects/acpi/
>
> Thanks,
> Rafael
>

Cool; thanks.
I'll check that out and see where and how I can locate the dsdt
manufacture number,  then see if I can fix the broken dsdt error and
apply this to the kernel and see what happens.
regards;

-- 
Justin P. Mattock

Re: dsdt buggy acpi

[Eduard - Gabriel Munteanu]

On Tue, 1 Jul 2008 16:18:45 +0000
"Justin Mattock" <justinmattock@gmail.com> wrote:

> Cool; thanks.
> I'll check that out and see where and how I can locate the dsdt
> manufacture number,  then see if I can fix the broken dsdt error and
> apply this to the kernel and see what happens.
> regards;

Just one note here: DSDTs have nothing to do with the kernel. This is
just broken firmware. The most one can do _in-kernel_ is blacklist some
functionality or create a workaround, but this only happens for widely
used stuff. Broken DSDTs aren't widely used stuff, they are written by
the machine's vendor (the laptop's manufacturer for example, but this
could be different for desktops) and differ a lot from one machine to
another.


	Eduard

Re: dsdt buggy acpi

[Justin Mattock]

On Wed, Jul 2, 2008 at 5:25 AM, Eduard - Gabriel Munteanu
<eduard.munteanu@linux360.ro> wrote:
> On Tue, 1 Jul 2008 16:18:45 +0000
> "Justin Mattock" <justinmattock@gmail.com> wrote:
>
>> Cool; thanks.
>> I'll check that out and see where and how I can locate the dsdt
>> manufacture number,  then see if I can fix the broken dsdt error and
>> apply this to the kernel and see what happens.
>> regards;
>
> Just one note here: DSDTs have nothing to do with the kernel. This is
> just broken firmware. The most one can do _in-kernel_ is blacklist some
> functionality or create a workaround, but this only happens for widely
> used stuff. Broken DSDTs aren't widely used stuff, they are written by
> the machine's vendor (the laptop's manufacturer for example, but this
> could be different for desktops) and differ a lot from one machine to
> another.
>
>
>        Eduard
>

Cool, thanks for the info, As of right now I'm mainly trying to clean
up as much acpi errors that I can
find in my system, in hopes leading me to more info on fixing a bug(or
someone else).: http://bugzilla.kernel.org/show_bug.cgi?id=10724
For right now I have cleaned up all of the errors and warning from the
dsdt.dsl and have
 plugged in the new dsdt.hex into the kernel.(everything seems O.K).,
except for two messages I received
from running iasl
 i.g. I've google but found not very many results for this
No back ptr to Op: type 8
No back ptr to Op: type 8

After contemplating I decided to go ahead with the modified dsdt
irregardless of the: No back ptr to Op: type 8
message, but to my dismay I'm still receiving the BUG.  "gripes"
on a positive not creating a custom dsdt and loading it into the
kernel is "cake", figuring out how to fix the dsdt is a "bi*^h";
anyways If you or anybody knows what this means, please send a message.
regards;

-- 
Justin P. Mattock

Re: dsdt buggy acpi

[Matthew Garrett]

On Wed, Jul 02, 2008 at 08:25:55AM +0300, Eduard - Gabriel Munteanu wrote:

> Just one note here: DSDTs have nothing to do with the kernel. This is
> just broken firmware. The most one can do _in-kernel_ is blacklist some
> functionality or create a workaround, but this only happens for widely
> used stuff. Broken DSDTs aren't widely used stuff, they are written by
> the machine's vendor (the laptop's manufacturer for example, but this
> could be different for desktops) and differ a lot from one machine to
> another.

We've made a huge number of workarounds for buggy DSDT implementations.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: dsdt buggy acpi

[Eduard - Gabriel Munteanu]

On Wed, 2 Jul 2008 11:09:35 +0100
Matthew Garrett <mjg59@srcf.ucam.org> wrote:

> On Wed, Jul 02, 2008 at 08:25:55AM +0300, Eduard - Gabriel Munteanu
> wrote:
> 
> > Just one note here: DSDTs have nothing to do with the kernel. This
> > is just broken firmware. The most one can do _in-kernel_ is
> > blacklist some functionality or create a workaround, but this only
> > happens for widely used stuff. Broken DSDTs aren't widely used
> > stuff, they are written by the machine's vendor (the laptop's
> > manufacturer for example, but this could be different for desktops)
> > and differ a lot from one machine to another.
> 
> We've made a huge number of workarounds for buggy DSDT
> implementations.

Of course, I myself used a custom DSDT for my laptop. But I was saying
that these workarounds generally do not belong to the kernel realm.

This isn't the regular "Pentium F00F bug" stuff; instead bugs in DSDTs
consist of compiling issues, non-standard compliant, plainly bad
code, Windows-only stuff, which can all be unique for every model of a
laptop for example. While the kernel may be able to get around some of
that stuff, the kernel won't have any Asus, Acer etc. specific
workarounds.

Re: dsdt buggy acpi

[Matthew Garrett]

On Wed, Jul 02, 2008 at 02:48:20PM +0300, Eduard - Gabriel Munteanu wrote:
> On Wed, 2 Jul 2008 11:09:35 +0100
> Matthew Garrett <mjg59@srcf.ucam.org> wrote:
> > We've made a huge number of workarounds for buggy DSDT
> > implementations.
> 
> Of course, I myself used a custom DSDT for my laptop. But I was saying
> that these workarounds generally do not belong to the kernel realm.

Of course they do. Nothing else is going to fix them up.

> This isn't the regular "Pentium F00F bug" stuff; instead bugs in DSDTs
> consist of compiling issues, non-standard compliant, plainly bad
> code, Windows-only stuff, which can all be unique for every model of a
> laptop for example. While the kernel may be able to get around some of
> that stuff, the kernel won't have any Asus, Acer etc. specific
> workarounds.

Windows doesn't have any Asus/Acer/whatever workarounds either. We just 
need to be compatible with the Windows implementation. There's a 
minority of cases where that isn't good enough, but almost every DSDT 
issue can (and should) be handled by Linux if the machine works under 
Windows.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: dsdt buggy acpi

[Justin Mattock]

On Wed, Jul 2, 2008 at 11:55 AM, Matthew Garrett <mjg59@srcf.ucam.org> wrote:
> On Wed, Jul 02, 2008 at 02:48:20PM +0300, Eduard - Gabriel Munteanu wrote:
>> On Wed, 2 Jul 2008 11:09:35 +0100
>> Matthew Garrett <mjg59@srcf.ucam.org> wrote:
>> > We've made a huge number of workarounds for buggy DSDT
>> > implementations.
>>
>> Of course, I myself used a custom DSDT for my laptop. But I was saying
>> that these workarounds generally do not belong to the kernel realm.
>
> Of course they do. Nothing else is going to fix them up.
>
>> This isn't the regular "Pentium F00F bug" stuff; instead bugs in DSDTs
>> consist of compiling issues, non-standard compliant, plainly bad
>> code, Windows-only stuff, which can all be unique for every model of a
>> laptop for example. While the kernel may be able to get around some of
>> that stuff, the kernel won't have any Asus, Acer etc. specific
>> workarounds.
>
> Windows doesn't have any Asus/Acer/whatever workarounds either. We just
> need to be compatible with the Windows implementation. There's a
> minority of cases where that isn't good enough, but almost every DSDT
> issue can (and should) be handled by Linux if the machine works under
> Windows.
>
> --
> Matthew Garrett | mjg59@srcf.ucam.org
>

Hello; what info is supplied with EFI i.g. I'm using a macbook pro.
After looking at:
http://acpi.sourceforge.net/dsdt/view.php I was unable to locate
anything with apple, or at least
couldn't find the manufacture number.
If somebody has already done this, I was wondering if it would be O.K.
if I can attached my dsdt.dsl with the errors,
and my explanation of what I changed, just so If I did something
completely wrong
I can  adjust it, So I can feel at ease knowing that it's correct.
regards;
-- 
Justin P. Mattock

Re: dsdt buggy acpi

[Matthew Garrett]

On Wed, Jul 02, 2008 at 04:30:11PM +0000, Justin Mattock wrote:

> Hello; what info is supplied with EFI i.g. I'm using a macbook pro.
> After looking at:
> http://acpi.sourceforge.net/dsdt/view.php I was unable to locate
> anything with apple, or at least
> couldn't find the manufacture number.
> If somebody has already done this, I was wondering if it would be O.K.
> if I can attached my dsdt.dsl with the errors,
> and my explanation of what I changed, just so If I did something
> completely wrong

iasl will complain about code that the Linux interpreter will happily 
accept. If the only reason you've made changes is that iasl complains, 
then it's unlikely that there's any functional difference as a result. 
Otherwise, work out which changes fix which Linux bugs and file a bug 
at bugzilla.kernel.org against acpi.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: dsdt buggy acpi

[Justin Mattock]

On Wed, Jul 2, 2008 at 4:35 PM, Matthew Garrett <mjg59@srcf.ucam.org> wrote:
> On Wed, Jul 02, 2008 at 04:30:11PM +0000, Justin Mattock wrote:
>
>> Hello; what info is supplied with EFI i.g. I'm using a macbook pro.
>> After looking at:
>> http://acpi.sourceforge.net/dsdt/view.php I was unable to locate
>> anything with apple, or at least
>> couldn't find the manufacture number.
>> If somebody has already done this, I was wondering if it would be O.K.
>> if I can attached my dsdt.dsl with the errors,
>> and my explanation of what I changed, just so If I did something
>> completely wrong
>
> iasl will complain about code that the Linux interpreter will happily
> accept. If the only reason you've made changes is that iasl complains,
> then it's unlikely that there's any functional difference as a result.
> Otherwise, work out which changes fix which Linux bugs and file a bug
> at bugzilla.kernel.org against acpi.
>
> --
> Matthew Garrett | mjg59@srcf.ucam.org
>

Hello; I modified dsdt because iasl was complaining, As a result like
what you said
"then it's unlikely that there's any functional difference as a
result" is probably
what I'm seeing. As for a bug report I already have one filed. As to
why I'm messing with
the dsdt, just trying to isolate the problem with the bug I have
already filed., or at least
get a better idea of what is happening. Anyways thanks for the info.
regards;

-- 
Justin P. Mattock

Re: dsdt buggy acpi

[Alexey Starikovskiy]

Justin Mattock wrote:
> On Wed, Jul 2, 2008 at 4:35 PM, Matthew Garrett <mjg59@srcf.ucam.org> wrote:
>   
>> On Wed, Jul 02, 2008 at 04:30:11PM +0000, Justin Mattock wrote:
>>
>>     
>>> Hello; what info is supplied with EFI i.g. I'm using a macbook pro.
>>> After looking at:
>>> http://acpi.sourceforge.net/dsdt/view.php I was unable to locate
>>> anything with apple, or at least
>>> couldn't find the manufacture number.
>>> If somebody has already done this, I was wondering if it would be O.K.
>>> if I can attached my dsdt.dsl with the errors,
>>> and my explanation of what I changed, just so If I did something
>>> completely wrong
>>>       
>> iasl will complain about code that the Linux interpreter will happily
>> accept. If the only reason you've made changes is that iasl complains,
>> then it's unlikely that there's any functional difference as a result.
>> Otherwise, work out which changes fix which Linux bugs and file a bug
>> at bugzilla.kernel.org against acpi.
>>
>> --
>> Matthew Garrett | mjg59@srcf.ucam.org
>>
>>     
>
> Hello; I modified dsdt because iasl was complaining, As a result like
> what you said
> "then it's unlikely that there's any functional difference as a
> result" is probably
> what I'm seeing. As for a bug report I already have one filed. As to
> why I'm messing with
> the dsdt, just trying to isolate the problem with the bug I have
> already filed., or at least
> get a better idea of what is happening. Anyways thanks for the info.
> regards;
>
>   

For difference, you should look for "Darwin", this is how MacOS X 
identifies itself to hardware.


Regards,
Alex.

Re: dsdt buggy acpi

[Justin Mattock]

On Fri, Jul 4, 2008 at 11:32 AM, Alexey Starikovskiy <aystarik@gmail.com> wrote:
> Justin Mattock wrote:
>>
>> On Wed, Jul 2, 2008 at 4:35 PM, Matthew Garrett <mjg59@srcf.ucam.org>
>> wrote:
>>
>>>
>>> On Wed, Jul 02, 2008 at 04:30:11PM +0000, Justin Mattock wrote:
>>>
>>>
>>>>
>>>> Hello; what info is supplied with EFI i.g. I'm using a macbook pro.
>>>> After looking at:
>>>> http://acpi.sourceforge.net/dsdt/view.php I was unable to locate
>>>> anything with apple, or at least
>>>> couldn't find the manufacture number.
>>>> If somebody has already done this, I was wondering if it would be O.K.
>>>> if I can attached my dsdt.dsl with the errors,
>>>> and my explanation of what I changed, just so If I did something
>>>> completely wrong
>>>>
>>>
>>> iasl will complain about code that the Linux interpreter will happily
>>> accept. If the only reason you've made changes is that iasl complains,
>>> then it's unlikely that there's any functional difference as a result.
>>> Otherwise, work out which changes fix which Linux bugs and file a bug
>>> at bugzilla.kernel.org against acpi.
>>>
>>> --
>>> Matthew Garrett | mjg59@srcf.ucam.org
>>>
>>>
>>
>> Hello; I modified dsdt because iasl was complaining, As a result like
>> what you said
>> "then it's unlikely that there's any functional difference as a
>> result" is probably
>> what I'm seeing. As for a bug report I already have one filed. As to
>> why I'm messing with
>> the dsdt, just trying to isolate the problem with the bug I have
>> already filed., or at least
>> get a better idea of what is happening. Anyways thanks for the info.
>> regards;
>>
>>
>
> For difference, you should look for "Darwin", this is how MacOS X identifies
> itself to hardware.
>
>
> Regards,
> Alex.
>

Hello;
So adding acpi_osi=Darwin will work for boot parameter. Also I wanted
to apologize If I pissed you off,
I didn't quite understand what was really happening, and now after
looking into the scenario, I think I need to find out
what is going on with my GPE's, this way you're detector(ec.c) won't
be going off so frequently.
regards;

-- 
Justin P. Mattock

Re: dsdt buggy acpi

[Justin Mattock]

On Fri, Jul 4, 2008 at 4:23 PM, Justin Mattock <justinmattock@gmail.com> wrote:
> On Fri, Jul 4, 2008 at 11:32 AM, Alexey Starikovskiy <aystarik@gmail.com> wrote:
>> Justin Mattock wrote:
>>>
>>> On Wed, Jul 2, 2008 at 4:35 PM, Matthew Garrett <mjg59@srcf.ucam.org>
>>> wrote:
>>>
>>>>
>>>> On Wed, Jul 02, 2008 at 04:30:11PM +0000, Justin Mattock wrote:
>>>>
>>>>
>>>>>
>>>>> Hello; what info is supplied with EFI i.g. I'm using a macbook pro.
>>>>> After looking at:
>>>>> http://acpi.sourceforge.net/dsdt/view.php I was unable to locate
>>>>> anything with apple, or at least
>>>>> couldn't find the manufacture number.
>>>>> If somebody has already done this, I was wondering if it would be O.K.
>>>>> if I can attached my dsdt.dsl with the errors,
>>>>> and my explanation of what I changed, just so If I did something
>>>>> completely wrong
>>>>>
>>>>
>>>> iasl will complain about code that the Linux interpreter will happily
>>>> accept. If the only reason you've made changes is that iasl complains,
>>>> then it's unlikely that there's any functional difference as a result.
>>>> Otherwise, work out which changes fix which Linux bugs and file a bug
>>>> at bugzilla.kernel.org against acpi.
>>>>
>>>> --
>>>> Matthew Garrett | mjg59@srcf.ucam.org
>>>>
>>>>
>>>
>>> Hello; I modified dsdt because iasl was complaining, As a result like
>>> what you said
>>> "then it's unlikely that there's any functional difference as a
>>> result" is probably
>>> what I'm seeing. As for a bug report I already have one filed. As to
>>> why I'm messing with
>>> the dsdt, just trying to isolate the problem with the bug I have
>>> already filed., or at least
>>> get a better idea of what is happening. Anyways thanks for the info.
>>> regards;
>>>
>>>
>>
>> For difference, you should look for "Darwin", this is how MacOS X identifies
>> itself to hardware.
>>
>>
>> Regards,
>> Alex.
>>
>
> Hello;
> So adding acpi_osi=Darwin will work for boot parameter. Also I wanted
> to apologize If I pissed you off,
> I didn't quite understand what was really happening, and now after
> looking into the scenario, I think I need to find out
> what is going on with my GPE's, this way you're detector(ec.c) won't
> be going off so frequently.
> regards;
>
> --
> Justin P. Mattock
>

Hmm I like this option(never new it existed), the only problem I'm seeing right
now is no battery info in /proc/acpi, "but there is no gpe storm which
makes me happy".
After searching I'm looking at the same as this:
http://lists.opensuse.org/opensuse-bugs/2007-08/msg09525.html
Overall the outcome of using sbs is bad with the Darwin option, system
sticks after loading
the module during boot. even under different proceedures
i.g. with
sbs=only (no a/c and battery modules)
sbs+ac(module)
sbs+ac+battery(modules)

regards;


-- 
Justin P. Mattock