[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110426131132.GG878@htj.dyndns.org>
Date: Tue, 26 Apr 2011 15:11:32 +0200
From: Tejun Heo <tj@...nel.org>
To: Thilo-Alexander Ginkel <thilo@...kel.com>
Cc: Arnd Bergmann <arnd@...db.de>, "Rafael J. Wysocki" <rjw@...k.pl>,
linux-kernel@...r.kernel.org, dm-devel@...hat.com
Subject: Re: Soft lockup during suspend since ~2.6.36 [bisected]
Hello, sorry about the delay. Was on the road and then sick.
On Sun, Apr 17, 2011 at 11:53:42PM +0200, Thilo-Alexander Ginkel wrote:
> >> | e22bee782b3b00bd4534ae9b1c5fb2e8e6573c5c is the first bad commit
> >> | commit e22bee782b3b00bd4534ae9b1c5fb2e8e6573c5c
> >> | Author: Tejun Heo <tj@...nel.org>
> >> | Date: Tue Jun 29 10:07:14 2010 +0200
> >> |
> >> | workqueue: implement concurrency managed dynamic worker pool
> >
> > Is it possible to make it work by reverting this patch in 2.6.38?
>
> Unfortunately, that's not that easy to test as the reverted patch does
> not apply cleanly against 2.6.38 (23 failed hunks) and I am not sure
> whether I want to revert it manually ;-).
Yeap, reverting that one would be a major effort at this point.
Hmmm... assuming all the workqueue usages were correct, the change
shouldn't have introduced such bug. All forward progress guarantees
remain the same in that all workqueues are automatically given a
rescuer thread. That said, there have been some number of bug fixes
and cases where single rescuer guarantee wasn't enough (which was
dangerous before the change too but was less likely to trigger).
> >> If anyone is interested in getting hold of this VM for further tests,
> >> let me know and I'll try to figure out how to get it (2*8 GB, barely
> >> compressible due to dmcrypt) to its recipient.
> >
> > Adding dm-devel to Cc, in case the problem is somewhere in there.
>
> In the meantime I also figured out that 2.6.39-rc3 seems to fix the
> issue (there have been some work queue changes, so this is somewhat
> sensible)
Hmmm... that's a big demotivator. :-)
> and that raid1 seems to be sufficient to trigger the issue.
> Now one could try to figure out what actually fixed it, but if that
> means another bisect series I am not too keen to perform that
> exercise. ;-) If someone else feels inclined to do so, my test
> environment is available for download, though:
> https://secure.tgbyte.de/dropbox/lockup-test.tar.bz2 (~ 700 MB)
>
> Boot using:
> kvm -hda LockupTestRaid-1.qcow2 -hdb LockupTestRaid-2.qcow2 -smp 8
> -m 1024 -curses
>
> To run the test, log in as root / test and run:
> /root/suspend-test
Before I go ahead and try that, do you happen to have softlockup dump?
ie. stack traces of the stuck tasks? I can't find the original
posting.
Thank you.
--
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists