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:55:10PM +0200, Andreas Tobler wrote:
> On 27.06.17 22:43, Konstantin Belousov wrote:
> > 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.
> 
> Hm, if you could give me some hands-on? How do I do that?
mount_nfs server:/path /mnt
If this fails with an RPC error, run it under ktrace and then show
me kdump.

Right now I do not undestand where does your error occur.  Are you able
to boot single-user ?

> 
> > Did you rebuilt the world after the update ?  It should work both ways,
> > but knowing the answer trims half of the change for suspect.
> 
> I built world and kernel in a clean env. rm -rf the obj part.
> The whole boot is done via nfs. I do boot the tree via netboot, 
> crossbuilt on amd64. The machine is shot I can not boot from disk atm.
> 
> With the r320421, the picture is the same, as expected.
> 
> > Can you run the ktrace tests on ppc ?
> > 	cd tests/sys/kqueue/libkqueue/
> > 	make
> > 	./kqtest
> 
> This is chicken and egg, my src is on the nfs drive :(
It is enough to checkout the libkqueue directory alone for this test
to build and run.  You can probably squeeze it into your boot nfs mount.