(Illustration by Gaich Muramatsu)
[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 MatthiasReceived on 2003-09-02 07:37:28