On Tue, Jan 17, 2012 at 10:40:41AM -0500, Greg Troxel wrote:
> I suggest building a kernel that has options DIAGNOSTIC turned on.  That
> enables assertion checking.

I'll try, have to set up kernel rebuilding anyway, to be able
to test the possible patches/fixes.

> Sorry, I meant that the linux binary was in coda, but that the data
> being used by the program (open/read) was not in coda.  I am wondering
> if it's the mmap of shlibs or the implicit sort-of-mmap from exec.

Unfortunately in my actual test case the binaries ar both run from Coda,
dynamically linked to shared libs which reside on Coda and sometimes
reading some files on Coda (like bash reading its script).

Actually ktruss _might_ show what happens as the last operations before
the crash. I'll try when I can.

> What happens if you run NetBSD binaries on Linux, the other way around
> :-) ?

Sigh. Linux is not as capable as the BSDs are :)

> that's plausible.  NetBSD has a lot (3000ish) regression tests in
> -current, many of which beat on filesystems.  Also there is a way to run
> filesystems in userspace, hooked up to the kernel.  I suspect it's only
> a day's work to let coda work that way, which would enable easier
> debugging (and only crash coda, not the machine).

This looks nice.

If you wish to be able to repeat my tests (i.e. use the Linux-abi software
present on Coda), let me know your gpg/pgp public key. Then of course use
a scratch host for running those binaries unless you actually decide to
trust them. I do my best to keep them safe and I know I am not
evil - but no-one else can know this for sure. :)

Regards,
Rune