On Thursday 14 April 2011, Thilo-Alexander Ginkel wrote: > All right... I verified all my bisect tests and actually found yet > another bug. After correcting that one (and verifying the correctness > of the other tests), git bisect actually came up with a commit, which > makes some more sense: > > | e22bee782b3b00bd4534ae9b1c5fb2e8e6573c5c is the first bad commit > | commit e22bee782b3b00bd4534ae9b1c5fb2e8e6573c5c > | Author: Tejun Heo <tj@xxxxxxxxxx> > | 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? > The good news is that I am able to reproduce the issue within a KVM > virtual machine, so I am able to test for the soft lockup (which > somewhat looks like a race condition during worker / CPU shutdown) in > a mostly automated fashion. Unfortunately, that also means that this > issue is all but hardware specific, i.e., it most probably affects all > SMP systems (with a varying probability depending on the number of > CPUs). > > Adding some further details about my configuration (which I replicated > in the VM): > - lvm running on top of > - dmcrypt (luks) running on top of > - md raid1 > > 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. Arnd -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel