ksoftirqd/0 hogs one core after resume from suspend
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
linux (Ubuntu) |
Won't Fix
|
Medium
|
Unassigned |
Bug Description
After resuming from suspension or hibernation, ksoftirqd/0 gets 100% CPU usage and stays there, using up a whole CPU core.
An unrelated kernel oops was generated at the time I submitted this report. I'm leaving the details here, in case they might be useful.
The default summary was: 'WARNING: at /build/
ProblemType: KernelOops
Annotation: Your system might become unstable now and might need to be restarted.
Architecture: i386
ArecordDevices:
**** List of CAPTURE Hardware Devices ****
card 0: Intel [HDA Intel], device 0: CONEXANT Analog [CONEXANT Analog]
Subdevices: 1/1
Subdevice #0: subdevice #0
AudioDevicesInUse:
USER PID ACCESS COMMAND
/dev/snd/
/dev/snd/pcmC0D0p: jms 2158 F...m pulseaudio
/dev/snd/seq: timidity 1960 F.... timidity
CRDA: Error: [Errno 2] Ficheiro ou directoria inexistente
Card0.Amixer.info:
Card hw:0 'Intel'/'HDA Intel at 0xf4500000 irq 22'
Mixer name : 'Conexant CX20549 (Venice)'
Components : 'HDA:14f15045,
Controls : 18
Simple ctrls : 8
Date: Sat Oct 31 17:55:11 2009
DistroRelease: Ubuntu 9.10
Failure: oops
HibernationDevice: RESUME=
MachineType: Packard Bell BV EasyNote MB65
NonfreeKernelMo
Package: linux-image-
ProcCmdLine: root=UUID=
ProcVersionSign
RelatedPackageV
linux-
linux-firmware 1.24
RfKill:
0: phy0: Wireless LAN
Soft blocked: no
Hard blocked: no
SourcePackage: linux
Tags: kernel-oops
Title: WARNING: at /build/
Uname: Linux 2.6.31-14-generic i686
WpaSupplicantLog:
dmi.bios.date: 04/25/2007
dmi.bios.vendor: Phoenix Technologies LTD
dmi.bios.version: PB23A01
dmi.board.name: PB2
dmi.board.vendor: Packard Bell BV
dmi.board.version: Not Applicable
dmi.chassis.
dmi.chassis.type: 1
dmi.chassis.vendor: Packard Bell BV
dmi.chassis.
dmi.modalias: dmi:bvnPhoenixT
dmi.product.name: EasyNote MB65
dmi.product.
dmi.sys.vendor: Packard Bell BV
Changed in linux (Ubuntu): | |
importance: | Undecided → Medium |
status: | New → Triaged |
Hi kunami,
The warning reported here typically indicates that it took longer for your system to resume from suspend than expected. I believe there is a 5 sec barrier which your system likely exceeded. Based on your dmesg output I see PM: resume devices took 8.636 seconds. A patch to prevent this warning has been applied via bug 464552. As a result I'm marking this as a duplicate to bug 464552. Please continue to track this issue at that report. Thanks!
[This is an automated message. Apologies if it has reached you inappropriately.]