> > Are your kernel and userland in sync?  (i.e. are you using GENERIC from
> > the same snapshot as userland?)
>
> Yes, it was (I'm referring to my original post on the subject here) very
> much in sync: it just didn't work. In my mail, you can find some ktraces,
> etc. debugging info related to the problem. If you've lost'em, tell me, and
> I'll repost. I'll try with 1.6A when I have time, and see if it happens
> again.
>
> Tomi

Well, did some retesting with a friend of mine on 1.6_BETA1, and the problem 
is still there. We did testing, and it appears that /dev/ipl does not return 
the correct value to FIONREAD:

 15294 ipmon    CALL  write(0x6,0x20e000,0x6)
 15294 ipmon    GIO   fd 6 wrote 6 bytes
       "15294
       "
 15294 ipmon    RET   write 6
 15294 ipmon    CALL  close(0x6)
 15294 ipmon    RET   close 0
 15294 ipmon    CALL  close(0x6)
 15294 ipmon    RET   close -1 errno 9 Bad file descriptor
 15294 ipmon    CALL  __sigaction14(0x1,0xffffffffffffb6b0,0xffffffffffffb690)

This is another bug, unrelated to logging: the pid file opened for reading is 
closed twice, hence the "Bad file descriptor".

And here it goes wrong:

 15294 ipmon    CALL  __sigaction14(0x1,0xffffffffffffb6b0,0xffffffffffffb690)
 15294 ipmon    RET   __sigaction14 0
 15294 ipmon    CALL  ioctl(0x3,FIONREAD,0xffffffffffffb79c)
 15294 ipmon    RET   ioctl 0
 15294 ipmon    CALL  ioctl(0x4,FIONREAD,0xffffffffffffb79c)
 15294 ipmon    RET   ioctl 0
 15294 ipmon    CALL  ioctl(0x5,FIONREAD,0xffffffffffffb79c)
 15294 ipmon    RET   ioctl 0
 15294 ipmon    CALL  nanosleep(0xffffffffffffb6c0,0xffffffffffffb6b0)
 15294 ipmon    RET   nanosleep 0

etc. ipmon goes to nanosleep, and tries again every one second. Only problem 
being, that FIONREAD does not return anything but zero even if there is data
to be read in /dev/ipl.

Ideas welcome,


Tomi