Yesterday I said:
> Sure.  http://www.mcs.vuw.ac.nz/~mark/jdb.out is the ktrace log file for the
> failing case and http://www.mcs.vuw.ac.nz/~mark/jdb1.out is the same system
> but having started artds.

> Things diverge significantly after writing the "> " prompt out.

So I went back and did a ktrace of the 1.5ZA case to see how that differed from 
the failing 1.5ZC case and everything is basically the same in the two traces 
up to a point where in the ZA trace you get:

		[...]
 15677 jdb      CALL  getdents(0x3,0xbfbf937c,0x1eb9)
 15677 jdb      RET   getdents 380/0x17c
 15677 jdb      CALL  stat(0x8058c68,0xbfbfb244)
 15677 jdb      NAMI  "/emul/linux/dev/."
 15677 jdb      NAMI  "/emul/linux"
 15677 jdb      NAMI  "/emul/linux/dev/."
 15677 jdb      RET   stat 0
 15677 jdb      CALL  stat(0x8058c68,0xbfbfb244)
 15677 jdb      NAMI  "/emul/linux/dev/.."
 15677 jdb      NAMI  "/emul/linux"
 15677 jdb      NAMI  "/dev/.."
 15677 jdb      RET   stat 0
 15677 jdb      CALL  stat(0x8058c68,0xbfbfb244)
 15677 jdb      NAMI  "/emul/linux/dev/dsp"
 15677 jdb      NAMI  "/emul/linux"
 15677 jdb      NAMI  "/emul/linux/dev/dsp"
 15677 jdb      RET   stat 0
 15677 jdb      CALL  stat(0x8058c68,0xbfbfb244)
 15677 jdb      NAMI  "/emul/linux/dev/null"
 15677 jdb      NAMI  "/emul/linux"
 15677 jdb      NAMI  "/emul/linux/dev/null"
 15677 jdb      RET   stat 0
 15677 jdb      CALL  stat(0x8058c68,0xbfbfb244)
 15677 jdb      NAMI  "/emul/linux/dev/cdrom"
 15677 jdb      NAMI  "/emul/linux"
 15677 jdb      NAMI  "/emul/linux/dev/cdrom"
 15677 jdb      RET   stat 0
 15677 jdb      CALL  stat(0x8058c68,0xbfbfb244)
 15677 jdb      NAMI  "/emul/linux/dev/fd0"
 15677 jdb      NAMI  "/emul/linux"
 15677 jdb      NAMI  "/emul/linux/dev/fd0"
 15677 jdb      RET   stat 0
 15677 jdb      CALL  stat(0x8058c68,0xbfbfb244)
 15677 jdb      NAMI  "/emul/linux/dev/hda"
 15677 jdb      NAMI  "/emul/linux"
 15677 jdb      NAMI  "/emul/linux/dev/hda"
 15677 jdb      RET   stat 0
 15677 jdb      CALL  stat(0x8058c68,0xbfbfb244)
 15677 jdb      NAMI  "/emul/linux/dev/hdb"
 15677 jdb      NAMI  "/emul/linux"
 15677 jdb      NAMI  "/emul/linux/dev/hdb"
 15677 jdb      RET   stat 0
		[...]

and in the ZC trace you get:

		[...]
   387 jdb      CALL  getdents(0x3,0xbfbf95bc,0x1eb9)
   387 jdb      RET   getdents 380/0x17c
   387 jdb      CALL  stat(0x8064478,0xbfbfb484)
   387 jdb      NAMI  "/emul/linux/dev/."
   387 jdb      NAMI  "/emul/linux"
   387 jdb      NAMI  "/emul/linux/dev/."
   387 jdb      RET   stat 0
   387 jdb      CALL  stat(0x8064478,0xbfbfb484)
   387 jdb      NAMI  "/emul/linux/dev/.."
   387 jdb      NAMI  "/emul/linux"
   387 jdb      NAMI  "/dev/.."
   387 jdb      RET   stat 0
   387 jdb      CALL  stat(0x8064478,0xbfbfb484)
   387 jdb      NAMI  "/emul/linux/dev/dsp"
   387 jdb      NAMI  "/emul/linux"
   387 jdb      NAMI  "/emul/linux/dev/dsp"
   387 jdb      RET   stat 0
   387 jdb      CALL  close(0x3)
   387 jdb      RET   close 0
   387 jdb      CALL  open(0x8064478,0,0)
   387 jdb      NAMI  "/emul/linux/dev/dsp"
   387 jdb      NAMI  "/emul/linux"
   387 jdb      NAMI  "/emul/linux/dev/dsp"
   387 jdb      RET   open 3
   387 jdb      CALL  fcntl(0,0x3,0)
   387 jdb      RET   fcntl 2
   387 jdb      CALL  fcntl(0x3,0x4,0x2)
   387 jdb      RET   fcntl 0
   387 jdb      CALL  dup2(0x3,0)
   387 jdb      RET   dup2 0
   387 jdb      CALL  close(0x3)
   387 jdb      RET   close 0
   387 jdb      CALL  old_mmap(0xbfbfb3f8)
   387 jdb      RET   old_mmap 1210241024/0x4822d000
   387 jdb      CALL  mprotect(0x4822d000,0x1000,0)
   387 jdb      RET   mprotect 0
   387 jdb      CALL  rt_sigprocmask(0x2,0,0x80605e4,0x8)
   387 jdb      RET   rt_sigprocmask 0
		[...]

Note the dup2().  Given that then its not surprising that later on things crap out 
when accessing standard in.

So I haven't yet tried updating the suse libraries to see if this goes away 
but it is odd.  What is causing it to go down a clearly different code path. 
Something stat() is returning that it didn't previously?
Setting emul.linux.kern.osrelease back to 2.0.38 via sysctl doesn't stop it 
failing so its nothing in the suse libraries that is conditional on kernel 
version.

cheers
mark