Messages in this thread | | | From | Arnd Bergmann <> | Subject | Re: Soft lockup during suspend since ~2.6.36 | Date | Mon, 4 Apr 2011 16:40:15 +0200 |
| |
On Monday 04 April 2011, Thilo-Alexander Ginkel wrote: > On Mon, Apr 4, 2011 at 05:02, Arnd Bergmann <arnd@arndb.de> wrote:
> Unfortunately, the output via a serial console becomes garbled after > "Entering mem sleep", so I went for patching dumpstack_64.c and a > couple of other source files to reduce the verbosity. I hope not to > have stripped any essential information. The result is available in > these pictures: > https://secure.tgbyte.de/dropbox/IeZalo4t-1.jpg > https://secure.tgbyte.de/dropbox/IeZalo4t-2.jpg > > For both traces, the printed error message reads: "BUG: soft lockup - > CPU#3 stuck for 67s! [kblockd:28]" > > (After a bit of Googling I understand that a soft lockup is probably > different from a deadlock - please correct me if that assumption is > wrong)
My interpretation is that some process tries to use kblockd_schedule_work() after the CPU for that workqueue has been disabled. The work queue functions (worker_maybe_bind_and_lock) is waiting for the CPU to become available, which it doesn't do.
You see different outputs every time the softlockup detection finds this because the loop is in different states here. The reason why the spin_unlock shows up here is because that is when the interrupts get enabled and the softlockup detection notices the timeout.
I'm pretty sure that this has nothing to do with the bisected bug that you initially found, but maybe somebody else can try analysing this better.
> > Yet another idea would be to set /sys/kernel/printk_delay so that the > > oops gets printed slower. > > Hm, that file does not exist on my machine. Does it need a special > compile-time config option to be enabled?
Sorry, I meant /proc/sys/kernel/printk_delay.
Arnd
| |