HEADS UP: UNIX domain socket locking changes merged to CVS HEAD
Yoshihiro Ota
ota at j.email.ne.jp
Mon Mar 5 05:30:28 UTC 2007
On Sun, 4 Mar 2007 10:51:23 +0000 (GMT)
Robert Watson <rwatson at FreeBSD.org> wrote:
>
> 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?
I wasn't sure where these files existed. So, I run "find" under /usr/src/sys. So, I am positive that I got right ones.
By the way, didn't you mean to try "before" the change? Wan't that why you asked me to back off uipc_usrreq.c from 1.199 to 1.196?
> > 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 rebuilt from no ports since I upgrade to 7.0-CURRENT. Actually, once I started seeing this on kinput2, I rebuilt kinput2. Then, it started spining.
I just tried reinstalling both canna and kinput2 after "cvs up -A" but it didn't help.
> 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.
I will try to find the date when this started happening. I only need to test kernel, don't I? Do I need something else?
By the way, if kinput2 is doing wrong, what kind of mis-operation do you expect? Do you have a guess?
Thanks,
Hiro
More information about the freebsd-current
mailing list