Here are my current results. I have not updated to the latest CVS yet. I'm doing bits incrementally due to the extremely long rebuild time for the SI as well as running the full test suite. There's some chance that these results would "regress" when run through the full cycle, but I'll cross that bridge if I come to it.
Remember that an LSB-si running in a chroot must run on top of a conforming kernel, which I have for ia32, and don't have for ia64, although in the latter case I'm building a kernel which applies all fixes I know about. ======================================== LSB-si/ia32: with Anthony Towns' fix to mprotect, the hang is gone. Total failures: 1 T.msync 7 claims that the sequence: mmap 1 page, msync 2 pages at address returned by mmap does not fail when it should. This is one that behaves as the test expects on the same system running natively, and could be either a library change (which I can't spot) or another test-interaction problem like the mprotect test was (I can't spot that, either). ======================================== LSB-si/ia64: 10 unexplained fails, which follow with some analysis. All other problems have either an unofficial fix, or at least an explanation such as needing the right number of address space pages. It's possible that some of these cannot easily be converted into pass, for example, the readv/writev tests attempt to test overflow of an ssize_t but the algorithm would require constructing an array of 1024 iovectors with size 9,007,199,254,742,016 bytes each. This works for the readv test, but the writev test has to allocate space for at least one of those, and strangely enough the malloc didn't work.... (grin) A few of the fixes match accepted TSD (Test Suite Deficiency) rulings, but this is not true for all. dlopen 4, 12 (2 fails total), appears that dlopen (0, RTLD_NOW) does not give access to the binary's own symbols. This might be a linker flag, but adding it didn't seem to help; it might be a problem actually in the libc dlopen code or the dynamic linker, I see there have been lots of changes to this codebase in the glibc cvs. utime 4, 7, 11 (3 fails total), error return is EPERM on several tests where this is not expected. On 4 and 7 there's an EPERM where no error is expected, on 11 the fail is EPERM instead of expected EACCES. read and readv test 13 (2 fails total) - atime not updated when it was expected to. This is *not* the problem of failing to mount the filesystems correctly, as other tests would fail with this error if it were. write and writev 16 (2 fails total), return failure and ENOSPC when not expected. These tests are attempting to check proper return when running out of space, but are expecting to see a partial write return instead of -1/ENOSPC, which should only happen if no bytes can be written. Could potentially be a kernel issue. grantpt 1 (1 fail), this is running with a pseudo filesystem mounted on /dev/pts, and detects the unexpected presence of group-write permission on the pty it tests. The same test passes on LSB-si/ia32, might be something in the underlying kernel.
