[Oneiric] Freezing of tasks failed after 20.00 seconds

Bug #816797 reported by Ming Lei
36
This bug affects 8 people
Affects Status Importance Assigned to Milestone
linux-ti-omap4 (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

[12822.864685] PM: Syncing filesystems ... done.
[12822.908416] PM: Preparing system for mem sleep
[12822.908630] Freezing user space processes ...
[12842.913848] Freezing of tasks failed after 20.00 seconds (3 tasks refusing to freeze, wq_busy=0
):
[12842.923187] gvfs-gdu-volume D c05b1438 0 977 1 0x00080001
---
AlsaDevices:
 total 0
 crw------- 1 root root 116, 33 2011-07-25 11:20 timer
AlsaVersion: Advanced Linux Sound Architecture Driver Version 1.0.24.
AplayDevices: aplay: device_list:240: no soundcards found...
Architecture: armel
ArecordDevices: arecord: device_list:240: no soundcards found...
DistroRelease: Ubuntu 11.10
Package: linux (not installed)
ProcEnviron:
 PATH=(custom, user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcKernelCmdLine: ro elevator=noop vram=32M mem=456M@0x80000000 mem=512M@0xA0000000 root=UUID=a957f519-7a09-48d9-a60d-b15883901edf fixrtc quiet splash console=ttyO2,115200n8 serialtty=ttyO2 earlyprintk
ProcVersionSignature: Ubuntu 3.0.0-1200.2-omap4 3.0.0-rc7
Tags: unity-2d oneiric
Uname: Linux 3.0.0-1200-omap4 armv7l
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm admin cdrom dialout lpadmin plugdev sambashare

Revision history for this message
Ming Lei (tom-leiming) wrote : BootDmesg.txt

apport information

tags: added: apport-collected oneiric unity-2d
description: updated
Revision history for this message
Ming Lei (tom-leiming) wrote : CurrentDmesg.txt

apport information

Revision history for this message
Ming Lei (tom-leiming) wrote : Lsusb.txt

apport information

Revision history for this message
Ming Lei (tom-leiming) wrote : ProcCpuinfo.txt

apport information

Revision history for this message
Ming Lei (tom-leiming) wrote : ProcInterrupts.txt

apport information

Revision history for this message
Ming Lei (tom-leiming) wrote : ProcModules.txt

apport information

Revision history for this message
Ming Lei (tom-leiming) wrote : UdevDb.txt

apport information

Revision history for this message
Ming Lei (tom-leiming) wrote : UdevLog.txt

apport information

Revision history for this message
Paolo Pisati (p-pisati) wrote :

it seems i can suspend ok with latest kernel:

flag@omap:~$ uname -a
Linux omap 3.0.0-1203-omap4 #8 SMP PREEMPT Sun Aug 28 14:26:24 CEST 2011 armv7l armv7l armv7l GNU/Linux
flag@omap:~$ sudo pm-suspend

on the serial console:

omap login: [ 380.310028] init: anacron main process (654) killed by TERM signal
[ 381.834106] usb 1-1.2.1: unlink qh8-0e01/ea9b6140 start 6 [1/2 us]
[ 382.582183] PM: Syncing filesystems ... done.
[ 382.586547] PM: Preparing system for mem sleep
[ 382.596282] Freezing user space processes ... (elapsed 0.02 seconds) done.
[ 382.631072] Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.
[ 382.655731] PM: Entering mem sleep
[ 382.662078] Suspending console(s) (use no_console_suspend to debug)

but i cannot wake up the board anymore (the nic doesn't support WOL, usb mouse/keyb don't have any effect and using /sys/class/rtc/rtc0/wakealarm doesn't help either).

Changed in linux-ti-omap4 (Ubuntu):
status: New → Confirmed
Revision history for this message
Dennis van Dok (dvandok-gmail) wrote :

I'm getting the same on
Linux camilla 3.0.0-17-generic #30-Ubuntu SMP Thu Mar 8 20:45:39 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

Revision history for this message
DarkTrick (darktrick1337) wrote :

Linux user 5.11.0-26-generic #28-Ubuntu SMP Thu Jul 15 19:27:01 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

I wish for someone to look into this. A system that cannot suspend in 2021 is ... very inconvenient for users.

There are many similar bug reports for specific different hardware. I think the main reason is a software/kernel problem.

Why in the world on earth would the kernel be allowed to be stopped by any user application? There is no reason, why any process could stop the kernel from working. I hear voices like "but the application might be doing something important". Well, then give it a timeout of 3 seconds. Otherwise the user will be impatient and hard-shutdown anyway. And again: No application should have permission to block the doing of the kernel. Especially if the doing is user-generated.

Revision history for this message
DarkTrick (darktrick1337) wrote :
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.