-
Notifications
You must be signed in to change notification settings - Fork 158
Description
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.
Activity
osy commentedon Sep 8, 2019
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.
osy commentedon Sep 8, 2019
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.
osy commentedon Sep 9, 2019
Seems like Macs have
HOST_CTRL_PORT_LINK_REG.DIS_LINK_CM
set in the PCH XHCI controller (offset 0x80EC) by default while on the NUC it is a hidden BIOS option that is default disabled. In compliance mode, ports have to be reset before they can be used. This is a potential root cause.EDIT: Testing the feature on another hackintosh with
HOST_CTRL_PORT_LINK_REG.DIS_LINK_CM
not set resulted in a working USB sleep/resume. This is not the root cause.osy commentedon Sep 9, 2019
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).
osy commentedon Sep 13, 2019
torvalds/linux@b8cb91e torvalds/linux@c3c5819 This might be related or more likely it's another false flag.
Udpate 202204 (#8)