I had the incorrect clock value for Zybo. It uses a 200 Mhz reference clock just like the Zedboard. So put default reference clock value and spi clock value into zynq-7000.dtsi

Other than printing a warning here to help debugging should the alloc fail, I think this is good.

Review feedback. Pull another function out, zone_free_bucket().

Review feedback. Cosmetic code adjustments.

• New snapshot

In D22198#485757, @markj wrote:

Do you happen to have a test case for this? We don't have any ND6 regression tests at the moment. :(

In D22546#493318, @markj wrote:

In D22546#493292, @kib wrote:

Also, I believe it is consistent with behavior of other sleeping syscalls like select(2), where the situation causes spurious EINTR.

I agree it is more consistent than before, but from my reading:

• it does not result in EINTR for a mere ptrace attach, and

For PT_ATTACH it is not needed, I believe. There a SIGSTOP is generated and we would do all the magic inside ptracestop().

Fixed!

In D22521#493290, @theron.tarigo_gmail.com wrote:

I let it get lost in switch from 390.x to 440.x patches.
I thought that getting the updated nvidia-headless-driver port to work with the 3xx versions would be more involved because of changed structure, but I just tried it and it works. Thanks!

Fix nvidia-driver pkg-plist. Create nvidia-headless-driver-390 (supports oldest generation of Nvidia GPUs used in hybrid graphics configuration).

Switch to FAT16 and reduce FAT parition size

Switch to using GPT everywhere instead of using BSD slices

With this patch and respective call (https://people.freebsd.org/~mav/ntb_hw_intel_dmar.patch) Intel NTB on Xeon v4 happily works with DMAR enabled. Thanks!

Sysctl will allow us to make changes at runtime. For example limits. It is quicker to modify and doesn't create ABI issues. I view this as more of a debugging tool and vmstat as more for system administrators.

In D22546#493292, @kib wrote:

Also, I believe it is consistent with behavior of other sleeping syscalls like select(2), where the situation causes spurious EINTR.

In D22546#493292, @kib wrote:

In D22546#493291, @markj wrote:

I think it's because kern_sigsuspend() and kern_sigtimedwait() call cursig() and thus may block in ptracestop() before returning to the usermode boundary.

So to be clear, the problem is that a debugger is expecting to see a system call entry following a PT_CONTINUE following the attach?

This is not quite a problem, but rather the inconvenience. In this situation debugger needs to understand that the process is waiting for a signal in a syscall that does not return until the signal is generated, and do something. It is quite involved for the debugger to infer this data, and much simpler for the kernel to fabricate a spurious EINTR instead.

Also, I believe it is consistent with behavior of other sleeping syscalls like select(2), where the situation causes spurious EINTR.

Not tested. There will be a trivial conflict in bus_dma.h, I will resolve it later.

Only inject EINTR in sigtimedwait() when error == 0.

Replace the macros with __always_inline functions, which preserves, and perhaps slightly enhances the performance benefit.

In D22546#493291, @markj wrote:

I think it's because kern_sigsuspend() and kern_sigtimedwait() call cursig() and thus may block in ptracestop() before returning to the usermode boundary.

So to be clear, the problem is that a debugger is expecting to see a system call entry following a PT_CONTINUE following the attach?

In D22546#493275, @kevans wrote:

In D22546#493273, @markj wrote:

In D22546#493033, @kevans wrote:

I think this looks good to me, thanks! It does behave differently now in that truss(1) will cause us to exit these syscalls if it attaches in the middle -- but every application I can think of using them will swiftly return to sigsuspend() state once it realizes nothing productive happened.

Sorry, I am confused. truss(1) attach should generate a SIGSTOP that interrupts the system call anyway.

The SIGSTOP interrupts, then zsh returns to sigsuspend(2) following that. The application then goes to trace syscall entry and we're stuck in sigsuspend(2) at that point.

Why do we interrupt only these two distinguished system calls?

There are perhaps others, but sigsuspend was the first candidate because it's the most problematic one and sigwait/sigtimedwait are a natural extension to this.

In D22521#493197, @monwarez_mailoo.org wrote:

For the pkg-plist of x11/nvidia-driver, there should be this:

So that nvidia-driver-headless could build (package phase) with legacy driver : 390, 340, 304 .

You're absolutely right. I let it get lost in switch from 390.x to 440.x patches.

Use %%EXTENSIONSDIR%%/libglx.so in nvidia-driver/pkg-plist

Move common macros to rk_cru.h

Do you get similar results by using C functions with the __always_inline attribute instead of macros?

In D22546#493273, @markj wrote:

In D22546#493033, @kevans wrote:

I think this looks good to me, thanks! It does behave differently now in that truss(1) will cause us to exit these syscalls if it attaches in the middle -- but every application I can think of using them will swiftly return to sigsuspend() state once it realizes nothing productive happened.

Sorry, I am confused. truss(1) attach should generate a SIGSTOP that interrupts the system call anyway.

In D22546#493033, @kevans wrote:

I think this looks good to me, thanks! It does behave differently now in that truss(1) will cause us to exit these syscalls if it attaches in the middle -- but every application I can think of using them will swiftly return to sigsuspend() state once it realizes nothing productive happened.

Updated with comments, added a compiler check to make it "commitable" before flagday and retested

Remarks from ae

In D22527#492862, @rlibby wrote:

In D22527#492846, @markj wrote:

As far as I know the only reason to disallow sleeping readers is that rmlock trackers typically live on the stack, and the stacks of sleeping threads may be swapped out. That seems like a fairly dubious reason in this day and age - do you know of any other reasons?

As in, is it accidental or fundamental that sleepable rm locks are not sleepable in read mode? I don't know.

I'm not sure if stack swapping is the only potential problem. I see the implementation referencing turnstiles... I think that implies a deeper interaction with non-sleepability. To be honest I don't know either turnstiles or the rm lock implementation that well.

LGTM, I've been running this for a while and it seems to work well.

Does this essentially obsoletes vm.zone_stats ? Wouldn't it be better to extend that interface and vmstat -z ?