Re: iasl and SSDT disassembling limitations

Re: iasl and SSDT disassembling limitations

[Lin Ming]

We have added a "-e" option to iasl that include tables for external
symbol resolution. See
http://git.acpica.org/repos/?p=acpica.git;a=commitdiff;h=2f705a1b06109e12bd2659d0e12215710a5622b7


Example: To disassemble an SSDT with external symbols defined in DSDT:

iasl -e dsdt.aml -d ssdt.aml

Lin Ming


> From: linux-acpi-owner@vger.kernel.org [mailto:linux-acpi-owner@vger.kernel.org] On Behalf Of Moore, Robert
> Sent: Saturday, September 27, 2008 12:49 AM
> To: Henrique de Moraes Holschuh
> Cc: linux-acpi@vger.kernel.org
> Subject: RE: iasl and SSDT disassembling limitations
> 
> Yes, it should be possible, and it is on our list of things to look at.
> 
> A little more info on the problem: Without the definition of the control method, the disassembler has no way of knowing how many arguments should be passed to the method. Without this information, it does not know how many expressions to parse after the control method invocation in order to create the arguments. The information is simply not available. So it tries to guess.
> 
> Bob
> 
> 
> >-----Original Message-----
> >From: Henrique de Moraes Holschuh [mailto:hmh@hmh.eng.br]
> >Sent: Friday, September 26, 2008 9:09 AM
> >To: Moore, Robert
> >Cc: linux-acpi@vger.kernel.org
> >Subject: iasl and SSDT disassembling limitations
> >
> >On Fri, 26 Sep 2008, Moore, Robert wrote:
> >> Most of the problems seen in the SSDT are related to the fact that the
> >> disassembler cannot always correctly disassemble code that contains calls
> >> to control methods that are external to the table. There is not enough
> >> information to disassemble correctly, and the table often needs to be
> >> repaired by hand.
> >
> >Can iasl be improved to properly disassemble such tables if we give it ALL
> >tables to work with?
> >
> >--
> >  "One disk to rule them all, One disk to find them. One disk to bring
> >  them all and in the darkness grind them. In the Land of Redmond
> >  where the shadows lie." -- The Silicon Valley Tarot
> >  Henrique Holschuh
> --
> 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

Re: iasl and SSDT disassembling limitations

[Frans Pop]

On Friday 24 October 2008, Lin Ming wrote:
> We have added a "-e" option to iasl that include tables for external
> symbol resolution.

Thanks very much. That does indeed give me a correctly disassembled table.

Would it be possible to add a warning when unavailable external symbols 
are detected? The warning could even be made verbose by saying that this 
may result in an incorrect dsl file and refer to the -e option (and maybe 
even specifically mention the dsdt table if that is the source for 
missing symbols in most cases).

Currently there is really no indication at all that something may have 
gone wrong or why until you look at the generated dsl file.

Cheers,
FJP

Re: iasl and SSDT disassembling limitations

[Lin Ming]

On Thu, 2008-10-30 at 17:11 +0800, Frans Pop wrote:
> On Friday 24 October 2008, Lin Ming wrote:
> > We have added a "-e" option to iasl that include tables for external
> > symbol resolution.
> 
> Thanks very much. That does indeed give me a correctly disassembled table.
> 
> Would it be possible to add a warning when unavailable external symbols 
> are detected? The warning could even be made verbose by saying that this 
> may result in an incorrect dsl file and refer to the -e option (and maybe 
> even specifically mention the dsdt table if that is the source for 
> missing symbols in most cases).

Good idea. Yes, we are going to add this warning message.

Lin Ming

> 
> Currently there is really no indication at all that something may have 
> gone wrong or why until you look at the generated dsl file.
> 
> Cheers,
> FJP

Re: iasl and SSDT disassembling limitations

[Thomas Renninger]

On Friday 24 October 2008 05:50:30 am Lin Ming wrote:
> We have added a "-e" option to iasl that include tables for external
> symbol resolution. See
> http://git.acpica.org/repos/?p=acpica.git;a=commitdiff;h=2f705a1b06109e12bd
>2659d0e12215710a5622b7
>
>
> Example: To disassemble an SSDT with external symbols defined in DSDT:
>
> iasl -e dsdt.aml -d ssdt.aml

I thought this option already existed for quite a while?
Did it get re-implemented?

IIRC I already saw references in both directions. SSDT is making use of 
variables declared in the DSDT and vice versa (rare, but it can happen).

IMO a proper long-term solution would be to be able to do:
iasl -d [DS]SDT*.dsl
iasl then parses every table, remembers unresolved objects and then goes 
through these, once the last table got parsed.

Probably one step harder to implement, do you think this is possible to do or 
should such things be considered as BIOS implementation bugs?

Thanks,

      Thomas

>
> Lin Ming
>
> > From: linux-acpi-owner@vger.kernel.org
> > [mailto:linux-acpi-owner@vger.kernel.org] On Behalf Of Moore, Robert
> > Sent: Saturday, September 27, 2008 12:49 AM
> > To: Henrique de Moraes Holschuh
> > Cc: linux-acpi@vger.kernel.org
> > Subject: RE: iasl and SSDT disassembling limitations
> >
> > Yes, it should be possible, and it is on our list of things to look at.
> >
> > A little more info on the problem: Without the definition of the control
> > method, the disassembler has no way of knowing how many arguments should
> > be passed to the method. Without this information, it does not know how
> > many expressions to parse after the control method invocation in order to
> > create the arguments. The information is simply not available. So it
> > tries to guess.
> >
> > Bob
> >
> > >-----Original Message-----
> > >From: Henrique de Moraes Holschuh [mailto:hmh@hmh.eng.br]
> > >Sent: Friday, September 26, 2008 9:09 AM
> > >To: Moore, Robert
> > >Cc: linux-acpi@vger.kernel.org
> > >Subject: iasl and SSDT disassembling limitations
> > >
> > >On Fri, 26 Sep 2008, Moore, Robert wrote:
> > >> Most of the problems seen in the SSDT are related to the fact that the
> > >> disassembler cannot always correctly disassemble code that contains
> > >> calls to control methods that are external to the table. There is not
> > >> enough information to disassemble correctly, and the table often needs
> > >> to be repaired by hand.
> > >
> > >Can iasl be improved to properly disassemble such tables if we give it
> > > ALL tables to work with?
> > >
> > >--
> > >  "One disk to rule them all, One disk to find them. One disk to bring
> > >  them all and in the darkness grind them. In the Land of Redmond
> > >  where the shadows lie." -- The Silicon Valley Tarot
> > >  Henrique Holschuh
> >
> > --
> > 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
>
> --
> 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

Re: iasl and SSDT disassembling limitations

[Lin Ming]

On Thu, 2008-11-13 at 08:17 +0800, Thomas Renninger wrote:
> On Friday 24 October 2008 05:50:30 am Lin Ming wrote:
> > We have added a "-e" option to iasl that include tables for external
> > symbol resolution. See
> > http://git.acpica.org/repos/?p=acpica.git;a=commitdiff;h=2f705a1b06109e12bd
> >2659d0e12215710a5622b7
> >
> >
> > Example: To disassemble an SSDT with external symbols defined in DSDT:
> >
> > iasl -e dsdt.aml -d ssdt.aml
> 
> I thought this option already existed for quite a while?
> Did it get re-implemented?

No, the original one is a NULL implementation.

> 
> IIRC I already saw references in both directions. SSDT is making use of 
> variables declared in the DSDT and vice versa (rare, but it can happen).
> 
> IMO a proper long-term solution would be to be able to do:
> iasl -d [DS]SDT*.dsl
> iasl then parses every table, remembers unresolved objects and then goes 
> through these, once the last table got parsed.
> 
> Probably one step harder to implement, do you think this is possible to do or 
> should such things be considered as BIOS implementation bugs?

It's possible, but harder. External symbol is not a BIOS bug.

iasl tries to guess the arguments of external methods, and it success at
most time (-e option is not needed).

But sometimes it fails, and then you can use -e option to include the
external tables to resolve the external symbols.

Lin Ming

> 
> Thanks,
> 
>       Thomas
> 
> >
> > Lin Ming
> >
> > > From: linux-acpi-owner@vger.kernel.org
> > > [mailto:linux-acpi-owner@vger.kernel.org] On Behalf Of Moore, Robert
> > > Sent: Saturday, September 27, 2008 12:49 AM
> > > To: Henrique de Moraes Holschuh
> > > Cc: linux-acpi@vger.kernel.org
> > > Subject: RE: iasl and SSDT disassembling limitations
> > >
> > > Yes, it should be possible, and it is on our list of things to look at.
> > >
> > > A little more info on the problem: Without the definition of the control
> > > method, the disassembler has no way of knowing how many arguments should
> > > be passed to the method. Without this information, it does not know how
> > > many expressions to parse after the control method invocation in order to
> > > create the arguments. The information is simply not available. So it
> > > tries to guess.
> > >
> > > Bob
> > >
> > > >-----Original Message-----
> > > >From: Henrique de Moraes Holschuh [mailto:hmh@hmh.eng.br]
> > > >Sent: Friday, September 26, 2008 9:09 AM
> > > >To: Moore, Robert
> > > >Cc: linux-acpi@vger.kernel.org
> > > >Subject: iasl and SSDT disassembling limitations
> > > >
> > > >On Fri, 26 Sep 2008, Moore, Robert wrote:
> > > >> Most of the problems seen in the SSDT are related to the fact that the
> > > >> disassembler cannot always correctly disassemble code that contains
> > > >> calls to control methods that are external to the table. There is not
> > > >> enough information to disassemble correctly, and the table often needs
> > > >> to be repaired by hand.
> > > >
> > > >Can iasl be improved to properly disassemble such tables if we give it
> > > > ALL tables to work with?
> > > >
> > > >--
> > > >  "One disk to rule them all, One disk to find them. One disk to bring
> > > >  them all and in the darkness grind them. In the Land of Redmond
> > > >  where the shadows lie." -- The Silicon Valley Tarot
> > > >  Henrique Holschuh
> > >
> > > --
> > > 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
> >
> > --
> > 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
> 
> 

Re: iasl and SSDT disassembling limitations

[Thomas Renninger]

On Thursday 13 November 2008 08:02:29 Lin Ming wrote:
> On Thu, 2008-11-13 at 08:17 +0800, Thomas Renninger wrote:
> > On Friday 24 October 2008 05:50:30 am Lin Ming wrote:
> > > We have added a "-e" option to iasl that include tables for external
> > > symbol resolution. See
> > > http://git.acpica.org/repos/?p=acpica.git;a=commitdiff;h=2f705a1b06109e
> > >12bd 2659d0e12215710a5622b7
> > >
> > >
> > > Example: To disassemble an SSDT with external symbols defined in DSDT:
> > >
> > > iasl -e dsdt.aml -d ssdt.aml
> >
> > I thought this option already existed for quite a while?
> > Did it get re-implemented?
>
> No, the original one is a NULL implementation.
It did not work, but it already remembered unresolved objects/functions and 
tried to resolve them correctly from the -e passed table.
Either this or I did mess up something completely when I played with that 
maybe a year ago.

>
> > IIRC I already saw references in both directions. SSDT is making use of
> > variables declared in the DSDT and vice versa (rare, but it can happen).
> >
> > IMO a proper long-term solution would be to be able to do:
> > iasl -d [DS]SDT*.dsl
> > iasl then parses every table, remembers unresolved objects and then goes
> > through these, once the last table got parsed.
> >
> > Probably one step harder to implement, do you think this is possible to
> > do or should such things be considered as BIOS implementation bugs?
>
> It's possible, but harder. External symbol is not a BIOS bug.
Do you plan to extend the functionality that external symbols can be
resolved in both directions, e.g. by passing all DSDT and SSDT tables:
iasl -d DSDT.dsl SSDT1.dsl SSDT2.dsl
I tried that unsuccessfully quite some time ago.
Now one still has an overview how this could be done :)
iasl -e DSDT.dsl SSDTx.dsl
should now work in much more cases, but I fear there will be some which
are still not covered (if DSDT references variables declared in SSDTs).

> iasl tries to guess the arguments of external methods, and it success at
> most time (-e option is not needed).
>
> But sometimes it fails, and then you can use -e option to include the
> external tables to resolve the external symbols.
Yes, and having this working makes it possible to more reliably check
BIOSes against ASL syntax errors.

Thanks a lot for your efforts,

     Thomas

> Lin Ming
>
> > Thanks,
> >
> >       Thomas
> >
> > > Lin Ming
> > >
> > > > From: linux-acpi-owner@vger.kernel.org
> > > > [mailto:linux-acpi-owner@vger.kernel.org] On Behalf Of Moore, Robert
> > > > Sent: Saturday, September 27, 2008 12:49 AM
> > > > To: Henrique de Moraes Holschuh
> > > > Cc: linux-acpi@vger.kernel.org
> > > > Subject: RE: iasl and SSDT disassembling limitations
> > > >
> > > > Yes, it should be possible, and it is on our list of things to look
> > > > at.
> > > >
> > > > A little more info on the problem: Without the definition of the
> > > > control method, the disassembler has no way of knowing how many
> > > > arguments should be passed to the method. Without this information,
> > > > it does not know how many expressions to parse after the control
> > > > method invocation in order to create the arguments. The information
> > > > is simply not available. So it tries to guess.
> > > >
> > > > Bob
> > > >
> > > > >-----Original Message-----
> > > > >From: Henrique de Moraes Holschuh [mailto:hmh@hmh.eng.br]
> > > > >Sent: Friday, September 26, 2008 9:09 AM
> > > > >To: Moore, Robert
> > > > >Cc: linux-acpi@vger.kernel.org
> > > > >Subject: iasl and SSDT disassembling limitations
> > > > >
> > > > >On Fri, 26 Sep 2008, Moore, Robert wrote:
> > > > >> Most of the problems seen in the SSDT are related to the fact that
> > > > >> the disassembler cannot always correctly disassemble code that
> > > > >> contains calls to control methods that are external to the table.
> > > > >> There is not enough information to disassemble correctly, and the
> > > > >> table often needs to be repaired by hand.
> > > > >
> > > > >Can iasl be improved to properly disassemble such tables if we give
> > > > > it ALL tables to work with?
> > > > >
> > > > >--
> > > > >  "One disk to rule them all, One disk to find them. One disk to
> > > > > bring them all and in the darkness grind them. In the Land of
> > > > > Redmond where the shadows lie." -- The Silicon Valley Tarot
> > > > >  Henrique Holschuh
> > > >
> > > > --
> > > > 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
> > >
> > > --
> > > 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

Re: iasl and SSDT disassembling limitations

[Lin Ming]

On Sat, 2008-11-15 at 00:28 +0800, Thomas Renninger wrote:
> On Thursday 13 November 2008 08:02:29 Lin Ming wrote:
> > On Thu, 2008-11-13 at 08:17 +0800, Thomas Renninger wrote:
> > > On Friday 24 October 2008 05:50:30 am Lin Ming wrote:
> > > > We have added a "-e" option to iasl that include tables for external
> > > > symbol resolution. See
> > > > http://git.acpica.org/repos/?p=acpica.git;a=commitdiff;h=2f705a1b06109e
> > > >12bd 2659d0e12215710a5622b7
> > > >
> > > >
> > > > Example: To disassemble an SSDT with external symbols defined in DSDT:
> > > >
> > > > iasl -e dsdt.aml -d ssdt.aml
> > >
> > > I thought this option already existed for quite a while?
> > > Did it get re-implemented?
> >
> > No, the original one is a NULL implementation.
> It did not work, but it already remembered unresolved objects/functions and 
> tried to resolve them correctly from the -e passed table.
> Either this or I did mess up something completely when I played with that 
> maybe a year ago.
> 
> >
> > > IIRC I already saw references in both directions. SSDT is making use of
> > > variables declared in the DSDT and vice versa (rare, but it can happen).
> > >
> > > IMO a proper long-term solution would be to be able to do:
> > > iasl -d [DS]SDT*.dsl
> > > iasl then parses every table, remembers unresolved objects and then goes
> > > through these, once the last table got parsed.
> > >
> > > Probably one step harder to implement, do you think this is possible to
> > > do or should such things be considered as BIOS implementation bugs?
> >
> > It's possible, but harder. External symbol is not a BIOS bug.
> Do you plan to extend the functionality that external symbols can be
> resolved in both directions, e.g. by passing all DSDT and SSDT tables:
> iasl -d DSDT.dsl SSDT1.dsl SSDT2.dsl

Yes, both directions.

> I tried that unsuccessfully quite some time ago.

I have some patches here.
You can try it again when next version of iasl is released.

Lin Ming

> Now one still has an overview how this could be done :)
> iasl -e DSDT.dsl SSDTx.dsl
> should now work in much more cases, but I fear there will be some which
> are still not covered (if DSDT references variables declared in SSDTs).
> 
> > iasl tries to guess the arguments of external methods, and it success at
> > most time (-e option is not needed).
> >
> > But sometimes it fails, and then you can use -e option to include the
> > external tables to resolve the external symbols.
> Yes, and having this working makes it possible to more reliably check
> BIOSes against ASL syntax errors.
> 
> Thanks a lot for your efforts,
> 
>      Thomas
> 
> > Lin Ming
> >
> > > Thanks,
> > >
> > >       Thomas
> > >
> > > > Lin Ming
> > > >
> > > > > From: linux-acpi-owner@vger.kernel.org
> > > > > [mailto:linux-acpi-owner@vger.kernel.org] On Behalf Of Moore, Robert
> > > > > Sent: Saturday, September 27, 2008 12:49 AM
> > > > > To: Henrique de Moraes Holschuh
> > > > > Cc: linux-acpi@vger.kernel.org
> > > > > Subject: RE: iasl and SSDT disassembling limitations
> > > > >
> > > > > Yes, it should be possible, and it is on our list of things to look
> > > > > at.
> > > > >
> > > > > A little more info on the problem: Without the definition of the
> > > > > control method, the disassembler has no way of knowing how many
> > > > > arguments should be passed to the method. Without this information,
> > > > > it does not know how many expressions to parse after the control
> > > > > method invocation in order to create the arguments. The information
> > > > > is simply not available. So it tries to guess.
> > > > >
> > > > > Bob
> > > > >
> > > > > >-----Original Message-----
> > > > > >From: Henrique de Moraes Holschuh [mailto:hmh@hmh.eng.br]
> > > > > >Sent: Friday, September 26, 2008 9:09 AM
> > > > > >To: Moore, Robert
> > > > > >Cc: linux-acpi@vger.kernel.org
> > > > > >Subject: iasl and SSDT disassembling limitations
> > > > > >
> > > > > >On Fri, 26 Sep 2008, Moore, Robert wrote:
> > > > > >> Most of the problems seen in the SSDT are related to the fact that
> > > > > >> the disassembler cannot always correctly disassemble code that
> > > > > >> contains calls to control methods that are external to the table.
> > > > > >> There is not enough information to disassemble correctly, and the
> > > > > >> table often needs to be repaired by hand.
> > > > > >
> > > > > >Can iasl be improved to properly disassemble such tables if we give
> > > > > > it ALL tables to work with?
> > > > > >
> > > > > >--
> > > > > >  "One disk to rule them all, One disk to find them. One disk to
> > > > > > bring them all and in the darkness grind them. In the Land of
> > > > > > Redmond where the shadows lie." -- The Silicon Valley Tarot
> > > > > >  Henrique Holschuh
> > > > >
> > > > > --
> > > > > 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
> > > >
> > > > --
> > > > 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
> 
> 

Re: iasl and SSDT disassembling limitations

[Lin Ming]

On Tue, 2008-11-18 at 15:53 +0800, Lin Ming wrote:
> On Sat, 2008-11-15 at 00:28 +0800, Thomas Renninger wrote:
> > On Thursday 13 November 2008 08:02:29 Lin Ming wrote:
> > > On Thu, 2008-11-13 at 08:17 +0800, Thomas Renninger wrote:
> > > > On Friday 24 October 2008 05:50:30 am Lin Ming wrote:
> > > > > We have added a "-e" option to iasl that include tables for external
> > > > > symbol resolution. See
> > > > > http://git.acpica.org/repos/?p=acpica.git;a=commitdiff;h=2f705a1b06109e
> > > > >12bd 2659d0e12215710a5622b7
> > > > >
> > > > >
> > > > > Example: To disassemble an SSDT with external symbols defined in DSDT:
> > > > >
> > > > > iasl -e dsdt.aml -d ssdt.aml
> > > >
> > > > I thought this option already existed for quite a while?
> > > > Did it get re-implemented?
> > >
> > > No, the original one is a NULL implementation.
> > It did not work, but it already remembered unresolved objects/functions and 
> > tried to resolve them correctly from the -e passed table.
> > Either this or I did mess up something completely when I played with that 
> > maybe a year ago.
> > 
> > >
> > > > IIRC I already saw references in both directions. SSDT is making use of
> > > > variables declared in the DSDT and vice versa (rare, but it can happen).
> > > >
> > > > IMO a proper long-term solution would be to be able to do:
> > > > iasl -d [DS]SDT*.dsl
> > > > iasl then parses every table, remembers unresolved objects and then goes
> > > > through these, once the last table got parsed.
> > > >
> > > > Probably one step harder to implement, do you think this is possible to
> > > > do or should such things be considered as BIOS implementation bugs?
> > >
> > > It's possible, but harder. External symbol is not a BIOS bug.
> > Do you plan to extend the functionality that external symbols can be
> > resolved in both directions, e.g. by passing all DSDT and SSDT tables:
> > iasl -d DSDT.dsl SSDT1.dsl SSDT2.dsl
> 
> Yes, both directions.

Sorry for my misunderstanding here.
No, currently I don't have this plan.
But it's a good idea, I'll put it in the to-do list.

Thanks,
Lin Ming

> 
> > I tried that unsuccessfully quite some time ago.
> 
> I have some patches here.
> You can try it again when next version of iasl is released.
> 
> Lin Ming
> 
> > Now one still has an overview how this could be done :)
> > iasl -e DSDT.dsl SSDTx.dsl
> > should now work in much more cases, but I fear there will be some which
> > are still not covered (if DSDT references variables declared in SSDTs).
> > 
> > > iasl tries to guess the arguments of external methods, and it success at
> > > most time (-e option is not needed).
> > >
> > > But sometimes it fails, and then you can use -e option to include the
> > > external tables to resolve the external symbols.
> > Yes, and having this working makes it possible to more reliably check
> > BIOSes against ASL syntax errors.
> > 
> > Thanks a lot for your efforts,
> > 
> >      Thomas
> > 
> > > Lin Ming
> > >
> > > > Thanks,
> > > >
> > > >       Thomas
> > > >
> > > > > Lin Ming
> > > > >
> > > > > > From: linux-acpi-owner@vger.kernel.org
> > > > > > [mailto:linux-acpi-owner@vger.kernel.org] On Behalf Of Moore, Robert
> > > > > > Sent: Saturday, September 27, 2008 12:49 AM
> > > > > > To: Henrique de Moraes Holschuh
> > > > > > Cc: linux-acpi@vger.kernel.org
> > > > > > Subject: RE: iasl and SSDT disassembling limitations
> > > > > >
> > > > > > Yes, it should be possible, and it is on our list of things to look
> > > > > > at.
> > > > > >
> > > > > > A little more info on the problem: Without the definition of the
> > > > > > control method, the disassembler has no way of knowing how many
> > > > > > arguments should be passed to the method. Without this information,
> > > > > > it does not know how many expressions to parse after the control
> > > > > > method invocation in order to create the arguments. The information
> > > > > > is simply not available. So it tries to guess.
> > > > > >
> > > > > > Bob
> > > > > >
> > > > > > >-----Original Message-----
> > > > > > >From: Henrique de Moraes Holschuh [mailto:hmh@hmh.eng.br]
> > > > > > >Sent: Friday, September 26, 2008 9:09 AM
> > > > > > >To: Moore, Robert
> > > > > > >Cc: linux-acpi@vger.kernel.org
> > > > > > >Subject: iasl and SSDT disassembling limitations
> > > > > > >
> > > > > > >On Fri, 26 Sep 2008, Moore, Robert wrote:
> > > > > > >> Most of the problems seen in the SSDT are related to the fact that
> > > > > > >> the disassembler cannot always correctly disassemble code that
> > > > > > >> contains calls to control methods that are external to the table.
> > > > > > >> There is not enough information to disassemble correctly, and the
> > > > > > >> table often needs to be repaired by hand.
> > > > > > >
> > > > > > >Can iasl be improved to properly disassemble such tables if we give
> > > > > > > it ALL tables to work with?
> > > > > > >
> > > > > > >--
> > > > > > >  "One disk to rule them all, One disk to find them. One disk to
> > > > > > > bring them all and in the darkness grind them. In the Land of
> > > > > > > Redmond where the shadows lie." -- The Silicon Valley Tarot
> > > > > > >  Henrique Holschuh
> > > > > >
> > > > > > --
> > > > > > 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
> > > > >
> > > > > --
> > > > > 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
> > 
> > 

Syntax errors in SSDT1 table of HP 2510p laptop

[Frans Pop]

[-- Attachment #1: Type: text/plain, Size: 3407 bytes --]

Hi,

I'm having problems with resume from suspend with this laptop. A lot of
the time it resumes perfectly, but sometimes it fails early.

During good resumes I see the following in my log:
ACPI Exception (exoparg2-0444): AE_AML_PACKAGE_LIMIT,
   Index (000000005) is beyond end of object [20080609]
ACPI Error (psparse-0530): Method parse/execution failed [\_SB_.C2C3]
   (Node ffff88007e335e80), AE_AML_PACKAGE_LIMIT
ACPI Error (psparse-0530): Method parse/execution failed [\_SB_.C003.C0F6.C3F3._STM]
   (Node ffff88007e33bdc0), AE_AML_PACKAGE_LIMIT
ata1: ACPI set timing mode failed (status=0x300d)

I have disassembled the ACPI tables using 'iasl' and found five obvious
syntax errors in the SSDT1 table (dump attached), of which one is in the
_GTM and two are in the _STM method. So that looks like an obvious cause.
I'm wondering if this could explain the resume problems.

If you cannot help me I'd appreciate some suggestions where to take this.


The first error looks like it may be a fairly simple fix:
@@ -64,8 +64,7 @@
                 CreateDWordField (Local0, 0x0C, C3F9)
                 CreateDWordField (Local0, 0x10, C3FA)
                 Store (C0FE (0x00, 0x00), C3F6)
-                Store (C101, 0x00)
-                C3FA
+                Store (C101 (0x00), C3FA)
                 If (And (C3FA, 0x01))
                 {
                     Store (C100 (0x00, 0x00), C3F7)

Or should that instead be
+                Store (C101 (0x00, 0x00), C3FA)
?


The next two I can't make anything of. They are very similar.
In the disassembly the first looks like:
<snip>
                If (LEqual (SizeOf (Arg1), 0x0200))
                {
                    Store (0x00, Local0)
                    Store (Buffer (Multiply (SizeOf (C2C2), 0x02)) {}, Local1)
                    While (LLess (Local0, SizeOf (C2C2)))
                    {
                        Store (DerefOf (Index (C2C2, Local0)), Local2)
                        Multiply (Local2, 0x02, Local2)
                        Multiply (Local0, 0x02, Local3)
                        Store (DerefOf (Index (Arg1, Local2)), Index (Local1, Local3))
                        Store (DerefOf (Index (Arg1, Add (Local2, 0x01))), Index (
                            Local1, Add (Local3, 0x01)))
                        Increment (Local0)
                    }

                    Store (C102 (0x00, 0x00, C3F6, C3FA, Local1), Local2)
                    Store (C106 (0x00, 0x00, C3F7, C3FA, Local1, Local3), \_SB.C2C3)
                    Local2
                    Local3
                    Local1
                    C3F4
                }
</snip>

The last 4 lines are obviously bogus. Does anyone here have a clue what
could be intended here?


The last two errors are in the _GTF method for two devices, again similar.
The first of those looks as follows:
<snip>
            Device (C3FB)
            {
                Name (_ADR, 0x00)
                Method (_GTF, 0, NotSerialized)
                {
                    Return (\_SB.C2CA)
                    C3F4
                    0x00
                }
            }
</snip>


Cheers and TIA,
FJP

P.S. There's also a warning from the DSDT table, but that looks relatively
harmless:
dsdt.dsl  9155:                         Wait (\_SB.C1AD, 0x10)
Warning  1103 -        Possible operator timeout is ignored ^

Can that be ignored or should I follow up on that too?

[-- Attachment #2: ssdt1.dat --]
[-- Type: application/octet-stream, Size: 702 bytes --]

Re: Syntax errors in SSDT1 table of HP 2510p laptop

[Zhao Yakui]

On Thu, 2008-09-25 at 11:19 +0200, Frans Pop wrote:
> Hi,
> 
Will you please try the latest kernel (2.6.27-rc6) and see whether the
problem still exists?
   It seems that the problem is fixed by the following commit:
   commit 48feb3c419508487becfb9ea3afcc54c3eac6d80
Author: Shaohua Li <shaohua.li@intel.com>
Date:   Tue Mar 25 16:50:45 2008 +0800

    ata-acpi: don't call _GTF for disabled drive

Thanks.
> I'm having problems with resume from suspend with this laptop. A lot of
> the time it resumes perfectly, but sometimes it fails early.
> 
> During good resumes I see the following in my log:
> ACPI Exception (exoparg2-0444): AE_AML_PACKAGE_LIMIT,
>    Index (000000005) is beyond end of object [20080609]
> ACPI Error (psparse-0530): Method parse/execution failed [\_SB_.C2C3]
>    (Node ffff88007e335e80), AE_AML_PACKAGE_LIMIT
> ACPI Error (psparse-0530): Method parse/execution failed [\_SB_.C003.C0F6.C3F3._STM]
>    (Node ffff88007e33bdc0), AE_AML_PACKAGE_LIMIT
> ata1: ACPI set timing mode failed (status=0x300d)
> 
> I have disassembled the ACPI tables using 'iasl' and found five obvious
> syntax errors in the SSDT1 table (dump attached), of which one is in the
> _GTM and two are in the _STM method. So that looks like an obvious cause.
> I'm wondering if this could explain the resume problems.
> 
> If you cannot help me I'd appreciate some suggestions where to take this.
> 
> 
> The first error looks like it may be a fairly simple fix:
> @@ -64,8 +64,7 @@
>                  CreateDWordField (Local0, 0x0C, C3F9)
>                  CreateDWordField (Local0, 0x10, C3FA)
>                  Store (C0FE (0x00, 0x00), C3F6)
> -                Store (C101, 0x00)
> -                C3FA
> +                Store (C101 (0x00), C3FA)
>                  If (And (C3FA, 0x01))
>                  {
>                      Store (C100 (0x00, 0x00), C3F7)
> 
> Or should that instead be
> +                Store (C101 (0x00, 0x00), C3FA)
> ?
> 
> 
> The next two I can't make anything of. They are very similar.
> In the disassembly the first looks like:
> <snip>
>                 If (LEqual (SizeOf (Arg1), 0x0200))
>                 {
>                     Store (0x00, Local0)
>                     Store (Buffer (Multiply (SizeOf (C2C2), 0x02)) {}, Local1)
>                     While (LLess (Local0, SizeOf (C2C2)))
>                     {
>                         Store (DerefOf (Index (C2C2, Local0)), Local2)
>                         Multiply (Local2, 0x02, Local2)
>                         Multiply (Local0, 0x02, Local3)
>                         Store (DerefOf (Index (Arg1, Local2)), Index (Local1, Local3))
>                         Store (DerefOf (Index (Arg1, Add (Local2, 0x01))), Index (
>                             Local1, Add (Local3, 0x01)))
>                         Increment (Local0)
>                     }
> 
>                     Store (C102 (0x00, 0x00, C3F6, C3FA, Local1), Local2)
>                     Store (C106 (0x00, 0x00, C3F7, C3FA, Local1, Local3), \_SB.C2C3)
>                     Local2
>                     Local3
>                     Local1
>                     C3F4
>                 }
> </snip>
> 
> The last 4 lines are obviously bogus. Does anyone here have a clue what
> could be intended here?
> 
> 
> The last two errors are in the _GTF method for two devices, again similar.
> The first of those looks as follows:
> <snip>
>             Device (C3FB)
>             {
>                 Name (_ADR, 0x00)
>                 Method (_GTF, 0, NotSerialized)
>                 {
>                     Return (\_SB.C2CA)
>                     C3F4
>                     0x00
>                 }
>             }
> </snip>
> 
> 
> Cheers and TIA,
> FJP
> 
> P.S. There's also a warning from the DSDT table, but that looks relatively
> harmless:
> dsdt.dsl  9155:                         Wait (\_SB.C1AD, 0x10)
> Warning  1103 -        Possible operator timeout is ignored ^
> 
> Can that be ignored or should I follow up on that too?

Re: Syntax errors in SSDT1 table of HP 2510p laptop

[Frans Pop]

On Friday 26 September 2008, Zhao Yakui wrote:
> Will you please try the latest kernel (2.6.27-rc6) and see whether the
> problem still exists?

Sorry that I did not make that clear, but I am already running with 
current git (v2.6.27-rc7-94-gc0f4d6d).

>    It seems that the problem is fixed by the following commit:
>    commit 48feb3c419508487becfb9ea3afcc54c3eac6d80

The kernel errors listed in that commit log are rather different from what 
I'm seeing.

Also, how could a commit in the kernel fix a broken ACPI table? No change 
in the kernel can repair syntax errors that show up when you disassemble 
and recompile the ACPI table itself, can it?
I thought using iasl as I did was the accepted way to uncover errors in a 
system's ACPI tables.

I really think the problem is in the ACPI table in this case, not in the 
kernel.

Cheers,
FJP

RE: Syntax errors in SSDT1 table of HP 2510p laptop

[Moore, Robert]

Most of the problems seen in the SSDT are related to the fact that the disassembler cannot always correctly disassemble code that contains calls to control methods that are external to the table. There is not enough information to disassemble correctly, and the table often needs to be repaired by hand.



>-----Original Message-----
>From: linux-acpi-owner@vger.kernel.org [mailto:linux-acpi-
>owner@vger.kernel.org] On Behalf Of Frans Pop
>Sent: Thursday, September 25, 2008 9:52 PM
>To: Zhao, Yakui
>Cc: linux-acpi@vger.kernel.org
>Subject: Re: Syntax errors in SSDT1 table of HP 2510p laptop
>
>On Friday 26 September 2008, Zhao Yakui wrote:
>> Will you please try the latest kernel (2.6.27-rc6) and see whether the
>> problem still exists?
>
>Sorry that I did not make that clear, but I am already running with
>current git (v2.6.27-rc7-94-gc0f4d6d).
>
>>    It seems that the problem is fixed by the following commit:
>>    commit 48feb3c419508487becfb9ea3afcc54c3eac6d80
>
>The kernel errors listed in that commit log are rather different from what
>I'm seeing.
>
>Also, how could a commit in the kernel fix a broken ACPI table? No change
>in the kernel can repair syntax errors that show up when you disassemble
>and recompile the ACPI table itself, can it?
>I thought using iasl as I did was the accepted way to uncover errors in a
>system's ACPI tables.
>
>I really think the problem is in the ACPI table in this case, not in the
>kernel.
>
>Cheers,
>FJP
>--
>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

iasl and SSDT disassembling limitations

[Henrique de Moraes Holschuh]

On Fri, 26 Sep 2008, Moore, Robert wrote:
> Most of the problems seen in the SSDT are related to the fact that the
> disassembler cannot always correctly disassemble code that contains calls
> to control methods that are external to the table. There is not enough
> information to disassemble correctly, and the table often needs to be
> repaired by hand.

Can iasl be improved to properly disassemble such tables if we give it ALL
tables to work with?

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

RE: iasl and SSDT disassembling limitations

[Moore, Robert]

Yes, it should be possible, and it is on our list of things to look at.

A little more info on the problem: Without the definition of the control method, the disassembler has no way of knowing how many arguments should be passed to the method. Without this information, it does not know how many expressions to parse after the control method invocation in order to create the arguments. The information is simply not available. So it tries to guess.

Bob


>-----Original Message-----
>From: Henrique de Moraes Holschuh [mailto:hmh@hmh.eng.br]
>Sent: Friday, September 26, 2008 9:09 AM
>To: Moore, Robert
>Cc: linux-acpi@vger.kernel.org
>Subject: iasl and SSDT disassembling limitations
>
>On Fri, 26 Sep 2008, Moore, Robert wrote:
>> Most of the problems seen in the SSDT are related to the fact that the
>> disassembler cannot always correctly disassemble code that contains calls
>> to control methods that are external to the table. There is not enough
>> information to disassemble correctly, and the table often needs to be
>> repaired by hand.
>
>Can iasl be improved to properly disassemble such tables if we give it ALL
>tables to work with?
>
>--
>  "One disk to rule them all, One disk to find them. One disk to bring
>  them all and in the darkness grind them. In the Land of Redmond
>  where the shadows lie." -- The Silicon Valley Tarot
>  Henrique Holschuh