Re: HEADS UP: UNIX domain socket locking changes merged to CVS HEAD

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