I sent this to the LSB-si developer list, but not here. Of course any suggestions (including where I can find an LSB-conforming ia64 kernel!) are welcome.
======================================== LSB-si/ia32: Anthony Towns' changes to mprotect also clear the hang I was seeing, leaving: 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 config file value (which I may not actually know yet). 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 and pick up a bad value from the system headers; but the algorithm, if it got the right value, would require constructing an array of 1024 iovectors with size 9,007,199,254,742,016 bytes each. I actually tried this, and it works for the readv test (no data is transferred), 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. Some PRs are pending; some are an informal status, not filed yet but being researched. The 10 fails: 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 the test detects the unexpected presence of group-write permission on the pty it tests. (620 instead of 600).
