Thank you!

Looks good to me.

Still looks good to me.

The change looks good to me.
Thank you.

I think that vmxnet3_isc_txd_credits_update can be made similar to, e.g., igb_isc_txd_credits_update with respect to the array index (tx_rs_cidx and vxcr_next respectively).
That is, we can stash vxcr_next into a local variable and then use the local variable for iteration.
At the end, we can update vxcr_next from the local variable.
This won't fix other potential issues with correctness / concurrency (data races), but at least it will ensure that vxcr_next will not have an out-of-bounds value.

@jhb my personal / private interest in sleepable ithreads is "natural" support for interrupt controllers on slow buses.
Originally, it was assumed that an interrupt controller has fast access and they had.
But imagine something like an I/O expander on an I2C bus.
Let's assume that it supports detecting changes on its I/O inputs and also has a dedicated line to an upstream interrupt controller.
We can configure interrupt modes using I2C transactions and we can also query / mask / etc interrupt lines using I2C.
This is a real interrupt controller from all points of view and if we want to avoid polling (for potentially long time) we need to support sleeping / waiting while communicating with such controller.
At least, that's how I see it.

Looks goof to me.
Thank you!

In D47779#1089560, @christos wrote:

I guess the same is true for PCM_RELEASE.

In D47779#1089556, @christos wrote:

Alright. There are other places in the sound driver that cv_waiters is still accessed directly, so I will see how I can fix those as well.

In D47779#1089553, @christos wrote:

Is there a reason (except maybe layering violations) that we do not want to do it this way and it's better to implement an additional counter in the driver?

Also, cv_wmesg is kind of semi-private and it's used only for diagnostics (tracing).
So, I don't think that it's precedent for general access to cv implementation details.

As I noted in the email thread, there is only one consumer outside of condvar implementation.

In D47571#1085010, @Matthew.Nygard.Dodd_gmail.com wrote:

In D47571#1084984, @avg wrote:

If you have added this from a diff, could you please re-do the diff with -U 9999 option?
That's to have a lot more context lines which would be useful when reviewing.

Done.

If you have added this from a diff, could you please re-do the diff with -U 9999 option?
That's to have a lot more context lines which would be useful when reviewing.

Oh, thinking about this triggered some old memories and I've dug up my old musings on this topic.
The code was never really tested and I cannot guarantee that it's correct, but it seemed correct to the younger me and it still seems correct the now me.
https://people.freebsd.org/~avg/wfhandler.v8.h

In D46421#1066706, @avg wrote:

Another general suggestion is that using CK_SLIST from ConcurrencyKit (included into FreeBSD) might help to make the code more compact and expressive.
But I haven't thought through details, so please feel free to ignore this suggestion if CK does not provide something that could be readily used.
The proposed code is completely good too.

Another general suggestion is that using CK_SLIST from ConcurrencyKit (included into FreeBSD) might help to make the code more compact and expressive.
But I haven't thought through details, so please feel free to ignore this suggestion if CK does not provide something that could be readily used.
The proposed code is completely good too.

I am not sure that such a OS/ACPI (firmware) mutex is possible.

My only concern with the current deregistration approach is a hypothetical situation where a handler resides in a loadable module and, thus, can be unloaded after deregistration.
I like the clever simplicity of the current code where list elements are never removed and only the head pointer can ever be modified.
But maybe it would be good for nmi_remove_handler to wait for a completion of the handler if it's running.
E.g., we could add an atomic counter to struct nmi_handler which would be incremented when the handler is started and decremented when the handler is done.
Then, nmi_remove_handler could spin-wait on that counter if it's not zero (after having cleared func field to prevent future calls).

LGTM

I like how using t_dtrace_trapframe both eliminates the search for the frame below the trap frame and the assumption on the position of the trap frame.

I would subtly change the title :-)
Otherwise, looks good to me.

Looks good to me.

Looks good to me.
A bit ashamed that I could not figure that fls(x - 1) does the job if zero is handled as a special case.

All should be done. Thank you for reporting and diagnosing the problem.

Looks like I assumed too much without paying attention to the scratch buffer.
I'll revert the change.

update description

Based on earlier entries for Samsung 8x0 drives in ata_da.c and scsi_da.c it seems that a separate entry per model line was a preference.
But combing multiple entries is also okay.
However, I'd like to do it as a separate commit a bit later, unless you want to do that yourself.

In D43961#1002853, @imp wrote:

These aren't listed in Linux but I'm OK with them here

The controller is

ahci2@pci0:0:17:0:      class=0x010601 rev=0x40 hdr=0x00 vendor=0x1002 device=0x4391 subvendor=0x1043 subdevice=0x84dd
    vendor     = 'Advanced Micro Devices, Inc. [AMD/ATI]'
    device     = 'SB7x0/SB8x0/SB9x0 SATA Controller [AHCI mode]'
    class      = mass storage
    subclass   = SATA

Just want to comment that based on the errors I initially thought that the problem was a bad cable or SATA port, so I tried a few cables and a few ports on the motherboard, all with the same result.
Then I searched the internet and found some reports for the SSD model.
Then I tried attaching the SSD to an LSI SAS 2308 controller and all problem immediately went away.
Then I added the quirk and the problem got fixed for connecting to on-board SATA as well.

I should clarify that I didn't see just silent data corruption, there were read and write errors as well.

I first-hand experienced problems with a device identified as Samsung SSD 870 EVO 250GB SVT02B6Q.
I inferred that 860 is also affected based on the Linux bug report and on a similar problem with 850 as well.