2011/10/19 Paweł Sikora <pluto@xxxxxxxx>: > > the latest patch (mm/migrate.c) applied on 3.0.4 also survives points > 1) and 2) described previously (https://lkml.org/lkml/2011/10/18/427), > so please apply it to the upstream/stable git tree. Ok, thanks, applied and pushed out. > from the other side, both patches don't help for 3.0.4+vserver host soft-lock > which dies in few hours of stressing. iirc this lock has started with 2.6.38. > is there any major change in memory managment area in 2.6.38 that i can bisect > and test with vserver? I suspect you'd be best off simply just doing a full bisect. Yes, if 2.6.37 is the last known working kernel for you, and 38 breaks, that's a lot of commits (about 10k, to be exact), and it will take an annoying number of reboots and tests, but assuming you don't hit any problems, it should still be "only" about 14 bisection points or so. You could *try* to minimize the bisect by only looking at commits that change mm/, but quite frankly, partial tree bisects tend to not be all that reliable. But if you want to try, you could do basically git bisect start mm/ git bisect good v2.6.37 git bisect bad v2.6.38 and go from there. That will try to do a more specific bisect, and you should have fewer test points, but the end result really is much less reliable. But it might help narrow things down a bit. Linus -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href