This change makes asmc_detach(..) reentrant by setting freed resources
to known invalid values when done, and makes asmc_attach(..) call
asmc_detach(..) instead of attempting to the semi-equivalent way of
cleaning up the driver resources allocated in asmc_detach(..).
Details
Details
I've been using this particular diff for some time now on a variety of Macs without issue, but all paths that have been tested are happy paths.
I should verify the pathological scenarios function as needed as well.
Diff Detail
Diff Detail
- Repository
- rG FreeBSD src repository
- Lint
Lint Skipped - Unit
Tests Skipped - Build Status
Buildable 70846 Build 67729: arc lint + arc unit
Event Timeline
Comment Actions
This works and has been stable in my testing for several weeks.
One issue remains: the sysctl context is not freed on teardown. The proper fix is the approach I implemented in:
https://github.com/freebsd/freebsd-src/commit/63eff205754c87d3f8e092c5f3a57a1ff2e3e2a2
(Note: I rebase often, so the SHA may change.)
I still reproduce a panic when unloading ASMC with an active Thunderbolt connection, so I havent updated D54615 yet. I need to trace the root cause.
That said, this can land as-is, the panic is reproducible with current code as well.
Comment Actions
...
One issue remains: the sysctl context is not freed on teardown. The proper fix is the approach I implemented in:
https://github.com/freebsd/freebsd-src/commit/63eff205754c87d3f8e092c5f3a57a1ff2e3e2a2
(Note: I rebase often, so the SHA may change.)
If I'm reading the code correctly, this should happen automatically as part of device_detach: https://cgit.freebsd.org/src/tree/sys/kern/subr_bus.c#n2728 .
I still reproduce a panic when unloading ASMC with an active Thunderbolt connection, so I havent updated D54615 yet. I need to trace the root cause.
Is the problem in the USB code or the asmc(4) code?