[Bug]: Computer restarts after 60s when USB is unplugged while sleeping

[ChaseDurand]

Pre-Submission Checklist

• I confirm this is NOT a code signing / certificate error.
• I have attached the log file (required for bug reports).

Describe the Bug

On two occasions, after using the kext successfully, after my computer goes to sleep and i unplug the USB, I will unlock it 60 seconds later it will reboot. Both crash logs mention a 60s timeout from OzzyKext, attached here.

I will try and experiment with the exact order of computer going to sleep, unplugging USB cable, and powering down my DB4 reproduce this.

Device Model

Allen & Heath Xone:DB4

Operating System

macOS 15 (Sequoia)

📎 Attach Debug Log (REQUIRED)

OzzyKext 60s Crash 1.txt

OzzyKext 60s Crash 2.txt

[timkondratev]

I have the same issue.
System: MacOS 15.6, M2 Pro, Xone:4D.

Steps to recreate:

• Plug device in
• Unplug device
• Close Mac lid
• Open Mac lid
• Log in to user
• Wait 60 seconds
• System freezes and restarts

GitHub Copilot revealed the following findings, although the attempts to fix the bug failed:

The most likely root cause is that aborted USB transfers are being immediately re-submitted during teardown. In OzzyKext.cpp:193 and OzzyKext.cpp:220, the driver aborts all pipes on disconnect/stop. Those aborts still complete through KextBus.cpp:14, and the completion handler forwards every completion, including aborted ones, into the engine at KextBus.cpp:65. Then PloytecEngine.cpp:177 unconditionally re-queues PCM out, PCM in, and MIDI in traffic regardless of completion status. That creates a teardown loop: abort -> completion -> resubmit -> interface stays busy -> registry busy timeout. The panic naming OzzyKext plus two IOUSBHostInterface instances matches this exactly.

The stop path is also unsafe because it frees transport objects after a fixed delay instead of proving all callbacks are gone. In OzzyKext.cpp:220, the code aborts, sleeps 100 ms, then releases pipes, closes interfaces, and destroys mEngine and mBus. But the completion path stores a raw KextBus pointer in TransferContext and dereferences it later in KextBus.cpp:14. If a late completion arrives after that 100 ms window, you have a use-after-free path on top of the busy timeout issue.

The current stopping flags do not actually gate I/O. PloytecEngine.cpp:117 only clears shared-memory flags for the HAL, but neither PloytecEngine.cpp:177 nor KextBus.cpp:105 checks a quiescing state before resubmitting or submitting new transfers. So from the transport’s point of view, stop never really begins.

What To Change

The minimal fix is:

Add a quiescing flag owned by OzzyKext or KextBus and set it before the first abort in disconnect handling.
In the completion handler, if status is aborted or quiescing is set, clean up the descriptor/context and return without calling the engine.
In the engine, do not resubmit on any non-success completion, and do not resubmit while stopping.
Replace the fixed 100 ms sleep with actual in-flight transfer tracking so stop waits for outstanding completions to drain before freeing mBus, mEngine, pipes, or interfaces.
That is the defect I would treat as primary. The current stop strategy is not just flawed in timing; it is logically self-defeating because the abort path feeds the same code that starts new I/O.