The gory details are at
<http://bugzilla.kernel.org/show_bug.cgi?id=5989>, but the short
summary:
With 2.6.15, S3 sleep and wake were 98% fine (once in a while waking
would hang, but I haven't managed to reproduce it). However, with
2.6.16-rc1 with the acpi-20060113 patch, the first sleep and wake goes
fine and the second sleep hangs at the 'Stopping tasks'.
With tons of debugging turned on, the second sleep does not hang, but
the wakeup hangs. With 0x1F as the acpi debug_level, the second sleep
still hangs and produces some output across a serial console. In the
second sleep (after the second 'Stopping tasks'), it endlessly repeats
a short sequence of
exregion-0182 ...
exregion-0287 ...
exregion-0182 ...
The machine is a TP 600X with the latest (1.11) BIOS and a fixed DSDT
so that it can S3 sleep at all.
-Sanjoy
`Never underestimate the evil of which men of power are capable.'
--Bertrand Russell, _War Crimes in Vietnam_, chapter 1.
Hi.
On Saturday 04 February 2006 15:02, Sanjoy Mahajan wrote:
> The gory details are at
> <http://bugzilla.kernel.org/show_bug.cgi?id=5989>, but the short
> summary:
>
> With 2.6.15, S3 sleep and wake were 98% fine (once in a while waking
> would hang, but I haven't managed to reproduce it). However, with
> 2.6.16-rc1 with the acpi-20060113 patch, the first sleep and wake goes
> fine and the second sleep hangs at the 'Stopping tasks'.
After the first suspend, do you have any processes sucking all available
cpu? This sounds like a thread that has been added since 2.6.15, which is
being told to enter the freezer, but isn't doing it. They usually end up
sucking cpu afterwards.
Regards,
Nigel
> With tons of debugging turned on, the second sleep does not hang, but
> the wakeup hangs. With 0x1F as the acpi debug_level, the second sleep
> still hangs and produces some output across a serial console. In the
> second sleep (after the second 'Stopping tasks'), it endlessly repeats
> a short sequence of
>
> exregion-0182 ...
> exregion-0287 ...
> exregion-0182 ...
>
> The machine is a TP 600X with the latest (1.11) BIOS and a fixed DSDT
> so that it can S3 sleep at all.
>
> -Sanjoy
>
> `Never underestimate the evil of which men of power are capable.'
> --Bertrand Russell, _War Crimes in Vietnam_, chapter 1.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel"
> in the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
> After the first suspend, do you have any processes sucking all
> available cpu? This sounds like a thread that has been added since
> 2.6.15, which is being told to enter the freezer, but isn't doing
> it. They usually end up sucking cpu afterwards.
A good thought. I just tried it again. The system woke up from the
first S3 sleep with nothing chewing CPU. Just as a check, the second
S3 sleep still hangs with the repeating exregion-* messages.
I also tried vanilla 2.6.16-rc2 (which includes the latest ACPICA
releases in it), and it has the same problem.
-Sanjoy
`Never underestimate the evil of which men of power are capable.'
--Bertrand Russell, _War Crimes in Vietnam_, chapter 1.
Hi Bernard.
On Sunday 05 February 2006 06:53, Sanjoy Mahajan wrote:
> > After the first suspend, do you have any processes sucking all
> > available cpu? This sounds like a thread that has been added since
> > 2.6.15, which is being told to enter the freezer, but isn't doing
> > it. They usually end up sucking cpu afterwards.
>
> A good thought. I just tried it again. The system woke up from the
> first S3 sleep with nothing chewing CPU. Just as a check, the second
> S3 sleep still hangs with the repeating exregion-* messages.
>
> I also tried vanilla 2.6.16-rc2 (which includes the latest ACPICA
> releases in it), and it has the same problem.
I think this is your department :)
Nigel
[ OOPS. Forward the wrong message. Will do the right one in a minute. Sorry! ]
Hmm.
Having control-R do reply to all isn't always a good idea, is it? :)
Sorry for the spam!
Nigel