Here's what the MS interpreter does for Stall(n);
1) If n <=3D 255 (MAX_BYTE), perform the stall.
2) If n > 255, throw an error and abort the control method.
In this case, I suggest that we simply duplicate the MS behavior, it
seems like a good compromise and also provides ACPI CA with exact
From: Nate Lawson [mailto:nate@...
Sent: Wednesday, October 01, 2003 10:27 AM
To: Matthew Wilcox
Cc: Moore, Robert; acpi-devel@...
Subject: Re: [ACPI] [PATCH] Stall semantics
On Wed, 1 Oct 2003, Matthew Wilcox wrote:
> On Wed, Oct 01, 2003 at 09:59:49AM -0700, Nate Lawson wrote:
> > Let me quote that line again:
> > > Because of this, delays longer than 100 microseconds must use
> > > instead of Stall.
> > The current code is incorrect. It uses Stall (i.e. a delay loop)
> > waits of up to 1000 us, not 100 us like the standard. My patch
> > code match the standard.
> > Your point is whether Sleep should automatically be called by OSPM
> > the AML specifies a Stall of more than a certain amount (let's stick
> > 100 us for this example). I believe OSPM can and should
> > call Sleep when the time requested exceeds the maximum for Stall.
> > that line again. The key word is "use". If OSPM automatically
> > the call, delays longer than 100 us will indeed _use_ Sleep instead
> > Stall. This gives correct, standard behavior even when the AML
> > originally match the standard.
> Fundamentally, we're outside the specification and into nasal demon
> territory. We can do whatever we like. The question is: what to do
> will break the least number of machines. Sleeping unexpectedly can
> break code -- this is why you can't schedule while holding a spinlock,
> for example. Of course, Stalling for too long is also a bad idea.
You're assuming the AML mistake is made both ways. If it is uniformly
made one way, it's easy to work around correctly.
> I think the current ACPI behaviour is probably adequate -- accommodate
> incopetent BIOS writers up to a point, then sleep, and damn them
It damns us OS vendors a different way in that we get unacceptably long
idle spin loops on some machines. Spinning for 1000 us is not correct
way you interpret the standard.
If we can't reach agreement, it's better to leave things the same. The
other part of my patch is still useful in reducing redundant code.