USB ports reset during sleep/wakeup; USB drives ejected #8
Comments
|
Another symptom: with the Apple wifi card installed, WoL on wifi works the first time you sleep. However, it stops working after a darkwake and must be fully woken up and slept again before it works. I think this is because the Wifi card is disconnected on darkwake and isn't properly re-initialized. |
|
Here is a resume log from ubuntu. Notice how the USB wakeup errors and the thunderbolt disconnect errors are seen in ubuntu as well. However, in ubuntu, workarounds exist to make the error handling transparent to the user. |
|
Seems like Macs have EDIT: Testing the feature on another hackintosh with |
|
After reversing the majority of the sleep-resume UEFI path, it's evident that the PM_Enable bit loss/XHCI controller reset is a hardware issue/design issue and cannot be fixed in BIOS. The best we can do is patch OSX's XHCI driver to be aware of this quirk but this is a extremely difficult task because of how the drivers are designed (children of the device cannot be re-associated). |
|
torvalds/linux@b8cb91e torvalds/linux@c3c5819 This might be related or more likely it's another false flag. |
osy
pushed a commit
that referenced
this issue
Jul 12, 2022
* Revert "fix boot stuck on Monterey 12.1+ for brcm wifi card" This reverts commit 240c0f5. * Use boot-arg instead of DSDT to "fix boot stuck on Monterey 12.1+ for brcm wifi card" DSDT will cause unexpected behavior on my test machine * add brcmfx boot-args for Monterey 12.1+ for brcm card * extend the delay time longer * bug fix: fix verbose and debug mode cannot be effective at the same time
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When a device is plugged in and the computer goes to sleep and wakes up, the device gets reset and the port is re-enumerated. If the device is a USB mass storage drive, then the user sees a "unsafe removal" message.
The behaviour is different for the PCH XHCI ports versus the PEG XHCI ports. For PEG, this happens only during the first sleep. Then, everything is normal. However, for PCH ports (and TB3 USB ports) the reset always happens.
The culprit appears to be a hardware or BIOS issue. The PCI PM_Enable bit should be retained across D3 sleeps, however by the time XNU is woken up, the PM_Enable state is lost. This could be a hardware bug or it could be the resume path in the UEFI firmware messing with the USB device. Evidence for the latter is that a USB keyboard that is plugged in has the LED briefly show up during wake, then goes off, and later comes back on again.
In addition to the PM_Enable state lost, it appears that all other state is lost as well, which is why the ports are reset on resume. A proper fix would require a patched BIOS. A workaround would be to silently re-enumerate the device without user notification (Linux does this). The way the IOUSBMassStorage driver works makes this solution difficult to implement because the USB device is a child of the port that is reset.
Marking as won't fix since BIOS patching is beyond the scope of this project.
Workaround: for devices that require preserving state across sleep/resumes, use only the PEG slots (the blue port on the front or the USB-C port on the front). After reset from the first sleep, the device should sleep/wake without issue.
The text was updated successfully, but these errors were encountered: