Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

[acpi-jp 3117] RE: ACPI-CA 20040311 imported

1 view
Skip to first unread message

Moore, Robert

unread,
Mar 25, 2004, 12:31:56 PM3/25/04
to
I think I've seen recursion in some IBM ASL.

Also, since iASL reports a remark when it detects a recursive call,
every now and then someone complains.

Bob


-----Original Message-----
From: Nate Lawson [mailto:na...@root.org]
Sent: Thursday, March 18, 2004 11:11 PM
To: Moore, Robert
Cc: acp...@jp.FreeBSD.org; cur...@freebsd.org
Subject: Re: [acpi-jp 3117] RE: ACPI-CA 20040311 imported

> -----Original Message-----
> From: owner-...@jp.FreeBSD.org
[mailto:owner-...@jp.FreeBSD.org]
> On Behalf Of Nate Lawson
> Sent: Thursday, March 18, 2004 10:47 AM
> To: cur...@freebsd.org; acp...@jp.FreeBSD.org
> Subject: [acpi-jp 3116] ACPI-CA 20040311 imported
>
> See src/sys/contrib/dev/acpica/CHANGES.txt for specific changes.
>
> The main change is that we now support _OSI to announce we're
compatible
> with all the NT-derived MS systems. Also, we now serialize all method
> execution as some ASL depends on this behavior. The MS interpreter
> doesn't support parallel execution, hence this matches their behavior.
>
> If there are problems with these features, please try the tunables:
>
> hw.acpi.osi_method
> hw.acpi.serialize_methods
>
> You can disable each feature by setting it to 0 at the loader prompt
or
> loader.conf.

On Thu, 18 Mar 2004, Moore, Robert wrote:
> 1) If you serialize all methods by default, you will prohibit
recursive
> methods. That's why we made this an option for Linux, and the default
> is to allow reentrant methods.
>
> 2) We are not really sure about the MS interpreter. They claim that
> they support reentrant methods and allow multiple threads to execute.
> But we see problems with the coding of reentrant ASL methods that
imply
> that that multiple threads never execute control methods concurrently
on
> Win*

Interesting. Do you know of any ASL that uses recursive methods? I
haven't ever found any like that. If you don't have a counter-example,
I'm happy to let this sit in the tree for a little while to see if it
solves problems or breaks things for people. If we don't turn it on by
default, it won't get the testing it needs.

-Nate
_______________________________________________
freebsd...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-curre...@freebsd.org"

Moore, Robert

unread,
Mar 26, 2004, 4:52:21 PM3/26/04
to
Here's an example of ASL recursion:

Method(PWUP,0,NotSerialized)
{
If(LAnd(\_SB.PCI0.CBS0.PWRS,\_SB.PCI0.CBS1.PWRS))
{
If(LNot(And(_ADR /* \_SB.PCI0.CBS0._ADR */,0xFFFF)))
{
And(MCTL /* \_SB.PCI0.CBS0.MCTL */,0x7C,Local0)
Or(Local0,BMCL /* \_SB.PCI0.CBS0.BMCL */,MCTL /*
\_SB.PCI0.CBS0.MCTL */)
}
Else
{
\_SB.PCI0.CBS0.PWUP()

Bruno Ducrot

unread,
Mar 28, 2004, 10:57:08 AM3/28/04
to
On Fri, Mar 26, 2004 at 01:52:21PM -0800, Moore, Robert wrote:
> Here's an example of ASL recursion:
>
> Method(PWUP,0,NotSerialized)
> {
> If(LAnd(\_SB.PCI0.CBS0.PWRS,\_SB.PCI0.CBS1.PWRS))
> {
> If(LNot(And(_ADR /* \_SB.PCI0.CBS0._ADR */,0xFFFF)))
> {
> And(MCTL /* \_SB.PCI0.CBS0.MCTL */,0x7C,Local0)
> Or(Local0,BMCL /* \_SB.PCI0.CBS0.BMCL */,MCTL /*
> \_SB.PCI0.CBS0.MCTL */)
> }
> Else
> {
> \_SB.PCI0.CBS0.PWUP()
> }
> }
> }

I assume that PWRS are some hardware io (pci conf probably), able to
detect if the cardbus is powered or not.
I assume _ADR can not be made dynamic. So far, this function look like:

Method(PWUP, 0, NotSerialized) {
While (Not((LAnd(\_SB.PCI0.CBS0.PWRS,\_SB.PCI0.CBS1.PWRS))) {
Noop
}
}
and is probably called from _WAK, or more likely from _PS0 so far I
guess it is ok to busy loop (in both form).

Why not writting the busy loop instead?

In the original form, there is the possibility to crash the system
by overflowing the kernel stack if the bus is not powered quickly.

-- Which is worse: ignorance or apathy?
-- Don't know. Don't care.

Moore, Robert

unread,
Mar 29, 2004, 1:23:15 PM3/29/04
to

There's nothing in the ACPI spec that precludes recursive methods.
However, I agree that it is a very scary thing to do. For this reason,
I have the iASL compiler issue a remark when it detects a recursive
method call.

All AML interpreters that I know of implement nested and recursive
method calls without chewing up the kernel stack, i.e., a state is
allocated for each nested call and linked to the previous method state.

Bob


-----Original Message-----
From: Bruno Ducrot [mailto:duc...@poupinou.org]
Sent: Sunday, March 28, 2004 7:57 AM
To: Moore, Robert
Cc: Nate Lawson; acp...@jp.FreeBSD.org; cur...@freebsd.org
Subject: Re: [acpi-jp 3117] RE: ACPI-CA 20040311 imported

Nate Lawson

unread,
Mar 30, 2004, 6:07:55 PM3/30/04
to
On Mon, 29 Mar 2004, Moore, Robert wrote:
> There's nothing in the ACPI spec that precludes recursive methods.
> However, I agree that it is a very scary thing to do. For this reason,
> I have the iASL compiler issue a remark when it detects a recursive
> method call.
>
> All AML interpreters that I know of implement nested and recursive
> method calls without chewing up the kernel stack, i.e., a state is
> allocated for each nested call and linked to the previous method state.

Thanks for the info. I've disabled serialized methods by default now and
left _OSI enabled by default. This matches the Linux approach.

-Nate

0 new messages