u-codalist-tccc_at_aetey.se writes:

> On Mon, Jan 16, 2012 at 01:42:17PM -0500, Greg Troxel wrote:
>> Are you running with DIAGNOSTIC?
>
> Just out-of-the-box whatever it is...

I suggest building a kernel that has options DIAGNOSTIC turned on.  That
enables assertion checking.

>>   linux binary in coda being run, not trying to read data from coda
>
> Can not exclude this but I assume that people are running Linux
> binaries on NetBSD (without Coda) successfully. Thus - hardly.

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.

> I actually do both as I my binaries are Linux-ABI and are on Coda.

That's only the second one.  It's both if the files used by the binaries
are in coda.

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

> Wonder if it can be the concurrency (which the scripts do trigger, a shell
> pipeline means several parallel execve()s) combined with the "unexpected"
> (Coda) file system latency which can trigger races. I recall that on
> Linux Coda triggered corner cases in the file system framework with the
> bugs persisting for very long time. Finally somebody managed to observe
> the same problem, as a very rare case, with local file systems too.

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).

> Another apparent suspect is the broken directory reading code
> which can lead to misaligned data and reading quite unexpected things?

True, it could just be that.

>> The big issue with coda and NetBSD now is that getcwd() seems not to
>> work right.
>
> I remember submitting a patch to uClibc long ago as this was a problem
> on Linux too.

Brett has fixed that in current.  When I get some spare time I'll try it
on -5.