Re: [REGRESSION,STABLE,BISECTED] Hang on resume from standby in3.1.[56], 3.2-rc*

[Venki Pallipadi]

On Sat, Dec 24, 2011 at 1:12 PM, Joseph Salisbury
<josephtsalisbury@xxxxxxxxx> wrote:
>
>
> On Sat, Dec 24, 2011 at 2:47 PM, Michael Tokarev <mjt@xxxxxxxxxx> wrote:
>>
>> On 24.12.2011 20:51, Phil Miller wrote:
>> > On Sat, Dec 24, 2011 at 03:09, Michael Tokarev <mjt@xxxxxxxxxx> wrote:
>> >> On 24.12.2011 10:40, Phil Miller wrote:
>> >>> On Fri, Dec 23, 2011 at 11:31, Phil Miller <mille121@xxxxxxxxxxxx>
>> >>> wrote:
>> >>>> I've got a Dell Precision T1500 (lspci, dmidecode, and dmesg output
>> >>>> at
>> >>>> http://charm.cs.uiuc.edu/~phil/linux-suspend-hang/ ) that I generally
>> >>>> suspend when I'm out of the house or asleep, and wake up when I want
>> >>>> to use it. Sadly, a recent change to the kernel has disrupted that
>> >>>> happy state of affairs. When I run the most recent stable or
>> []
>> >> I  noticed that my host also stopped resuming with 3.1, and noted that
>> >> with 3.1.3 it works ok.  I'm now trying to revert this commit too, to
>> >> see if that's the problem.
>>
>> Actually that wasn't the issue.  After several iterations (which took
>> some time) I found out that I can't reproduce the hangs which I were
>> able to trigger trivially just yesterday.  I can only guess these hangs
>> were due to some other software components (gnome, X stuff, whatever)
>> which happened to be upgraded today too, together with the kernel, and
>> the problem went away.  I booted into kernel with which the system
>> definitely had the issue at hand (3.1.3), but it resumes from suspend
>> (both s2ram and s2disk) without any issue whatsoever, I did several
>> resumes of each kind in a row, intermixed them together.
>>
>> > I first noticed this using Debian unstable's packaged kernels, which
>> > call themselves 3.x.0, but actually get revved through the stable
>> > versions 3.x.y (I'll probably complain about that misnaming to them).
>> > The upgrade from 3.1.4 to 3.1.5 is where it broke, matching the
>> > bisection's results.
>>
>> So it looks like not all systems suffer from this issue...
>>
>> Please excuse me for the noize -- it really looked like the kernel
>> broke.
>>
>> Thanks,
>>
>> /mjt
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majordomo@xxxxxxxxxxxxxxx
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at  http://www.tux.org/lkml/
>
>
>
> This issue also happens in the 3.0 kernel.  A bisect and revert was done for
> a bug report[1].  Testing indicated the same commit caused the
> suspend/resume issue.
>

Both the reports here from Phil and Joe are with systems hav HPET MSI support
--
[    1.010213] HPET: 8 timers in total, 5 timers will be used for per-cpu timer
[    1.010221] hpet0: at MMIO 0xfed00000, IRQs 2, 8, 40, 41, 42, 43, 44, 0
[    1.010226] hpet0: 8 comparators, 64-bit 14.318180 MHz counter
[    1.014637] hpet: hpet2 irq 40 for MSI
[    1.014771] hpet: hpet3 irq 41 for MSI
[    1.018748] hpet: hpet4 irq 42 for MSI
[    1.022810] hpet: hpet5 irq 43 for MSI
[    1.026712] hpet: hpet6 irq 44 for MSI
--

The ordering issue addressed in
7c1e76897492d92b6a1c2d6892494d39ded9680c was found with HPET MSI.
So, it seems like change de28f25e8244c7353abed8de0c7792f5f883588c
opened up that ordering problem again.

Thomas: Is de28f25e8244c7353abed8de0c7792f5f883588c for a specific bug
or regression on some platform?

Thanks,
Venki

>
> Thanks,
>
> Joe
>
> [1] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/904569
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/