2.6.21-mm2: ACPI exception on resume

2.6.21-mm2: ACPI exception on resume

[Matt Mackall]

Starting with 2.6.21-mm2, I'm seeing occassional failures to resume
from suspend-to-ram on my Thinkpad R51. The screen will flash as it
usually does, then go black and the machine will become totally
unresponsive, even to holding down the power button for 30+ seconds.
But the hard drive light will occassionally flash, so the machine is
clearly not completely dead at this point.

The log contains this:

08:57:25 hub 1-0:1.0: over-current change on port 4
08:57:26 ACPI: EC: acpi_ec_wait timeout, status = 10, expect_event = 2
08:57:26 ACPI: EC: write_cmd timeout, command = 128
08:57:26 ACPI Exception (evregion-0424): AE_TIME, Returned by Handler for [EmbeddedControl] [20070126]
08:57:26 ACPI Exception (dswexec-0462): AE_TIME, While resolving operands for [OpcodeName unavailable] [20070126]
08:57:26 ACPI Error (psparse-0537): Method parse/execution failed [\_SB_.PCI0.LPC_.EC__.GBIF] (Node c203270c), AE_TIME
08:57:26 ACPI Error (psparse-0537): Method parse/execution failed [\_SB_.PCI0.LPC_.EC__.BAT0._BIF] (Node c2032644), AE_TIME
08:57:26 ACPI Exception (battery-0147): AE_TIME, Evaluating _BIF [20070126]
08:57:26 ACPI: EC: acpi_ec_wait timeout, status = 10, expect_event = 2
08:57:26 ACPI: EC: input buffer is not empty, aborting transaction
08:57:26 ACPI Exception (evregion-0424): AE_TIME, Returned by Handler for [EmbeddedControl] [20070126]
08:57:26 ACPI Error (psparse-0537): Method parse/execution failed [\_SB_.PCI0.LPC_.EC__.AC__._PSR] (Node c20324c8), AE_TIME
08:57:26 ACPI Exception (ac-0095): AE_TIME, Error reading AC Adapter state [20070126]
08:57:27 ACPI: EC: acpi_ec_wait timeout, status = 10, expect_event = 2
08:57:27 ACPI: EC: input buffer is not empty, aborting transaction
08:57:27 ACPI Exception (evregion-0424): AE_TIME, Returned by Handler for [EmbeddedControl] [20070126]
08:57:27 ACPI Exception (dswexec-0462): AE_TIME, While resolving operands for [OpcodeName unavailable] [20070126]
08:57:27 ACPI Error (psparse-0537): Method parse/execution failed [\_TZ_.THM0._TMP] (Node c202db30), AE_TIME
08:57:27 agpgart: Found an AGP 2.0 compliant device at 0000:00:00.0.
08:57:27 agpgart: Putting AGP V2 device at 0000:00:00.0 into 4x mode
08:57:27 agpgart: Putting AGP V2 device at 0000:01:00.0 into 4x mode
08:57:27 [drm] Loading R200 Microcode
08:57:27 ACPI: EC: acpi_ec_wait timeout, status = 10, expect_event = 2
08:57:27 ACPI: EC: input buffer is not empty, aborting transaction
08:57:28 ACPI: EC: acpi_ec_wait timeout, status = 10, expect_event = 2

followed by a continual stream of these:

08:57:32 ACPI Exception (evregion-0424): AE_TIME, Returned by Handler for [EmbeddedControl] [20070126]
08:57:32 ACPI Error (psparse-0537): Method parse/execution failed [\_SB_.PCI0.LPC_.EC__.AC__._PSR] (Node c20324c8), AE_TIME
08:57:32 ACPI Exception (ac-0095): AE_TIME, Error reading AC Adapter state [20070126]
08:57:33 ACPI: EC: acpi_ec_wait timeout, status = 10, expect_event = 2
08:57:33 ACPI: EC: input buffer is not empty, aborting transaction

-- 
Mathematics is the supreme nostalgia of our time.

Re: 2.6.21-mm2: ACPI exception on resume

[Rafael J. Wysocki]

Hi,

On Saturday, 19 May 2007 18:57, Matt Mackall wrote:
> Starting with 2.6.21-mm2, I'm seeing occassional failures to resume
> from suspend-to-ram on my Thinkpad R51. The screen will flash as it
> usually does, then go black and the machine will become totally
> unresponsive, even to holding down the power button for 30+ seconds.
> But the hard drive light will occassionally flash, so the machine is
> clearly not completely dead at this point.

Does the mainline (as of 2.6.22-rc2) do this?

Rafael

Re: 2.6.21-mm2: ACPI exception on resume

[Matt Mackall]

On Sat, May 19, 2007 at 08:24:16PM +0200, Rafael J. Wysocki wrote:
> Hi,
> 
> On Saturday, 19 May 2007 18:57, Matt Mackall wrote:
> > Starting with 2.6.21-mm2, I'm seeing occassional failures to resume
> > from suspend-to-ram on my Thinkpad R51. The screen will flash as it
> > usually does, then go black and the machine will become totally
> > unresponsive, even to holding down the power button for 30+ seconds.
> > But the hard drive light will occassionally flash, so the machine is
> > clearly not completely dead at this point.
> 
> Does the mainline (as of 2.6.22-rc2) do this?

Dunno. I've triggered it twice since -mm2 was released, never before
that point. -mm1 was fine.

-- 
Mathematics is the supreme nostalgia of our time.

Re: 2.6.21-mm2: ACPI exception on resume

[Rafael J. Wysocki]

On Sunday, 20 May 2007 00:40, Matt Mackall wrote:
> On Sat, May 19, 2007 at 08:24:16PM +0200, Rafael J. Wysocki wrote:
> > Hi,
> > 
> > On Saturday, 19 May 2007 18:57, Matt Mackall wrote:
> > > Starting with 2.6.21-mm2, I'm seeing occassional failures to resume
> > > from suspend-to-ram on my Thinkpad R51. The screen will flash as it
> > > usually does, then go black and the machine will become totally
> > > unresponsive, even to holding down the power button for 30+ seconds.
> > > But the hard drive light will occassionally flash, so the machine is
> > > clearly not completely dead at this point.
> > 
> > Does the mainline (as of 2.6.22-rc2) do this?
> 
> Dunno. I've triggered it twice since -mm2 was released, never before
> that point. -mm1 was fine.

Can you please test 2.6.22-rc2?

Rafael

Re: 2.6.21-mm2: ACPI exception on resume

[Henrique de Moraes Holschuh]

On Sat, 19 May 2007, Matt Mackall wrote:
> usually does, then go black and the machine will become totally
> unresponsive, even to holding down the power button for 30+ seconds.

Now, that means either the BIOS or EC have been thrown out of whack,
otherwise one of the two would have force-powered-off the machine a bit
after 10s.

Are you using the latest BIOS and EC firmware available?

If you are at the latest BIOS and EC releases, does ec_intr=0 fix the issue?

> 08:57:27 [drm] Loading R200 Microcode
> 08:57:27 ACPI: EC: acpi_ec_wait timeout, status = 10, expect_event = 2
> 08:57:27 ACPI: EC: input buffer is not empty, aborting transaction
> 08:57:28 ACPI: EC: acpi_ec_wait timeout, status = 10, expect_event = 2

Yep, EC is confused.  Not Good!

-- 
  "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: 2.6.21-mm2: ACPI exception on resume

[Matt Mackall]

On Sat, May 19, 2007 at 05:45:04PM -0300, Henrique de Moraes Holschuh wrote:
> On Sat, 19 May 2007, Matt Mackall wrote:
> > usually does, then go black and the machine will become totally
> > unresponsive, even to holding down the power button for 30+ seconds.
> 
> Now, that means either the BIOS or EC have been thrown out of whack,
> otherwise one of the two would have force-powered-off the machine a bit
> after 10s.
> 
> Are you using the latest BIOS and EC firmware available?

No, I've been running the same BIOS without issue for two years.

-- 
Mathematics is the supreme nostalgia of our time.

Re: 2.6.21-mm2: ACPI exception on resume

[Henrique de Moraes Holschuh]

On Sat, 19 May 2007, Matt Mackall wrote:
> On Sat, May 19, 2007 at 05:45:04PM -0300, Henrique de Moraes Holschuh wrote:
> > On Sat, 19 May 2007, Matt Mackall wrote:
> > > usually does, then go black and the machine will become totally
> > > unresponsive, even to holding down the power button for 30+ seconds.
> > 
> > Now, that means either the BIOS or EC have been thrown out of whack,
> > otherwise one of the two would have force-powered-off the machine a bit
> > after 10s.
> > 
> > Are you using the latest BIOS and EC firmware available?
> 
> No, I've been running the same BIOS without issue for two years.

Version of BIOS and EC firmware, please?  It is in the dmidecode output.

-- 
  "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: 2.6.21-mm2: ACPI exception on resume

[Matt Mackall]

On Sun, May 20, 2007 at 12:52:59AM -0300, Henrique de Moraes Holschuh wrote:
> > > On Sat, 19 May 2007, Matt Mackall wrote:
> > > > usually does, then go black and the machine will become totally
> > > > unresponsive, even to holding down the power button for 30+ seconds.
> > > 
> > > Now, that means either the BIOS or EC have been thrown out of whack,
> > > otherwise one of the two would have force-powered-off the machine a bit
> > > after 10s.
> > > 
> > > Are you using the latest BIOS and EC firmware available?
> > 
> > No, I've been running the same BIOS without issue for two years.
> 
> Version of BIOS and EC firmware, please?  It is in the dmidecode output.

BIOS Information
        Vendor: IBM
        Version: 1RETDHWW (3.13 )
        Release Date: 10/29/2004

No sign of any EC version in the output.

-- 
Mathematics is the supreme nostalgia of our time.

Re: 2.6.21-mm2: ACPI exception on resume

[Henrique de Moraes Holschuh]

On Mon, 21 May 2007, Matt Mackall wrote:
> BIOS Information
>         Vendor: IBM
>         Version: 1RETDHWW (3.13 )
>         Release Date: 10/29/2004
> 
> No sign of any EC version in the output.

This is a buggy, ancient version of the BIOS, which probably means you have
an old and slightly buggy EC firmware.  I recommend you to upgrade to BIOS
3.21 and EC 3.04.  See http://thinkwiki.org/wiki/BIOS_Upgrade for more
details.

-- 
  "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: 2.6.21-mm2: ACPI exception on resume

[Matt Mackall]

On Mon, May 21, 2007 at 08:03:49PM -0300, Henrique de Moraes Holschuh wrote:
> On Mon, 21 May 2007, Matt Mackall wrote:
> > BIOS Information
> >         Vendor: IBM
> >         Version: 1RETDHWW (3.13 )
> >         Release Date: 10/29/2004
> > 
> > No sign of any EC version in the output.
> 
> This is a buggy, ancient version of the BIOS, which probably means you have
> an old and slightly buggy EC firmware.  I recommend you to upgrade to BIOS
> 3.21 and EC 3.04.  See http://thinkwiki.org/wiki/BIOS_Upgrade for more
> details.

Really, I'd much prefer my kernel not regress instead. Updating
firmware is just introducing more potential instability and ignoring
the problem.

-- 
Mathematics is the supreme nostalgia of our time.

Re: 2.6.21-mm2: ACPI exception on resume

[Henrique de Moraes Holschuh]

On Tue, 22 May 2007, Matt Mackall wrote:
> On Mon, May 21, 2007 at 08:03:49PM -0300, Henrique de Moraes Holschuh wrote:
> > On Mon, 21 May 2007, Matt Mackall wrote:
> > > BIOS Information
> > >         Vendor: IBM
> > >         Version: 1RETDHWW (3.13 )
> > >         Release Date: 10/29/2004
> > > 
> > > No sign of any EC version in the output.
> > 
> > This is a buggy, ancient version of the BIOS, which probably means you have
> > an old and slightly buggy EC firmware.  I recommend you to upgrade to BIOS
> > 3.21 and EC 3.04.  See http://thinkwiki.org/wiki/BIOS_Upgrade for more
> > details.
> 
> Really, I'd much prefer my kernel not regress instead. Updating
> firmware is just introducing more potential instability and ignoring
> the problem.

We can't very much know if the kernel is really buggy, then.  I'd say we
need a report from someone with another thinkpad that uses the 1R BIOS that
has an up-to-date BIOS, to know for sure.  Since that includes the T41 and
T42, chances are others would have spoken up about it already if it affected
the more recent versions of the 1R BIOS.

-- 
  "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: 2.6.21-mm2: ACPI exception on resume

[Matt Mackall]

On Tue, May 22, 2007 at 09:19:43PM -0300, Henrique de Moraes Holschuh wrote:
> On Tue, 22 May 2007, Matt Mackall wrote:
> > On Mon, May 21, 2007 at 08:03:49PM -0300, Henrique de Moraes Holschuh wrote:
> > > On Mon, 21 May 2007, Matt Mackall wrote:
> > > > BIOS Information
> > > >         Vendor: IBM
> > > >         Version: 1RETDHWW (3.13 )
> > > >         Release Date: 10/29/2004
> > > > 
> > > > No sign of any EC version in the output.
> > > 
> > > This is a buggy, ancient version of the BIOS, which probably means you have
> > > an old and slightly buggy EC firmware.  I recommend you to upgrade to BIOS
> > > 3.21 and EC 3.04.  See http://thinkwiki.org/wiki/BIOS_Upgrade for more
> > > details.
> > 
> > Really, I'd much prefer my kernel not regress instead. Updating
> > firmware is just introducing more potential instability and ignoring
> > the problem.
> 
> We can't very much know if the kernel is really buggy, then.

Whether the 'bug' is in the firmware or the kernel, it is the kernel
that has regressed. Suspend worked fine for 2+ years before this.

Breaking working systems, either software or hardware, is a bad idea.
I shouldn't have to upgrade my BIOS to work with a new kernel any more
than I should have to upgrade my browser.

-- 
Mathematics is the supreme nostalgia of our time.

Re: 2.6.21-mm2: ACPI exception on resume

[Henrique de Moraes Holschuh]

On Tue, 22 May 2007, Matt Mackall wrote:
> Whether the 'bug' is in the firmware or the kernel, it is the kernel
> that has regressed. Suspend worked fine for 2+ years before this.

That means something, but not that much.  The kernel could have been doing
broken things for two years in ACPI that happened to not trigger a bug in
someone's firmware, for example.  And when the kernel was fixed (to, e.g.,
do it right by the spec or unbreak other firmwares that did it by the spec)
and that triggered the bug.

We really need to find the cause of the regression to know.

> Breaking working systems, either software or hardware, is a bad idea.

We shouldn't do it for frivoulous reasons, of course.

> I shouldn't have to upgrade my BIOS to work with a new kernel any more
> than I should have to upgrade my browser.

We don't agree there, as you are not talking about a stable kernel series.

And btw, unless you hunt down someone that also has the bug and uses an
up-to-date BIOS (or something else to give an extra data point that discards
a possible firmware bug in your version of the BIOS), or bissect to pinpoint
what caused the regression, this thread will go nowhere.

-- 
  "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: 2.6.21-mm2: ACPI exception on resume

[Ray Lee]

On 5/22/07, Henrique de Moraes Holschuh <hmh@hmh.eng.br> wrote:
> > I shouldn't have to upgrade my BIOS to work with a new kernel any more
> > than I should have to upgrade my browser.
>
> We don't agree there, as you are not talking about a stable kernel series.

Ah, so you're planning on submitting these patches for 2.7 then? 2.6
is perpetually stable. Matt is quite correct; feel free to ask for
clarifications from Linus et al if you need guidance.

Re: 2.6.21-mm2: ACPI exception on resume

[Henrique de Moraes Holschuh]

On Tue, 22 May 2007, Ray Lee wrote:
> On 5/22/07, Henrique de Moraes Holschuh <hmh@hmh.eng.br> wrote:
> >> I shouldn't have to upgrade my BIOS to work with a new kernel any more
> >> than I should have to upgrade my browser.
> >
> >We don't agree there, as you are not talking about a stable kernel series.
> 
> Ah, so you're planning on submitting these patches for 2.7 then? 2.6
> is perpetually stable. Matt is quite correct; feel free to ask for
> clarifications from Linus et al if you need guidance.

2.6.x.y is stable.  2.6.x is not by any reasonably strict definition of
stable.  Unless you can explain how the stuff that went in 2.6.21 could be
added to a stable series kernel, do not even bother replying.

And for the record, the patches are NOT mine, but since I am the one usually
dealing directly with thinkpad firmware, I jumped in to help debug things as
a thinkpad firmware was *probably* to blame.

-- 
  "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: 2.6.21-mm2: ACPI exception on resume

[Ray Lee]

On 5/23/07, Henrique de Moraes Holschuh <hmh@hmh.eng.br> wrote:
> On Tue, 22 May 2007, Ray Lee wrote:
> > On 5/22/07, Henrique de Moraes Holschuh <hmh@hmh.eng.br> wrote:
> > >We don't agree there, as you are not talking about a stable kernel series.
> >
> > Ah, so you're planning on submitting these patches for 2.7 then? 2.6
> > is perpetually stable. Matt is quite correct; feel free to ask for
> > clarifications from Linus et al if you need guidance.
>
> 2.6.x.y is stable.  2.6.x is not by any reasonably strict definition of
> stable.  Unless you can explain how the stuff that went in 2.6.21 could be
> added to a stable series kernel, do not even bother replying.

I owe you an apology, I was a bit snippy there. However, to answer
your question, they got in by accident and lax testing on the part of
the submitters. As someone who has written and maintains a lot of
deployed software that gets upgraded live, I feel comfortable in
saying that maintaining a perpetually stable software series while
allowing new features is entirely possible.

The problem is when the maintainers/submitters get the wrong
impression, that 2.6.x.y is there to clean up the mess they made. The
best of all worlds, in terms of everybody's time spent debugging and
fixing, is if the patches are well-tested before submission. If the
submitters feel that 2.6.x is an unstable series, then they have no
reason to heavily test that code before it goes in.

Which is the crux of my problem with your statement. I feel we
shouldn't give the wrong idea to those authors. They need to know that
the expectation is that 2.6.x is a stable series, and 2.6.x.y is for
dealing with unavoidable mistakes.

> And for the record, the patches are NOT mine, but since I am the one usually
> dealing directly with thinkpad firmware, I jumped in to help debug things as
> a thinkpad firmware was *probably* to blame.

Again, my apologies; I was out of line. Thanks for helping.

Ray

Re: 2.6.21-mm2: ACPI exception on resume

[Henrique de Moraes Holschuh]

On Wed, 23 May 2007, Ray Lee wrote:
> The problem is when the maintainers/submitters get the wrong
> impression, that 2.6.x.y is there to clean up the mess they made. The

Now, that I agree with completely.

> Which is the crux of my problem with your statement. I feel we
> shouldn't give the wrong idea to those authors. They need to know that
> the expectation is that 2.6.x is a stable series, and 2.6.x.y is for
> dealing with unavoidable mistakes.

Well, the only case where I feel a regression is justified is one where it
is caused by a bug in the firmware or the hardware.

At which point my personal opinion is that users of firmware/hardware *that
have a fix available* are to be told to apply the fix, unless the problem is
so serious that it could potentially cause extreme damage (loss of human
life, permanent hardware damage, major data loss).

If there is no fix the user can apply, then it really depends on how
damaging it is to work around the issue for others: you don't punish those
who have non-broken stuff to avoid problems for those that have broken
stuff.

Fortunately, most of the time one can come up with a fix that causes little
to no loss to those with non-broken hardware/firmware.

-- 
  "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: 2.6.21-mm2: ACPI exception on resume

[Ray Lee]

On 5/23/07, Henrique de Moraes Holschuh <hmh@hmh.eng.br> wrote:
> On Wed, 23 May 2007, Ray Lee wrote:
> > Which is the crux of my problem with your statement. I feel we
> > shouldn't give the wrong idea to those authors. They need to know that
> > the expectation is that 2.6.x is a stable series, and 2.6.x.y is for
> > dealing with unavoidable mistakes.
>
> Well, the only case where I feel a regression is justified is one where it
> is caused by a bug in the firmware or the hardware.

Here's the problem. Each of the people testing the kernel is a 'canary
in the coalmine.' If one person is having trouble, then it's likely
that there are ten more that will have the same issue. The real
problem here is that those other ten people aren't going to know how
to fix it, other than "it used to work, so obviously the kernel is now
doing something wrong."

This is particularly bad for firmware, where upgrading it may
introduce new regressions. I understand that there are broken
firmwares out there -- I have a laptop with one.  But there needs to
be a way to support broken systems and the sane ones simultaneously.
This is a requirement for the ACPI tree, for example, and it seems to
work.

All of this is assuming that the firmware really was at fault. It's
also possible that it's just doing something different than before,
and both behaviors are valid and should be dealt with gracefully.

> At which point my personal opinion is that users of firmware/hardware *that
> have a fix available* are to be told to apply the fix, unless the problem is
> so serious that it could potentially cause extreme damage (loss of human
> life, permanent hardware damage, major data loss).

Those are extreme. My point is that if you know who all those people
are, and are willing to contact them, then sure, that's viable.
Otherwise, the bottom line is that the kernel used to deal with a
problem gracefully, and now it doesn't. There's no telling how many
other people will get bit by the same problem, and most of those
people aren't going to know what to do about it, other than to
downgrade the kernel, and wait for it to magically get fixed by
someone else.

> If there is no fix the user can apply, then it really depends on how
> damaging it is to work around the issue for others: you don't punish those
> who have non-broken stuff to avoid problems for those that have broken
> stuff.

I understand your point of view, but another way to look at it is that
we always want to make forward progress on the code. If we don't, then
we're never going to have a good metric (measure) of how we're doing.

> Fortunately, most of the time one can come up with a fix that causes little
> to no loss to those with non-broken hardware/firmware.

And I'm sure those with the Big Brains(tm) can do so again.

Thanks,

Ray

Re: 2.6.21-mm2: ACPI exception on resume

[Pavel Machek]

Hi!

> > >> I shouldn't have to upgrade my BIOS to work with a new kernel any more
> > >> than I should have to upgrade my browser.
> > >
> > >We don't agree there, as you are not talking about a stable kernel series.
> > 
> > Ah, so you're planning on submitting these patches for 2.7 then? 2.6
> > is perpetually stable. Matt is quite correct; feel free to ask for
> > clarifications from Linus et al if you need guidance.
> 
> 2.6.x.y is stable.  2.6.x is not by any reasonably strict definition of

Wrong. 2.6.x is stable as in 'must not break userspace, must not
regress'.

							Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: 2.6.21-mm2: ACPI exception on resume

[Rafael J. Wysocki]

On Wednesday, 23 May 2007 03:48, Matt Mackall wrote:
> On Tue, May 22, 2007 at 09:19:43PM -0300, Henrique de Moraes Holschuh wrote:
> > On Tue, 22 May 2007, Matt Mackall wrote:
> > > On Mon, May 21, 2007 at 08:03:49PM -0300, Henrique de Moraes Holschuh wrote:
> > > > On Mon, 21 May 2007, Matt Mackall wrote:
> > > > > BIOS Information
> > > > >         Vendor: IBM
> > > > >         Version: 1RETDHWW (3.13 )
> > > > >         Release Date: 10/29/2004
> > > > > 
> > > > > No sign of any EC version in the output.
> > > > 
> > > > This is a buggy, ancient version of the BIOS, which probably means you have
> > > > an old and slightly buggy EC firmware.  I recommend you to upgrade to BIOS
> > > > 3.21 and EC 3.04.  See http://thinkwiki.org/wiki/BIOS_Upgrade for more
> > > > details.
> > > 
> > > Really, I'd much prefer my kernel not regress instead. Updating
> > > firmware is just introducing more potential instability and ignoring
> > > the problem.
> > 
> > We can't very much know if the kernel is really buggy, then.
> 
> Whether the 'bug' is in the firmware or the kernel, it is the kernel
> that has regressed. Suspend worked fine for 2+ years before this.
> 
> Breaking working systems, either software or hardware, is a bad idea.
> I shouldn't have to upgrade my BIOS to work with a new kernel any more
> than I should have to upgrade my browser.

While I agree with that, it would really be helpful if you tested the latest -rc
kernel and saw if the bug was present in there.

If the bug is not present in the latest -rc, it'll be possible to identify the
patch that causes it to appear in -mm and find the reason of the breakage.

Greetings,
Rafael

Re: 2.6.21-mm2: ACPI exception on resume

[Henrique de Moraes Holschuh]

On Wed, 23 May 2007, Rafael J. Wysocki wrote:
> While I agree with that, it would really be helpful if you tested the latest -rc
> kernel and saw if the bug was present in there.
> 
> If the bug is not present in the latest -rc, it'll be possible to identify the
> patch that causes it to appear in -mm and find the reason of the breakage.

And, once we know the reason, we will be able to find out how to best fix the
problem.

So, do please test latest -rc, or bissect to the last known-good kernel. As
I said, we need further data points to do anything.

-- 
  "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: 2.6.21-mm2: ACPI exception on resume

[Matt Mackall]

On Wed, May 23, 2007 at 02:13:30PM -0300, Henrique de Moraes Holschuh wrote:
> On Wed, 23 May 2007, Rafael J. Wysocki wrote:
> > While I agree with that, it would really be helpful if you tested the latest -rc
> > kernel and saw if the bug was present in there.
> > 
> > If the bug is not present in the latest -rc, it'll be possible to identify the
> > patch that causes it to appear in -mm and find the reason of the breakage.
> 
> And, once we know the reason, we will be able to find out how to best fix the
> problem.
> 
> So, do please test latest -rc, or bissect to the last known-good kernel. As
> I said, we need further data points to do anything.

This isn't conclusive as this bug is fairly hard to trigger, but it
looks like the culprit may have been this patch and not anything in
-mm or mainline. So the below patch doesn't help the problem it was
intended for (lid switch no longer wakes up S2R after a S2D cycle) and
appears to be implicated in making my EC unhappy.

-----------------

Can you please check if the appended debug patch helps?

Rafael

---
 kernel/power/disk.c |    4 ++--
 kernel/power/user.c |    8 ++++----
 2 files changed, 6 insertions(+), 6 deletions(-)

Index: linux-2.6.21-rc7/kernel/power/disk.c
===================================================================
--- linux-2.6.21-rc7.orig/kernel/power/disk.c
+++ linux-2.6.21-rc7/kernel/power/disk.c
@@ -170,9 +170,9 @@ int pm_suspend_disk(void)
 
 	if (in_suspend) {
 		enable_nonboot_cpus();
-		platform_finish();
 		device_resume();
 		resume_console();
+		platform_finish();
 		pr_debug("PM: writing image.\n");
 		error = swsusp_write();
 		if (!error)
@@ -189,9 +189,9 @@ int pm_suspend_disk(void)
  Enable_cpus:
 	enable_nonboot_cpus();
  Resume_devices:
-	platform_finish();
 	device_resume();
 	resume_console();
+	platform_finish();
  Thaw:
 	unprepare_processes();
  Finish:
Index: linux-2.6.21-rc7/kernel/power/user.c
===================================================================
--- linux-2.6.21-rc7.orig/kernel/power/user.c
+++ linux-2.6.21-rc7/kernel/power/user.c
@@ -170,11 +170,11 @@ static inline int snapshot_suspend(int p
 	}
 	enable_nonboot_cpus();
  Resume_devices:
+	device_resume();
+	resume_console();
 	if (platform_suspend)
 		platform_finish();
 
-	device_resume();
-	resume_console();
  Finish:
 	mutex_unlock(&pm_mutex);
 	return error;
@@ -202,11 +202,11 @@ static inline int snapshot_restore(int p
 
 	enable_nonboot_cpus();
  Resume_devices:
+	device_resume();
+	resume_console();
 	if (platform_suspend)
 		platform_finish();
 
-	device_resume();
-	resume_console();
  Finish:
 	pm_restore_console();
 	mutex_unlock(&pm_mutex);


-- 
Mathematics is the supreme nostalgia of our time.

Re: 2.6.21-mm2: ACPI exception on resume

[Rafael J. Wysocki]

On Wednesday, 23 May 2007 19:48, Matt Mackall wrote:
> On Wed, May 23, 2007 at 02:13:30PM -0300, Henrique de Moraes Holschuh wrote:
> > On Wed, 23 May 2007, Rafael J. Wysocki wrote:
> > > While I agree with that, it would really be helpful if you tested the latest -rc
> > > kernel and saw if the bug was present in there.
> > > 
> > > If the bug is not present in the latest -rc, it'll be possible to identify the
> > > patch that causes it to appear in -mm and find the reason of the breakage.
> > 
> > And, once we know the reason, we will be able to find out how to best fix the
> > problem.
> > 
> > So, do please test latest -rc, or bissect to the last known-good kernel. As
> > I said, we need further data points to do anything.
> 
> This isn't conclusive as this bug is fairly hard to trigger, but it
> looks like the culprit may have been this patch and not anything in
> -mm or mainline. So the below patch doesn't help the problem it was
> intended for (lid switch no longer wakes up S2R after a S2D cycle) and
> appears to be implicated in making my EC unhappy.

Yes, this was just a debug patch.

We broke quite a few systems by placing platform_finish() before
device_resume() and I suspected your system could be one of them.

Apparently, that's not the case.

In 2.6.22-rc2 we also moved platform_prepare() to after device_suspend()
and that's why I asked you to test this kernel.

Greetings,
Rafael

Re: 2.6.21-mm2: ACPI exception on resume

[Matt Mackall]

On Wed, May 23, 2007 at 10:56:27PM +0200, Rafael J. Wysocki wrote:
> On Wednesday, 23 May 2007 19:48, Matt Mackall wrote:
> > On Wed, May 23, 2007 at 02:13:30PM -0300, Henrique de Moraes Holschuh wrote:
> > > On Wed, 23 May 2007, Rafael J. Wysocki wrote:
> > > > While I agree with that, it would really be helpful if you tested the latest -rc
> > > > kernel and saw if the bug was present in there.
> > > > 
> > > > If the bug is not present in the latest -rc, it'll be possible to identify the
> > > > patch that causes it to appear in -mm and find the reason of the breakage.
> > > 
> > > And, once we know the reason, we will be able to find out how to best fix the
> > > problem.
> > > 
> > > So, do please test latest -rc, or bissect to the last known-good kernel. As
> > > I said, we need further data points to do anything.
> > 
> > This isn't conclusive as this bug is fairly hard to trigger, but it
> > looks like the culprit may have been this patch and not anything in
> > -mm or mainline. So the below patch doesn't help the problem it was
> > intended for (lid switch no longer wakes up S2R after a S2D cycle) and
> > appears to be implicated in making my EC unhappy.
> 
> Yes, this was just a debug patch.
> 
> We broke quite a few systems by placing platform_finish() before
> device_resume() and I suspected your system could be one of them.
> 
> Apparently, that's not the case.
> 
> In 2.6.22-rc2 we also moved platform_prepare() to after device_suspend()
> and that's why I asked you to test this kernel.

Will get to it eventually.

-- 
Mathematics is the supreme nostalgia of our time.