I have more news on the LSB test regressions I reported on earlier. On Sun, 2006-10-15 at 18:22 -0400, Jeff Licquia wrote: > The two tests are: > > /tset/LSB.os/mfiles/msync_P/T.msync_P 7 FAIL
As far as I can tell, the test is correct. The test does an mmap() of three pages from a large read-write file, munmap()'s the middle page, and then tries to msync() the first two pages. This should fail, since the second page has been unmapped, but it succeeds on current etch. It turns out that some tweaks to mm/msync.c, at git commit 707c21c848deeb0200ba3f07e4ba90e6dc419c2f in the 2.6.17 stable tree, are to blame. 2.6.16 and earlier do not exhibit the problem. Nor, it turns out, does the 2.6.18 kernel shipped as an update to Fedora Core 5. After looking at the patches to that kernel, it seems that a patch backported from 2.6.19 fixes the problem. Testing Linus's tree (post-2.6.19rc2) confirms that the regression is gone. The specific commit which touches msync.c (found in Linus's tree) is 204ec841fbea3e5138168edbc3a76d46747cc987. It depends on several of the other patches by Peter Zijlstra that precede it. The whole group is reflected in the patch in Fedora's 2.6.18 kernel called "linux-2.6-mm-tracking-dirty-pages.patch". I have not specifically tested the patches, but as this is the only patch which touches the msync code in Fedora's package, it seems to be the likely culprit. So, it would seem, Debian has a few options: - Apply the Fedora patch to Debian's kernels. - Assume that etch will ship with 2.6.19 or later. - Write a small patch to undo the 2.6.17 change which caused the problem, and apply it to Debian's kernels. I'll follow this up with a bug report, but I thought it best to let everyone know the details. > /tset/LSB.os/procenv/nice/T.nice 9 FAIL I'll leave this one to Steve, who seems to have a good handle on it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]