Remove all dead printfs from this file.

Remove some more stuff from midi.c

Committed: https://github.com/freebsd/virtual_oss/commit/a0860ca4972c473578c8025d8d0cf400aafaa724

Committed: https://github.com/freebsd/virtual_oss/commit/fcf3d0e7d1e3b351975f444606ba30d1e5106fbf

Committed: https://github.com/freebsd/virtual_oss/commit/7b833e492e6ab1f112c0f5a88a3c767abc391485

Remove cuse_uninit() call.

Remove atomic_destroy().

Let's not complicate things more since to be complete we also need to clean up every error case as well.

Address Mark's comments.

Define voss_exit as sig_atomic_t.

In D50393#1153261, @tijl wrote:

In D50393#1152501, @christos wrote:

I haven't tested this for a few days, but I remember that even without the Makefile change, things worked as expected. Is this not the case?

There are 2 different panics:

1. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=286385#c12
2. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=286385#c26

The first is fixed without the Makefile change. It happens when an interrupt occurs after the child hdacc device has been deleted by the bus_generic_detach call in hdac_detach.

The second happens when an interrupt occurs earlier, during hdaa_pcm_detach. The detach thread holds the channel lock and destroys it in chn_kill while the interrupt thread tries to acquire that lock in chn_intr. I can't reproduce this panic but afaict the Makefile change is needed so hdac_detach is called before hdaa_pcm_detach so the draining happens first.

Full diff.

Full diff.

Full diff.

Full diff.

In D50492#1153167, @markj wrote:

It's quite hard to review this without context lines. Did you import virtual_oss into src, or?

Unlock after callout_stop() in the loop.

In D50386#1153172, @markj wrote:

In D50386#1152459, @adrian wrote:

In D50386#1152342, @christos wrote:

The bug D50488 solves could be a reason why the callout was being rescheduled.

It could be, but I still think it's worth being more defensive in making sure we clean things up / stop things right.

Again, the change in the patch introduces a new bug: if callout_stop() returns 0, then the callout thread is blocked on the softc lock, which means that it's waiting for the callout_stop() caller to release the lock, which means that the loop while (callout_stop(&sc->callout) == 0) ; never terminates.

I haven't tested this for a few days, but I remember that even without the Makefile change, things worked as expected. Is this not the case?

In D38825#1144242, @christos wrote:

In D38825#1136408, @markj wrote:

I will spend some time testing this again within a week. My recollection from last time is that there were some edge cases where probes didn't fire when I expected. One thing I didn't test yet but am a bit suspicious will not work properly is stack unwinding -- did you test that the stack() action prints reasonable output when used within an inline function probe?

I will test it in the following days.

In D50386#1152459, @adrian wrote:

In D50386#1152342, @christos wrote:

The bug D50488 solves could be a reason why the callout was being rescheduled.

It could be, but I still think it's worth being more defensive in making sure we clean things up / stop things right.

Address Adrian's comment.

Rename signal handler to virtual_sig_exit().

The bug D50488 solves could be a reason why the callout was being rescheduled.

• Run redirection code only if we are already using the current codec, otherwise we'll be switching automatically to the headphones even when using a different device (e.g., USB).
• Rename "HDA" devd system to "SND" to make it more general.
• Rename "REDIR" devd subsystem to "CONN", according to mav@'s suggestion.

I don't quite follow: hdacc_detach() and hdaa_detach() both call bus_generic_detach().

Reflect D50398 changes.

Address Mark's comments.

LGTM. We'll also need to MFC this to both stable/14 and releng/14.3.
CC @cperciva

In D50378#1150042, @markj wrote:

The only real difference I can see is that this change causes child devices to be detached in reverse order. Does the order matter for some reason?

I didn't know about the Makefile thing. Does the sorting really affect the order in which the detach routines will be called?

I ran the test (i.e., load snd_dummy(4), start virtual_oss, kill it and then unload snd_dummy) in a loop for ~1 hour without crashes. Before the patch it would crash during the first minutes.

I think this can dropped in favor of D50070 and follow-up patches.