HEADS UP: UNIX domain socket locking changes merged to CVS HEAD
Robert Watson
rwatson at FreeBSD.org
Sun Mar 4 10:51:24 UTC 2007
On Sun, 4 Mar 2007, Yoshihiro Ota wrote:
>> Could you confirm that if you run the code precisely before the commits in
>> question (i.e., back out to uipc_usrreq.c:1.196 and unpcb.h:1.22) the
>> problem goes away completely? If so, could you try running ktrace on
>> kinput2 and see if it's looping around any particular syscalls and getting
>> an error repeatedly? It could be that an error is now (possibly
>> incorrectly) being returned and that kinput2 is not handling that well.
>
> I changed to uipc_usrreq.c 1.199 to 1.196 and I already had unpcb.h 1.11.
> After rebooting, the problem still remains.
Hmm. That's odd -- you should really have needed to have unpcb.h:1.22 in
order for the kernel to compile with the recent uipc_usrreq.c changes --
perhaps you're referring to the unpcb.h in /usr/include/sys rather than
/usr/src/sys/sys?
> The below is what I got from ktrace/kdump run on uipc_usrreq.c at 1.199. I
> think I started seeing this problem on last Sat. or Sun day.
>
> It seems that when I kill kinput2, canna dies together so that when I see
> like this:
>
> $ sh /usr/local/etc/rc.d/canna.sh stop Cannot connect with cannaserver
> "unix".
>
> % ktrace -f ktrace.out
>
> 1274 kinput2 RET poll 1
> 1274 kinput2 CALL poll(0x88450fb0,0x2,0)
> 1274 kinput2 RET poll 1
> 1274 kinput2 CALL poll(0x88450fb0,0x2,0)
> 1274 kinput2 RET poll 1
>
> %grep poll ktrace.txt | wc
> 621264 2795688 22986795
Returning imediately from poll() with a third argument (timeout) of 0 is
expected. However, it could be that the application is expecting something
that is no longer true, or that we're handling something differently than we
used to. I take it that kinput2 doesn't have this way in -STABLE? Have you
tried using portupgrade (or a related tool) to rebuild everything and make
sure that a library didn't get out of sync?
I may need to ask you to do a binary kernel search for the date where the
problem started occuring in order to get much further -- or it may take
someone familiar with (or becoming familiar with) the kinput and canna
internals to figure out if this is a new kernel bug or a bug in the
application.
Thanks,
Robert N M Watson
Computer Laboratory
University of Cambridge
More information about the freebsd-current
mailing list