On Tue, Sep 28, 2010 at 12:01:42AM -0400, Ted Ts'o wrote: > Why are they strange? Because this was running under KVM, and there > were no underlying hardware problems in the host OS. > > The other two times I got a hard hang at XFStests 219 and 83, and the > system was caught in such a type look that magic-sysrq wasn't working > correctly. > > I've XFStests in this setup before applying these patches, and things > worked fine. I'm currently rolling back the patches and trying > another xfstests runs just to make sure the problem wasn't introduced > by some patch, but for now, it looks there might be a problem > somewhere. And unfortunately, since it's not happening in a regular > location or test, and the system is so badly locked up sysrq doesn't > work, finding it may be intersting.... I've just tried bisecting the patches, and tried applying the first three (well, two since I combined patches #2 and #3). Simply enabling the init_itables code wasn't enough to trigger the problem. It looks like the problem is in the last three patches (probably in one of the patches where we convert ext4 to use sb_issue_zeroout, either the extent or the resize code). What I'll probably do (unless we find the problem very quickly) is to reorder things so that we take the init_itable patch and the sysfs feature patch, and put the rest into the unstable portion of the patch queue. That way I can work on the rest of the ext4 patches for the merge window, without getting blocked on this patch series. And if we don't manage to figure out what went wrong, while it would be nice to simplify the code for 2.6.36, it won't be the end of the world if they need to wait until the next cycle. - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
