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

[Andreas Tobler]

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?

> 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 :(

I'll check-out a src tree on this machine tomorrow and do test build/run.

Thx for the feedback!
Andreas