* Reserved method has too many arguments (_OSC requires 4)
@ 2010-03-12 14:00 Thomas Renninger
2010-03-12 15:58 ` [Devel] " Moore, Robert
2010-03-15 17:28 ` Moore, Robert
0 siblings, 2 replies; 5+ messages in thread
From: Thomas Renninger @ 2010-03-12 14:00 UTC (permalink / raw
To: linux-acpi; +Cc: devel
Hi,
I have a laptop freezing early, acpi=off and noapic helps.
I wonder whether this could have to do with the broken _OSC method.
I cannot access the machine myself, eventually I can get more info
if needed, but the machine is freezing really early (after ACPI
initialization, somewhere around bringing up CPUs (possibly when
starting PCI init already?).
This is not the first time I see this message.
It would be great to get (from include/linux/kernel.h):
#define FW_BUG "[Firmware Bug]: "
#define FW_WARN "[Firmware Warn]: "
#define FW_INFO "[Firmware Info]: "
marked messages into ACPICA and blame the guys who are responsible
for that.
My other concern/question is: what exactly happens in such a case?
Will _OSC get invoked at all?
If yes, what will be the last argument, zero, -1?
Hmm, I doubt it has to do with the freeze, but it would still be
great if someone knowing these parts could comment what people
with such a BIOS could expect to happen.
Thanks,
Thomas
Method (_OSC, 5, NotSerialized)
{
Store (Arg3, Local0)
Multiply (Local0, 0x04, Local1)
Name (BUF1, Buffer (Local1) {})
Store (Arg4, BUF1)
Store (Zero, Local1)
Store (Zero, Local2)
While (Local0)
{
Multiply (Local1, 0x04, Local2)
CreateDWordField (BUF1, Local2, CAPB)
If (Arg2)
{
If (LEqual (Local1, Zero))
{
And (CAPB, 0xFFFFFFFC)
}
}
Increment (Local1)
Decrement (Local0)
}
Return (BUF1)
}
^ permalink raw reply [flat|nested] 5+ messages in thread
* RE: [Devel] Reserved method has too many arguments (_OSC requires 4)
2010-03-12 14:00 Reserved method has too many arguments (_OSC requires 4) Thomas Renninger
@ 2010-03-12 15:58 ` Moore, Robert
2010-03-15 9:30 ` Thomas Renninger
2010-03-15 17:28 ` Moore, Robert
1 sibling, 1 reply; 5+ messages in thread
From: Moore, Robert @ 2010-03-12 15:58 UTC (permalink / raw
To: Thomas Renninger, linux-acpi@vger.kernel.org; +Cc: devel@acpica.org
>My other concern/question is: what exactly happens in such a case?
>Will _OSC get invoked at all?
>If yes, what will be the last argument, zero, -1?
The method will be invoked with the 4 arguments, the correct number. What will happen then is one of three things:
1) The method attempts to access the phantom fifth argument and it will then be aborted with an AE_AML_UNINITIALIZED_ARG exception.
2) The method has some other confusion about the first four arguments (given that it is already confused about the number of arguments in the first place), and does something unpredictable.
2) The method does not attempt to access the fifth argument, understands the first four arguments correctly and runs to completion correctly.
>This is not the first time I see this message.
>It would be great to get (from include/linux/kernel.h):
I've seen this suggestion before, I'll add it as something to look at -- since it goes far beyond one or two error messages.
In the meantime, the existing error message could use some improvement to clarify it, any suggestions?
Bob
>-----Original Message-----
>From: devel-bounces@acpica.org [mailto:devel-bounces@acpica.org] On Behalf
>Of Thomas Renninger
>Sent: Friday, March 12, 2010 6:01 AM
>To: linux-acpi@vger.kernel.org
>Cc: devel@acpica.org
>Subject: [Devel] Reserved method has too many arguments (_OSC requires 4)
>
>Hi,
>
>I have a laptop freezing early, acpi=off and noapic helps.
>I wonder whether this could have to do with the broken _OSC method.
>
>I cannot access the machine myself, eventually I can get more info
>if needed, but the machine is freezing really early (after ACPI
>initialization, somewhere around bringing up CPUs (possibly when
>starting PCI init already?).
>
>This is not the first time I see this message.
>It would be great to get (from include/linux/kernel.h):
>#define FW_BUG "[Firmware Bug]: "
>#define FW_WARN "[Firmware Warn]: "
>#define FW_INFO "[Firmware Info]: "
>marked messages into ACPICA and blame the guys who are responsible
>for that.
>
>My other concern/question is: what exactly happens in such a case?
>Will _OSC get invoked at all?
>If yes, what will be the last argument, zero, -1?
>
>Hmm, I doubt it has to do with the freeze, but it would still be
>great if someone knowing these parts could comment what people
>with such a BIOS could expect to happen.
>
>Thanks,
>
> Thomas
>
>Method (_OSC, 5, NotSerialized)
>{
> Store (Arg3, Local0)
> Multiply (Local0, 0x04, Local1)
> Name (BUF1, Buffer (Local1) {})
> Store (Arg4, BUF1)
> Store (Zero, Local1)
> Store (Zero, Local2)
> While (Local0)
> {
> Multiply (Local1, 0x04, Local2)
> CreateDWordField (BUF1, Local2, CAPB)
> If (Arg2)
> {
> If (LEqual (Local1, Zero))
> {
> And (CAPB, 0xFFFFFFFC)
> }
> }
> Increment (Local1)
> Decrement (Local0)
> }
> Return (BUF1)
>}
>_______________________________________________
>Devel mailing list
>Devel@acpica.org
>http://lists.acpica.org/listinfo/devel
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Devel] Reserved method has too many arguments (_OSC requires 4)
2010-03-12 15:58 ` [Devel] " Moore, Robert
@ 2010-03-15 9:30 ` Thomas Renninger
2010-03-15 16:59 ` Moore, Robert
0 siblings, 1 reply; 5+ messages in thread
From: Thomas Renninger @ 2010-03-15 9:30 UTC (permalink / raw
To: Moore, Robert; +Cc: linux-acpi@vger.kernel.org, devel@acpica.org
On Friday 12 March 2010 16:58:41 Moore, Robert wrote:
>
> >My other concern/question is: what exactly happens in such a case?
> >Will _OSC get invoked at all?
> >If yes, what will be the last argument, zero, -1?
>
> The method will be invoked with the 4 arguments, the correct number.
> What will happen then is one of three things:
>
> 1) The method attempts to access the phantom fifth argument and it
> will then be aborted with an AE_AML_UNINITIALIZED_ARG exception.
>
> 2) The method has some other confusion about the first four arguments
> (given that it is already confused about the number of arguments in
> the first place), and does something unpredictable.
>
> 3) The method does not attempt to access the fifth argument, understands
> the first four arguments correctly and runs to completion correctly.
I expect I have the first with acpiexec I get:
execute \_SB_.PCI0._OSC 1 1 1 1
Executing \_SB_.PCI0._OSC
ACPI Error: Uninitialized Arg[4] at node 0x6c9648 (20100304/dsmthdat-544)
ACPI Exception: AE_AML_UNINITIALIZED_ARG, While resolving operands for [Store] (20100304/dswexec-554)
[AcpiExec] Exception AE_AML_UNINITIALIZED_ARG during execution of method [_OSC] Opcode [Store] @12
**** Exception AE_AML_UNINITIALIZED_ARG during execution of method [\_SB_.PCI0._OSC] (Node 0x67b7c0)
Thanks!
> >This is not the first time I see this message.
> >It would be great to get (from include/linux/kernel.h):
>
> I've seen this suggestion before, I'll add it as something to look at
> -- since it goes far beyond one or two error messages.
Great, would be the possibilty/interface, first for now.
This would help with most important/upcoming messages and newly written code.
No need to go through all files and adjust every potential message.
> In the meantime, the existing error message could use some improvement
> to clarify it, any suggestions?
Hm, not sure if this is necessary or possible.
More important would be to find out what the fifth argument is for and how
to solve this if Linux has to be able to differ _OSC 4 vs 5 arguments?
As this is the 2nd OEM (maybe only one BIOS devel company?) making use of this...
It's always the PCI root bridge _OSC method with 5 arguments, there are
other _OSC methods (e.g. processor capabilities) which still have 4 args.
This should be the first kind of such differentiation and probably is really
ugly to implement?
With the one vendor we are a bit in touch, I try to find out more.
Thanks,
Thomas
> >-----Original Message-----
> >From: devel-bounces@acpica.org [mailto:devel-bounces@acpica.org] On Behalf
> >Of Thomas Renninger
> >Sent: Friday, March 12, 2010 6:01 AM
> >To: linux-acpi@vger.kernel.org
> >Cc: devel@acpica.org
> >Subject: [Devel] Reserved method has too many arguments (_OSC requires 4)
> >
> >Hi,
> >
> >I have a laptop freezing early, acpi=off and noapic helps.
> >I wonder whether this could have to do with the broken _OSC method.
> >
> >I cannot access the machine myself, eventually I can get more info
> >if needed, but the machine is freezing really early (after ACPI
> >initialization, somewhere around bringing up CPUs (possibly when
> >starting PCI init already?).
> >
> >This is not the first time I see this message.
> >It would be great to get (from include/linux/kernel.h):
> >#define FW_BUG "[Firmware Bug]: "
> >#define FW_WARN "[Firmware Warn]: "
> >#define FW_INFO "[Firmware Info]: "
> >marked messages into ACPICA and blame the guys who are responsible
> >for that.
> >
> >My other concern/question is: what exactly happens in such a case?
> >Will _OSC get invoked at all?
> >If yes, what will be the last argument, zero, -1?
> >
> >Hmm, I doubt it has to do with the freeze, but it would still be
> >great if someone knowing these parts could comment what people
> >with such a BIOS could expect to happen.
> >
> >Thanks,
> >
> > Thomas
> >
> >Method (_OSC, 5, NotSerialized)
> >{
> > Store (Arg3, Local0)
> > Multiply (Local0, 0x04, Local1)
> > Name (BUF1, Buffer (Local1) {})
> > Store (Arg4, BUF1)
> > Store (Zero, Local1)
> > Store (Zero, Local2)
> > While (Local0)
> > {
> > Multiply (Local1, 0x04, Local2)
> > CreateDWordField (BUF1, Local2, CAPB)
> > If (Arg2)
> > {
> > If (LEqual (Local1, Zero))
> > {
> > And (CAPB, 0xFFFFFFFC)
> > }
> > }
> > Increment (Local1)
> > Decrement (Local0)
> > }
> > Return (BUF1)
> >}
> >_______________________________________________
> >Devel mailing list
> >Devel@acpica.org
> >http://lists.acpica.org/listinfo/devel
>
^ permalink raw reply [flat|nested] 5+ messages in thread
* RE: [Devel] Reserved method has too many arguments (_OSC requires 4)
2010-03-15 9:30 ` Thomas Renninger
@ 2010-03-15 16:59 ` Moore, Robert
0 siblings, 0 replies; 5+ messages in thread
From: Moore, Robert @ 2010-03-15 16:59 UTC (permalink / raw
To: Thomas Renninger; +Cc: linux-acpi@vger.kernel.org, devel@acpica.org
Please send the acpidump for this machine, we'd like to take a look at this.
Thanks,
Bob
>-----Original Message-----
>From: Thomas Renninger [mailto:trenn@suse.de]
>Sent: Monday, March 15, 2010 2:31 AM
>To: Moore, Robert
>Cc: linux-acpi@vger.kernel.org; devel@acpica.org
>Subject: Re: [Devel] Reserved method has too many arguments (_OSC requires
>4)
>
>On Friday 12 March 2010 16:58:41 Moore, Robert wrote:
>>
>> >My other concern/question is: what exactly happens in such a case?
>> >Will _OSC get invoked at all?
>> >If yes, what will be the last argument, zero, -1?
>>
>> The method will be invoked with the 4 arguments, the correct number.
>> What will happen then is one of three things:
>>
>> 1) The method attempts to access the phantom fifth argument and it
>> will then be aborted with an AE_AML_UNINITIALIZED_ARG exception.
>>
>> 2) The method has some other confusion about the first four arguments
>> (given that it is already confused about the number of arguments in
>> the first place), and does something unpredictable.
>>
>> 3) The method does not attempt to access the fifth argument, understands
>> the first four arguments correctly and runs to completion correctly.
>
>I expect I have the first with acpiexec I get:
>execute \_SB_.PCI0._OSC 1 1 1 1
>Executing \_SB_.PCI0._OSC
>ACPI Error: Uninitialized Arg[4] at node 0x6c9648 (20100304/dsmthdat-544)
>ACPI Exception: AE_AML_UNINITIALIZED_ARG, While resolving operands for
>[Store] (20100304/dswexec-554)
>[AcpiExec] Exception AE_AML_UNINITIALIZED_ARG during execution of method
>[_OSC] Opcode [Store] @12
>
>**** Exception AE_AML_UNINITIALIZED_ARG during execution of method
>[\_SB_.PCI0._OSC] (Node 0x67b7c0)
>
>Thanks!
>
>> >This is not the first time I see this message.
>> >It would be great to get (from include/linux/kernel.h):
>>
>> I've seen this suggestion before, I'll add it as something to look at
>> -- since it goes far beyond one or two error messages.
>Great, would be the possibilty/interface, first for now.
>This would help with most important/upcoming messages and newly written
>code.
>No need to go through all files and adjust every potential message.
>
>> In the meantime, the existing error message could use some improvement
>> to clarify it, any suggestions?
>Hm, not sure if this is necessary or possible.
>More important would be to find out what the fifth argument is for and how
>to solve this if Linux has to be able to differ _OSC 4 vs 5 arguments?
>As this is the 2nd OEM (maybe only one BIOS devel company?) making use of
>this...
>It's always the PCI root bridge _OSC method with 5 arguments, there are
>other _OSC methods (e.g. processor capabilities) which still have 4 args.
>This should be the first kind of such differentiation and probably is
>really
>ugly to implement?
>
>With the one vendor we are a bit in touch, I try to find out more.
>
>Thanks,
>
> Thomas
>
>> >-----Original Message-----
>> >From: devel-bounces@acpica.org [mailto:devel-bounces@acpica.org] On
>Behalf
>> >Of Thomas Renninger
>> >Sent: Friday, March 12, 2010 6:01 AM
>> >To: linux-acpi@vger.kernel.org
>> >Cc: devel@acpica.org
>> >Subject: [Devel] Reserved method has too many arguments (_OSC requires
>4)
>> >
>> >Hi,
>> >
>> >I have a laptop freezing early, acpi=off and noapic helps.
>> >I wonder whether this could have to do with the broken _OSC method.
>> >
>> >I cannot access the machine myself, eventually I can get more info
>> >if needed, but the machine is freezing really early (after ACPI
>> >initialization, somewhere around bringing up CPUs (possibly when
>> >starting PCI init already?).
>> >
>> >This is not the first time I see this message.
>> >It would be great to get (from include/linux/kernel.h):
>> >#define FW_BUG "[Firmware Bug]: "
>> >#define FW_WARN "[Firmware Warn]: "
>> >#define FW_INFO "[Firmware Info]: "
>> >marked messages into ACPICA and blame the guys who are responsible
>> >for that.
>> >
>> >My other concern/question is: what exactly happens in such a case?
>> >Will _OSC get invoked at all?
>> >If yes, what will be the last argument, zero, -1?
>> >
>> >Hmm, I doubt it has to do with the freeze, but it would still be
>> >great if someone knowing these parts could comment what people
>> >with such a BIOS could expect to happen.
>> >
>> >Thanks,
>> >
>> > Thomas
>> >
>> >Method (_OSC, 5, NotSerialized)
>> >{
>> > Store (Arg3, Local0)
>> > Multiply (Local0, 0x04, Local1)
>> > Name (BUF1, Buffer (Local1) {})
>> > Store (Arg4, BUF1)
>> > Store (Zero, Local1)
>> > Store (Zero, Local2)
>> > While (Local0)
>> > {
>> > Multiply (Local1, 0x04, Local2)
>> > CreateDWordField (BUF1, Local2, CAPB)
>> > If (Arg2)
>> > {
>> > If (LEqual (Local1, Zero))
>> > {
>> > And (CAPB, 0xFFFFFFFC)
>> > }
>> > }
>> > Increment (Local1)
>> > Decrement (Local0)
>> > }
>> > Return (BUF1)
>> >}
>> >_______________________________________________
>> >Devel mailing list
>> >Devel@acpica.org
>> >http://lists.acpica.org/listinfo/devel
>>
^ permalink raw reply [flat|nested] 5+ messages in thread
* RE: [Devel] Reserved method has too many arguments (_OSC requires 4)
2010-03-12 14:00 Reserved method has too many arguments (_OSC requires 4) Thomas Renninger
2010-03-12 15:58 ` [Devel] " Moore, Robert
@ 2010-03-15 17:28 ` Moore, Robert
1 sibling, 0 replies; 5+ messages in thread
From: Moore, Robert @ 2010-03-15 17:28 UTC (permalink / raw
To: Thomas Renninger, linux-acpi@vger.kernel.org
Cc: devel@acpica.org, Lin, Ming M
Thomas,
Looking closely at the ASL code for _OSC that you provided, I'm afraid that the control method is botched beyond all hope.
Here is the definition of _OSC:
Arguments: (4)
Arg0 - A Buffer containing a UUID
Arg1 - An Integer containing a Revision ID of the buffer format
Arg2 - An Integer containing a count of entries in Arg3
Arg3 - A Buffer containing a list of DWORD capabilities
Analyzing the method:
>Method (_OSC, 5, NotSerialized)
>{
> Store (Arg3, Local0)
> Multiply (Local0, 0x04, Local1)
Attempting to convert a DWORD count to a BYTE count. It is Arg2 that contains the count, not Arg3.
> Name (BUF1, Buffer (Local1) {})
> Store (Arg4, BUF1)
Attempting to copy the input buffer. It is Arg3 that contains the input buffer, not Arg4.
> Store (Zero, Local1)
> Store (Zero, Local2)
> While (Local0)
> {
Attempt to walk the entire input buffer, by DWORDs. Local0 incorrectly contains Arg3, should the count -- Arg2.
> Multiply (Local1, 0x04, Local2)
> CreateDWordField (BUF1, Local2, CAPB)
Create a named object (CAPB) within a loop. This will fail on the second iteration of the loop -- i.e., on the second DWORD.
> If (Arg2)
> {
> If (LEqual (Local1, Zero))
> {
> And (CAPB, 0xFFFFFFFC)
gr.asl 20: And (CAPB, 0xFFFFFFFC)
Warning 1106 - ^ Result is not used, operator has no effect
> }
> }
> Increment (Local1)
> Decrement (Local0)
> }
> Return (BUF1)
>}
Even if the code would actually execute, it doesn't do anything.
Also, the UUID is never checked.
Bob
>-----Original Message-----
>From: devel-bounces@acpica.org [mailto:devel-bounces@acpica.org] On Behalf
>Of Thomas Renninger
>Sent: Friday, March 12, 2010 6:01 AM
>To: linux-acpi@vger.kernel.org
>Cc: devel@acpica.org
>Subject: [Devel] Reserved method has too many arguments (_OSC requires 4)
>
>Hi,
>
>I have a laptop freezing early, acpi=off and noapic helps.
>I wonder whether this could have to do with the broken _OSC method.
>
>I cannot access the machine myself, eventually I can get more info
>if needed, but the machine is freezing really early (after ACPI
>initialization, somewhere around bringing up CPUs (possibly when
>starting PCI init already?).
>
>This is not the first time I see this message.
>It would be great to get (from include/linux/kernel.h):
>#define FW_BUG "[Firmware Bug]: "
>#define FW_WARN "[Firmware Warn]: "
>#define FW_INFO "[Firmware Info]: "
>marked messages into ACPICA and blame the guys who are responsible
>for that.
>
>My other concern/question is: what exactly happens in such a case?
>Will _OSC get invoked at all?
>If yes, what will be the last argument, zero, -1?
>
>Hmm, I doubt it has to do with the freeze, but it would still be
>great if someone knowing these parts could comment what people
>with such a BIOS could expect to happen.
>
>Thanks,
>
> Thomas
>
>Method (_OSC, 5, NotSerialized)
>{
> Store (Arg3, Local0)
> Multiply (Local0, 0x04, Local1)
> Name (BUF1, Buffer (Local1) {})
> Store (Arg4, BUF1)
> Store (Zero, Local1)
> Store (Zero, Local2)
> While (Local0)
> {
> Multiply (Local1, 0x04, Local2)
> CreateDWordField (BUF1, Local2, CAPB)
> If (Arg2)
> {
> If (LEqual (Local1, Zero))
> {
> And (CAPB, 0xFFFFFFFC)
> }
> }
> Increment (Local1)
> Decrement (Local0)
> }
> Return (BUF1)
>}
>_______________________________________________
>Devel mailing list
>Devel@acpica.org
>http://lists.acpica.org/listinfo/devel
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2010-03-15 17:28 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-03-12 14:00 Reserved method has too many arguments (_OSC requires 4) Thomas Renninger
2010-03-12 15:58 ` [Devel] " Moore, Robert
2010-03-15 9:30 ` Thomas Renninger
2010-03-15 16:59 ` Moore, Robert
2010-03-15 17:28 ` Moore, Robert
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).