[sorry for the late reply -- was AFK for the weekend]

jaharkes_at_cs.cmu.edu said:
> Hmm, is bonnie using SIGALRM by any chance? 

Appearently not. I also can't reproduce this one anymore after
setting up everything from scratch a couple of times...
I still see lots of the 2-second timeouts, but not the crashing.

[lookup problems]

> Are you by any chance crossing volume boundaries in the problematic
> cases

No, definitely not -- I only have 1 volume.

There are however 2 serious deviations from standard (BSD) behaviour
in the dirent/readdir code.
(I've extended the ktrace kernel code in NetBSD for this - maybe
I'll get this into the main tree sooner or later.)
Some ktrace output:
 14207 make     CALL  open(0x807b909,0x4,0)
 14207 make     NAMI  "../../../../../../lib/libkern"
 14207 make     RET   open 4
[...]
 14207 make     CALL  getdents(0x4,0x807d000,0x1000)
 14207 make     GIO   fd 4 read 2048 bytes
        000   49 78 89 53 18 00 00 0d  73 74 72 6e 63 61 73 65 Ix.S....strncase
        010   63 6d 70 2e 63 00 00 00  39 ff bf 53 14 00 00 08 cmp.c...9..S....
        020   63 6d 70 64 69 32 2e 63  00 00 00 00 1a f0 8b 53 cmpdi2.c.......S
[...]

What's wrong is that the d_type fields are zero -- this seems harmless for 
"make"
but might induce strange behaviour elsewhere. And that the first 2 entries are
not "." and "..". That's fatal for BSD "make" because it blindly skips the 
first
2 readdir() results. (This behaviour gets also visible if one does an "ls 
-af".)

While we are here: the venus_readdir() function is unused in the NetBSD
kernel code. Does this upcall (still) exist? Can it be removed?
What is/was the purpose of the CTL_FILE?

best regards
Matthias