svn commit: r320043 - in head: contrib/netbsd-tests/kernel/kqueue lib/libc/include lib/libc/sys sys/compat/freebsd32 sys/kern sys/sys tests/sys/kqueue/libkqueue usr.bin/truss

[Konstantin Belousov]

On Tue, Jun 27, 2017 at 10:21:42PM +0200, Andreas Tobler wrote:
> Hi Kib,
> 
> On 17.06.17 02:57, Konstantin Belousov wrote:
> > Author: kib
> > Date: Sat Jun 17 00:57:26 2017
> > New Revision: 320043
> > URL: https://svnweb.freebsd.org/changeset/base/320043
> > 
> > Log:
> >    Add abstime kqueue(2) timers and expand struct kevent members.
> >    
> >    This change implements NOTE_ABSTIME flag for EVFILT_TIMER, which
> >    specifies that the data field contains absolute time to fire the
> >    event.
> >    
> >    To make this useful, data member of the struct kevent must be extended
> >    to 64bit.  Using the opportunity, I also added ext members.  This
> >    changes struct kevent almost to Apple struct kevent64, except I did
> >    not changed type of ident and udata, the later would cause serious API
> >    incompatibilities.
> >    
> >    The type of ident was kept uintptr_t since EVFILT_AIO returns a
> >    pointer in this field, and e.g. CHERI is sensitive to the type
> >    (discussed with brooks, jhb).
> >    
> >    Unlike Apple kevent64, symbol versioning allows us to claim ABI
> >    compatibility and still name the new syscall kevent(2).  Compat shims
> >    are provided for both host native and compat32.
> >    
> >    Requested by:	bapt
> >    Reviewed by:	bapt, brooks, ngie (previous version)
> >    Sponsored by:	The FreeBSD Foundation
> >    Differential revision:	https://reviews.freebsd.org/D11025
> 
> This, or one of the following commits breaks my nfs mounts on powerpc64. 
> With the following I mean, 320044-46. The last working revision is 320038.
> 
> With this revision I get this error:
> 
> RPCPROG_NFS: RPC: Port mapper failure - RPC: Unable to receive
> 
> Boot is ok beside not having nfs.
> 
> Right now I build the latest trunk to be sure to test against jhibbit's 
> latest commit in this area. But I do not expect a change.
> 
> Any idea where to look for suspects?

Start with ktrace-ing the mount command, assuming the direct invocation of
mount_nfs(8) fails.

Did you rebuilt the world after the update ?  It should work both ways,
but knowing the answer trims half of the change for suspect.

Can you run the ktrace tests on ppc ?
	cd tests/sys/kqueue/libkqueue/
	make
	./kqtest