Hi,
as of kernel 2.6.34 I sometimes get a strange hang during suspend to
RAM. After echo mem > /sys/power/state, the suspend script hangs, Xorg
eats 100% CPU, and the desktop is frozen. I can kill the script and the
computer will then suspend and resume fine. The kernel log shows
nothing interesting when the hang happens:
usblp0: removed
usbcore: deregistering interface driver dvb_usb_vp7045
dvb-usb: Twinhan USB2.0 DVB-T receiver (TwinhanDTV Alpha/MagicBox II)
successfully deinitialized and disconnected.
PM: Syncing filesystems ... done.
Is this a known problem? I had rock stable suspend with 2.3.33.x. The
computer is a Mac mini Core2 Duo with i945 graphics. I use KMS. I will
compile a kernel with suspend debug to get more information if the hang
happens next time.
Regards,
Tino
On Wednesday, June 09, 2010, Tino Keitel wrote:
> Hi,
>
> as of kernel 2.6.34 I sometimes get a strange hang during suspend to
> RAM. After echo mem > /sys/power/state, the suspend script hangs, Xorg
> eats 100% CPU, and the desktop is frozen. I can kill the script and the
> computer will then suspend and resume fine. The kernel log shows
> nothing interesting when the hang happens:
>
> usblp0: removed
> usbcore: deregistering interface driver dvb_usb_vp7045
> dvb-usb: Twinhan USB2.0 DVB-T receiver (TwinhanDTV Alpha/MagicBox II)
> successfully deinitialized and disconnected.
> PM: Syncing filesystems ... done.
>
> Is this a known problem?
No, it's not.
> I had rock stable suspend with 2.3.33.x. The
> computer is a Mac mini Core2 Duo with i945 graphics. I use KMS. I will
> compile a kernel with suspend debug to get more information if the hang
> happens next time.
Yes, please try to get more information.
Rafael
10.06.2010 03:42, Rafael J. Wysocki пишет:
> On Wednesday, June 09, 2010, Tino Keitel wrote:
>> Hi,
>>
>> as of kernel 2.6.34 I sometimes get a strange hang during suspend to
>> RAM. After echo mem> /sys/power/state, the suspend script hangs, Xorg
>> eats 100% CPU, and the desktop is frozen. I can kill the script and the
>> computer will then suspend and resume fine. The kernel log shows
>> nothing interesting when the hang happens:
>>
>> usblp0: removed
>> usbcore: deregistering interface driver dvb_usb_vp7045
>> dvb-usb: Twinhan USB2.0 DVB-T receiver (TwinhanDTV Alpha/MagicBox II)
>> successfully deinitialized and disconnected.
>> PM: Syncing filesystems ... done.
Sounds very much like the problem I have with 2.6.34 final. Did not
happen with 2.6.34-rc7 which suspended just fine, but happens quite
regularly on 2.6.34 final - not every suspend but each 2nd or 3rd
attempt. I stopped doing suspend-to-ram due to this, because it's
unreliable. Suspend-to-disk works just fine.
>> Is this a known problem?
>
> No, it's not.
>
>> I had rock stable suspend with 2.3.33.x. The
>> computer is a Mac mini Core2 Duo with i945 graphics. I use KMS. I will
>> compile a kernel with suspend debug to get more information if the hang
>> happens next time.
It's amd780g athlon-based machine here, with radeon graphics, also with KMS.
> Yes, please try to get more information.
Got it ;)
/mjt
On Thu, Jun 10, 2010 at 10:05:05 +0400, Michael Tokarev wrote:
[...]
> Sounds very much like the problem I have with 2.6.34 final. Did not
> happen with 2.6.34-rc7 which suspended just fine, but happens quite
I also had this hang before -rc7.
Regards,
Tino
On Thursday, June 10, 2010, Michael Tokarev wrote:
> 10.06.2010 03:42, Rafael J. Wysocki пишет:
> > On Wednesday, June 09, 2010, Tino Keitel wrote:
> >> Hi,
> >>
> >> as of kernel 2.6.34 I sometimes get a strange hang during suspend to
> >> RAM. After echo mem> /sys/power/state, the suspend script hangs, Xorg
> >> eats 100% CPU, and the desktop is frozen. I can kill the script and the
> >> computer will then suspend and resume fine. The kernel log shows
> >> nothing interesting when the hang happens:
> >>
> >> usblp0: removed
> >> usbcore: deregistering interface driver dvb_usb_vp7045
> >> dvb-usb: Twinhan USB2.0 DVB-T receiver (TwinhanDTV Alpha/MagicBox II)
> >> successfully deinitialized and disconnected.
> >> PM: Syncing filesystems ... done.
>
> Sounds very much like the problem I have with 2.6.34 final. Did not
> happen with 2.6.34-rc7 which suspended just fine, but happens quite
> regularly on 2.6.34 final - not every suspend but each 2nd or 3rd
> attempt. I stopped doing suspend-to-ram due to this, because it's
> unreliable. Suspend-to-disk works just fine.
Well, it would be helpful to check which commit between 2.6.34-rc7 and
2.6.34 final broke that for you (there were not too many commits between these
two kernels, so it shouldn't be too much work).
> >> Is this a known problem?
> >
> > No, it's not.
> >
> >> I had rock stable suspend with 2.3.33.x. The
> >> computer is a Mac mini Core2 Duo with i945 graphics. I use KMS. I will
> >> compile a kernel with suspend debug to get more information if the hang
> >> happens next time.
>
> It's amd780g athlon-based machine here, with radeon graphics, also with KMS.
>
> > Yes, please try to get more information.
>
> Got it ;)
That still doesn't really help to diagnose the problem.
Rafael
Michael Tokarev wrote:
> 10.06.2010 03:42, Rafael J. Wysocki пишет:
>> On Wednesday, June 09, 2010, Tino Keitel wrote:
>>> Hi,
>>>
>>> as of kernel 2.6.34 I sometimes get a strange hang during suspend to
>>> RAM. After echo mem> /sys/power/state, the suspend script hangs, Xorg
>>> eats 100% CPU, and the desktop is frozen. I can kill the script and the
>>> computer will then suspend and resume fine. The kernel log shows
>>> nothing interesting when the hang happens:
>>>
>>> usblp0: removed
>>> usbcore: deregistering interface driver dvb_usb_vp7045
>>> dvb-usb: Twinhan USB2.0 DVB-T receiver (TwinhanDTV Alpha/MagicBox II)
>>> successfully deinitialized and disconnected.
>>> PM: Syncing filesystems ... done.
>
> Sounds very much like the problem I have with 2.6.34 final. Did not
> happen with 2.6.34-rc7 which suspended just fine, but happens quite
> regularly on 2.6.34 final - not every suspend but each 2nd or 3rd
> attempt. I stopped doing suspend-to-ram due to this, because it's
> unreliable. Suspend-to-disk works just fine.
>
>>> Is this a known problem?
>>
There are two things you can try if you wish, one is to go the text console
before suspend, the other is to run your system in VESA video mode (assuming you
are a lucky person and any other mode is supported).
I'm not running on 2.6.34 for production (2.6.33.5) but I did try when it first
came out, and saw some issues there.
>> No, it's not.
>>
>>> I had rock stable suspend with 2.3.33.x. The
>>> computer is a Mac mini Core2 Duo with i945 graphics. I use KMS. I will
>>> compile a kernel with suspend debug to get more information if the hang
>>> happens next time.
>
> It's amd780g athlon-based machine here, with radeon graphics, also with
> KMS.
>
>> Yes, please try to get more information.
>
> Got it ;)
>
> /mjt
--
Bill Davidsen <[email protected]>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
On Thursday, June 10, 2010, Michael Tokarev wrote:
> 10.06.2010 03:42, Rafael J. Wysocki пишет:
> > On Wednesday, June 09, 2010, Tino Keitel wrote:
> >> Hi,
> >>
> >> as of kernel 2.6.34 I sometimes get a strange hang during suspend to
> >> RAM. After echo mem> /sys/power/state, the suspend script hangs, Xorg
> >> eats 100% CPU, and the desktop is frozen. I can kill the script and the
> >> computer will then suspend and resume fine. The kernel log shows
> >> nothing interesting when the hang happens:
> >>
> >> usblp0: removed
> >> usbcore: deregistering interface driver dvb_usb_vp7045
> >> dvb-usb: Twinhan USB2.0 DVB-T receiver (TwinhanDTV Alpha/MagicBox II)
> >> successfully deinitialized and disconnected.
> >> PM: Syncing filesystems ... done.
>
> Sounds very much like the problem I have with 2.6.34 final. Did not
> happen with 2.6.34-rc7 which suspended just fine, but happens quite
> regularly on 2.6.34 final - not every suspend but each 2nd or 3rd
> attempt. I stopped doing suspend-to-ram due to this, because it's
> unreliable. Suspend-to-disk works just fine.
Can you both try to do "echo 0 > /sys/power/pm_async" and check if suspend
works with that?
Rafael
On środa, 9 czerwca 2010 o 19:53:56 Tino Keitel wrote:
> Hi,
>
> as of kernel 2.6.34 I sometimes get a strange hang during suspend to
> RAM. After echo mem > /sys/power/state, the suspend script hangs, Xorg
> eats 100% CPU, and the desktop is frozen. I can kill the script and the
> computer will then suspend and resume fine. The kernel log shows
> nothing interesting when the hang happens:
>
I created a Bugzilla entry at
https://bugzilla.kernel.org/show_bug.cgi?id=16207
for your bug report, please add your address to the CC list in there, thanks!
--
Maciej Rutecki
http://www.maciek.unixy.pl
Hi,
this nasty bug did not appear after I enabled suspend debugging first,
but now it did:
2010-06-20_22:40:31.22927 kern.info: usbcore: deregistering interface driver dvb_usb_vp7045
2010-06-20_22:40:31.24960 kern.debug: usb 1-6: __pm_runtime_resume()!
2010-06-20_22:40:31.24968 kern.debug: usb 1-6: __pm_runtime_resume() returns 1!
2010-06-20_22:40:31.24969 kern.debug: PM: Removing info for No Bus:dvb0.frontend0
2010-06-20_22:40:31.24971 kern.debug: PM: Removing info for No Bus:dvb0.net0
2010-06-20_22:40:31.24972 kern.debug: PM: Removing info for No Bus:dvb0.demux0
2010-06-20_22:40:31.24973 kern.debug: PM: Removing info for No Bus:dvb0.dvr0
2010-06-20_22:40:31.24974 kern.info: dvb-usb: Twinhan USB2.0 DVB-T receiver (TwinhanDTV Alpha/MagicBox II) successfully deinitialized and disconnected.
2010-06-20_22:40:32.26675 kern.info: PM: Syncing filesystems ... done.
2010-06-20_22:40:32.39011 kern.debug: PM: Preparing system for mem sleep
When I killed the suspend script which hung at the echo mem >
/sys/power/state line, the computer suspended. After wakeup, the kernel
log lines after the line above look like this:
2010-06-20_22:49:10.28745 kern.warn: Freezing user space processes ... (elapsed 0.02 seconds) done.
2010-06-20_22:49:10.28748 kern.warn: Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.
2010-06-20_22:49:10.28748 kern.debug: PM: Entering mem sleep
2010-06-20_22:49:10.28749 kern.warn: Suspending console(s) (use no_console_suspend to debug)
I also attached the full kernel log since the boot.
Regards,
Tino
On Monday, June 21, 2010, Tino Keitel wrote:
> Hi,
>
> this nasty bug did not appear after I enabled suspend debugging first,
> but now it did:
>
> 2010-06-20_22:40:31.22927 kern.info: usbcore: deregistering interface driver dvb_usb_vp7045
> 2010-06-20_22:40:31.24960 kern.debug: usb 1-6: __pm_runtime_resume()!
> 2010-06-20_22:40:31.24968 kern.debug: usb 1-6: __pm_runtime_resume() returns 1!
> 2010-06-20_22:40:31.24969 kern.debug: PM: Removing info for No Bus:dvb0.frontend0
> 2010-06-20_22:40:31.24971 kern.debug: PM: Removing info for No Bus:dvb0.net0
> 2010-06-20_22:40:31.24972 kern.debug: PM: Removing info for No Bus:dvb0.demux0
> 2010-06-20_22:40:31.24973 kern.debug: PM: Removing info for No Bus:dvb0.dvr0
> 2010-06-20_22:40:31.24974 kern.info: dvb-usb: Twinhan USB2.0 DVB-T receiver (TwinhanDTV Alpha/MagicBox II) successfully deinitialized and disconnected.
> 2010-06-20_22:40:32.26675 kern.info: PM: Syncing filesystems ... done.
> 2010-06-20_22:40:32.39011 kern.debug: PM: Preparing system for mem sleep
>
> When I killed the suspend script which hung at the echo mem >
> /sys/power/state line, the computer suspended. After wakeup, the kernel
> log lines after the line above look like this:
>
> 2010-06-20_22:49:10.28745 kern.warn: Freezing user space processes ... (elapsed 0.02 seconds) done.
> 2010-06-20_22:49:10.28748 kern.warn: Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.
> 2010-06-20_22:49:10.28748 kern.debug: PM: Entering mem sleep
> 2010-06-20_22:49:10.28749 kern.warn: Suspending console(s) (use no_console_suspend to debug)
>
> I also attached the full kernel log since the boot.
Hmm. It looks like a USB problem, then.
Alan, can you have a look at this, please?
Rafael
On Mon, Jun 21, 2010 at 21:24:08 +0200, Rafael J. Wysocki wrote:
> On Monday, June 21, 2010, Tino Keitel wrote:
> > Hi,
> >
> > this nasty bug did not appear after I enabled suspend debugging first,
> > but now it did:
> >
> > 2010-06-20_22:40:31.22927 kern.info: usbcore: deregistering interface driver dvb_usb_vp7045
> > 2010-06-20_22:40:31.24960 kern.debug: usb 1-6: __pm_runtime_resume()!
> > 2010-06-20_22:40:31.24968 kern.debug: usb 1-6: __pm_runtime_resume() returns 1!
> > 2010-06-20_22:40:31.24969 kern.debug: PM: Removing info for No Bus:dvb0.frontend0
> > 2010-06-20_22:40:31.24971 kern.debug: PM: Removing info for No Bus:dvb0.net0
> > 2010-06-20_22:40:31.24972 kern.debug: PM: Removing info for No Bus:dvb0.demux0
> > 2010-06-20_22:40:31.24973 kern.debug: PM: Removing info for No Bus:dvb0.dvr0
> > 2010-06-20_22:40:31.24974 kern.info: dvb-usb: Twinhan USB2.0 DVB-T receiver (TwinhanDTV Alpha/MagicBox II) successfully deinitialized and disconnected.
> > 2010-06-20_22:40:32.26675 kern.info: PM: Syncing filesystems ... done.
> > 2010-06-20_22:40:32.39011 kern.debug: PM: Preparing system for mem sleep
> >
> > When I killed the suspend script which hung at the echo mem >
> > /sys/power/state line, the computer suspended. After wakeup, the kernel
> > log lines after the line above look like this:
> >
> > 2010-06-20_22:49:10.28745 kern.warn: Freezing user space processes ... (elapsed 0.02 seconds) done.
> > 2010-06-20_22:49:10.28748 kern.warn: Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.
> > 2010-06-20_22:49:10.28748 kern.debug: PM: Entering mem sleep
> > 2010-06-20_22:49:10.28749 kern.warn: Suspending console(s) (use no_console_suspend to debug)
> >
> > I also attached the full kernel log since the boot.
>
> Hmm. It looks like a USB problem, then.
Just FYI: The dvb-usb message is generated when the driver for the
DVB-T USB receiver is unloaded. I unload it because I had issues after
resume if I did not unload it.
Regards,
Tino
Hi,
another observation:
As the the computer suspends if I kill the hanging suspend script, I
tried to see that the suspend script is doing. So I attached strace to
it:
$ strace -f -p 6652
After this, the computer suspended.
Regards,
Tino
On Mon, 21 Jun 2010, Tino Keitel wrote:
> On Mon, Jun 21, 2010 at 21:24:08 +0200, Rafael J. Wysocki wrote:
> > On Monday, June 21, 2010, Tino Keitel wrote:
> > > Hi,
> > >
> > > this nasty bug did not appear after I enabled suspend debugging first,
> > > but now it did:
> > >
> > > 2010-06-20_22:40:31.22927 kern.info: usbcore: deregistering interface driver dvb_usb_vp7045
> > > 2010-06-20_22:40:31.24960 kern.debug: usb 1-6: __pm_runtime_resume()!
> > > 2010-06-20_22:40:31.24968 kern.debug: usb 1-6: __pm_runtime_resume() returns 1!
> > > 2010-06-20_22:40:31.24969 kern.debug: PM: Removing info for No Bus:dvb0.frontend0
> > > 2010-06-20_22:40:31.24971 kern.debug: PM: Removing info for No Bus:dvb0.net0
> > > 2010-06-20_22:40:31.24972 kern.debug: PM: Removing info for No Bus:dvb0.demux0
> > > 2010-06-20_22:40:31.24973 kern.debug: PM: Removing info for No Bus:dvb0.dvr0
> > > 2010-06-20_22:40:31.24974 kern.info: dvb-usb: Twinhan USB2.0 DVB-T receiver (TwinhanDTV Alpha/MagicBox II) successfully deinitialized and disconnected.
> > > 2010-06-20_22:40:32.26675 kern.info: PM: Syncing filesystems ... done.
> > > 2010-06-20_22:40:32.39011 kern.debug: PM: Preparing system for mem sleep
> > >
> > > When I killed the suspend script which hung at the echo mem >
> > > /sys/power/state line, the computer suspended. After wakeup, the kernel
> > > log lines after the line above look like this:
> > >
> > > 2010-06-20_22:49:10.28745 kern.warn: Freezing user space processes ... (elapsed 0.02 seconds) done.
> > > 2010-06-20_22:49:10.28748 kern.warn: Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.
> > > 2010-06-20_22:49:10.28748 kern.debug: PM: Entering mem sleep
> > > 2010-06-20_22:49:10.28749 kern.warn: Suspending console(s) (use no_console_suspend to debug)
> > >
> > > I also attached the full kernel log since the boot.
> >
> > Hmm. It looks like a USB problem, then.
>
> Just FYI: The dvb-usb message is generated when the driver for the
> DVB-T USB receiver is unloaded. I unload it because I had issues after
> resume if I did not unload it.
Why does this look like a USB problem? As far as I can tell, the bug
is that the system delays somewhere during the suspend procedure. But
there's no reason to think the delay is connected with USB.
If you boot with "no_console_suspend" on the boot command line and set
the console loglevel high enough to see all messages, can you tell at
what point the hang occurs? I didn't see any clues when looking at the
timestamps in the full kernel log.
Alan Stern
On Mon, Jun 21, 2010 at 18:31:57 -0400, Alan Stern wrote:
[...]
> Why does this look like a USB problem? As far as I can tell, the bug
> is that the system delays somewhere during the suspend procedure. But
> there's no reason to think the delay is connected with USB.
Breaking news: I just got the same hang when switching from X to the
console, so I gues that this bug has nothing to to with suspend, but
was just triggered by the switch to the console before suspend. I guess
I have to ask the intel-gfx folks.
Regards,
Tino
On Wednesday, June 23, 2010, Tino Keitel wrote:
> On Mon, Jun 21, 2010 at 18:31:57 -0400, Alan Stern wrote:
>
> [...]
>
> > Why does this look like a USB problem? As far as I can tell, the bug
> > is that the system delays somewhere during the suspend procedure. But
> > there's no reason to think the delay is connected with USB.
>
> Breaking news: I just got the same hang when switching from X to the
> console, so I gues that this bug has nothing to to with suspend, but
> was just triggered by the switch to the console before suspend. I guess
> I have to ask the intel-gfx folks.
Or the tty folks.
Rafael