[GUIDE] Dell XPS 13 9333
Thanks for the heads up on the USB drivers nuudles. I haven't had a chance to test your suggestions but I'm currently experimenting with the MEI driver as linux users have nailed down the same symptoms on this laptop to an issue with the MEI kernel module. It's a little trickier to disable the MEI driver in OSX since it's bundled with the AppleIntelFrameBufferAzul kext but I've now patched my way out of this pickle. I just need to do some more testing to confirm it's working on OSX - since I need to wait 3 hours before I can test, it's not progressing very fast...
(if anyone's curious, here's the linux kernel bug tracker entry:
https://bugzilla.kernel.org/show_bug.cgi?id=86241 - many thanks to Vincent for compiling dozens of linux kernels until he isolated the breaking commit).
It works!
Short story: I just pushed the patch mentioned above to github (
https://github.com/vbourachot/Dell-...mmit/72e2dbb81264643a9bdb1a4463b3de42c4a7692b) - confirmed sleep is fixed with 3 successful sleep periods after 3+ hours of uptime each. Will appreciate any feedback if it works or doesn't for you guys.
Long story: So as mentioned above, the same symptoms on this laptop in linux were nailed down to an issue with the Intel MEI module in the kernel. The patch I just pushed to github basically stops the OS X MEI driver as soon as it starts. This is the next best thing to unloading it since the driver is part of the framebuffer kext and we obviously need that one.
When using this patch, this is what you should see in your ioreg:
Code:
$ ioreg | grep MEI
| | +-o IMEI@16 <class IOPCIDevice, id 0x1000001b6, registered, matched, active, busy 0 (40 ms), retain 9>
| | | +-o AppleIntelMEIDriver <class AppleIntelMEIDriver, id 0x1000002cd, !registered, !matched, active, busy 0, retain 4>
Note the NOT registered, NOT matched statuses for the driver, even though it is attached to the MEI device. With the driver in this state, I can sleep and wake regardless of how long the machine has been up prior.
I have not seen any issues with running OSX with MEI disabled in this fashion (QE/CI is running fine). However it is so tightly integrated with the framebuffer (i.e. it is not meant to be a separate module as in linux, and OSX is not meant to be running without it) that there might be issues. Please report if anything is not working with this patch enabled.
For an example of what I mean above, this message will now show up in your syslog on boot:
Dec 6 18:17:44 localhost kernel[0]: DRMStatus: iTunes/Apple Store Content Access Problem. Content playback may be disabled on this computer. You can continue to use the machine, but you should contact an Apple support representative. ErrorCode: 8877652
(geek note: this is triggered by AppleMEClientController::
whineAboutMEDriver() ... someone got that right)
However, I have not had any issue logging in to Apple Store and accessing previous purchases. I do not buy my music on itunes so I do not know if this patch really creates an issue with the DRM engine. I've had no problem listening to itunes radio, but it very well might break some other DRM protected media. In that case, one would have to temporarily remove the patch to re-enable the MEI driver. There might be other stuffs which this patch breaks, but I haven't had any issues so far.
As far as I'm concerned, finally being able to close the lid on the laptop without worrying if it's going to lockup or not greatly outweighs any potential issue with apple software.
Intel open source engineers are looking into the MEI module in linux to try to identify/fix this bug. If they come up with something that can be ported to OSX, I'll update the patch.