Re: LSB 3.1 status for etch
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.
Reply to: