WindowServer random crashes about nucintosh

[zearp]

No I don’t have similar problems and I’m using several NUCs. Please share steps on how I can reproduce this.

[zearp]

I just remembered this can happen but very rarely under very heavy specific loads. Can you try setting enable-hdmi20 to 00000000 in the config? It might sort it all out and unless you use 4k you don't need that setting enabled.

I had totally forgotten about this cuz the only way to trigger a crash was to run a specific type of stress test, nothing else would trigger it when using the machine. But it seems you're running into it in the wild. Which makes me wonder what you're doing when it crashes. You say random but that would mean it also happens if you leave it idle.

Does it happen when idle?
Does it happen on a clean install with nothing installed, eg; just macOS + EFI?

Steps to reproduce would be best, but if it's really random then it might be hard for me to help cuz I don't experience it myself.

[zearp]

If you do need or have 4k you can change enable-hdmi20 with enable-max-pixel-clock-override and set it to 01000000 to enable it again.

[Rogerthat12]

I don't know how to reproduce this, but I think that's might be a temperature overload limit or something, because today was a very hot weather outside and my nuc was spinning faster than usual. What I read it is possible to be a gpu kext but maybe it was only temperature. Now I don't have any problem for an hour or two. I will try to analyze this if this will happen in future. I noticed that Avid Link crashed also. Maybe It's that.

PS. I don't have 4K monitor only Full HD.

[zearp]

I'm pretty sure it's not overheating, if it overheats it will throttle the speed to cool itself down and if that can't be done fast enough it will shut the machine down.

The crash you experience I looked into a while ago, I forgot about it. I'm pretty sure that once you remove or disable the enable-hdmi20 property it won't happen again. It's a known issue and it won't be fixed due to enable-hdmi20 being replaced with enable-max-pixel-clock-override in WhateverGreen.

I didn't make any changes to the config yet because nobody had run into this crash till now and it may break 4k if removed and using the hdmi instead of usb-c/thunderbolt as video output. I also don't have a 4k screen at the moment so no way to test so I left things how there were.

What I will do is add both properties in the config and disable enable-hdmi20 by default leaving the other one enabled. If nobody opens an issue saying this broke their 4k we can assume it works haha. I do hope to get a 4k screen at some point in the future.

[zearp]

Made the changes: b844f48

Hopefully it doesn't break 4k for anyone and with this done WindowServer shouldn't crash anymore. Please let me know if you run into it again with the updated config or with enable-hdmi20 remove/disabled.

[Rogerthat12]

Thanks so much!

I'll let you know if It crash.

[Rogerthat12]

Otherwise I had an issue with bluetooth mouse and keyboard battery drain during not using mouse and keyboard( or sleeping?)(I think that's not necesary to create new topic). I solved this issue with this script: https://www.tonymacx86.com/threads/workaround-for-bluetooth-mouse-keyboard-battery-drain.301110/

Maybe it will be a good idea to write this into readme on Nucintosh? Or somehow inform that's possible problem with intel bluetooth.

[zearp]

Hmm, my first reaction would be to blame the device. Devices should enter power saving mode when not used. I haven't use Intel bluetooth much though so maybe it is preventing devices from going into power saving... If it does then it could also happen in Linux. The way bluetooth works on our builds is by loading the Linux firmware Intel has released. It doesn't do anything more than it. macOS can use it for basic functions using this firmware. Any issues with bluetooth are down to macOS.

If you have a Windows install on an other disk or partition you can you try if using the Windows firmware version works any better. You'll have to boot into Windows and then boot back into macOS without power cycling. You'll also need to disable the 2 Intel bluetooth kexts. What this does is leave the Windows firmware in there.

This is of course only useful to check if the issue is with the firmware or not. Maybe there are issues with it. I really can't tell and I don't use enough bluetooth stuff to test battery drain. The few bluetooth mice I use have up to a year battery life so it will be hard to see if that drains faster or slower. I also don't have any bluetooth keyboards that report the battery percentage. What keyboard and mouse do you use?

I don't think forcefully disconnecting devices using scripts is a fix and something that should be done. Maybe as a temporary band-aid only but ideally the root cause is found and fixed (if possible). The script just disconnects the device, depending on the type of keyboard or mouse this may or may not help as some devices may try to reconnect.

The best I can suggest is to try the Windows firmware and also test if the drain is present in Windows or not and maybe check for bluetooth power state events in macOS logs or even use Apple's Bluetooth Explorer tool to see whats happening. If you're into Linux you can test it in there too. Linux and macOS share the same firmware but don't have the same bluetooth stack. If it's fine in Linux then it's down to macOS.

Normally a bluetooth device should enter sleep status, this should be shown in the logs or with Bluetooth Explorer. It should also if it fails to enter sleep mode and hopefully why. I have a bluetooth keyboard that I know has no issues with battery drain and always enters sleep when no key is pressed in 90 seconds or so.

I will see what happens on a native Apple bluetooth card in the logs and then repeat that on a NUC with Intel bluetooth. It may not lead to anything but who knows. If the keyboard also sleeps fine when using Intel bluetooth then I dunno what else to do short from buying a device thats reported to have this draining issue.

Bluetooth Explorer.zip

[Rogerthat12]

I think that this isn't long term fix, but it seems to reduce battery drain. I use apple Magic Mouse and keyboard 1st gen (without internal battery).There is one error what I've get with Bluetooth explorer (currently I use only Magic Mouse):

Bluetooth Module powered on.
Bluetooth Module powered on.
Bluetooth Module powered on.
Bluetooth Module powered on.
Bluetooth Module powered on.
Bluetooth Module powered on.
2021-05-11 6:30:50 PM +0000 Apple80211Get(APPLE80211_IOC_BTCOEX_MODE) returned error 5

updateChainPower error: 5
2021-05-11 6:30:50 PM +0000 Apple80211Get(APPLE80211_IOC_BTCOEX_MODE) returned error 5

updateChainPower error: 5
2021-05-11 6:30:50 PM +0000 Apple80211Get(APPLE80211_IOC_BTCOEX_MODE) returned error 5

updateChainPower error: 5
2021-05-11 6:30:50 PM +0000 Apple80211Get(APPLE80211_IOC_BTCOEX_MODE) returned error 5

updateChainPower error: 5
2021-05-11 6:30:55 PM +0000 Apple80211Get(APPLE80211_IOC_BTCOEX_MODE) returned error 5

updateChainPower error: 5
2021-05-11 6:30:55 PM +0000 Apple80211Get(APPLE80211_IOC_BTCOEX_MODE) returned error 5

updateChainPower error: 5
2021-05-11 6:30:55 PM +0000 Apple80211Get(APPLE80211_IOC_BTCOEX_MODE) returned error 5

updateChainPower error: 5
(null) (Handle: 0xFFFF) connection failed, status: 0x04

[zearp]

Those errors are not relevant, I'm not sure how useful this tool is cuz its made for Apple's own chipset. The basics do work though like monitoring signals, but maybe this isn't the right tool. I had hoped we could monitor state changes but many things simply crash the tool. Don't think it likes being used on non-Apple chips.

I also have an old school Apple's Bluetooth keyboard with 2 aa batteries, currently connected to a NUC with Apple's own card inside. The Console app is open there showing bluetooth events in real time. I will let it sit idle for a while and see what happens. It should hopefully show some kind of power state messages at some point. I use this stuff way too little to know what kind of battery life to expect from 2 rechargeable aa's. Also depends on the capacity of them of course. I have no baseline to know if its good or bad haha.

I use Apple's own card on my main rig and battery life has been fine for me. I also wouldn't be able to tell there. Both the mouse and keyboard have like 12 months+ of rated battery life and I'm maybe at 6 month max into that and no way to check the current % without measuring voltages on the batteries. I'm not gonna go that far lol.

The short story with Intel bluetooth is that if things work then great, if it doesn't work its really too bad but not much we can really do about it cuz all we do is load a firmware so macOS can use it. The fact Apple supports basic bluetooth out of the box on certain chips is pretty unique already. Can't blame Apple for not providing a firmware for it, thats why we load it. Most bluetooth dongles have the firmware flashed on board so they work without any kexts. Even those 99 cent dongles from eBay work for your basic mouse/keyboard and headset needs. Maybe they also issues with power management, I use some in my Dells but again don't really use bluetooth for HID devices all that much.

[Rogerthat12]

Apple Card in NUC? Maybe I can upgrade it
I had nuc in sleep little longer (but maybe isn't relevant):

May 11 20:31:56 Davids-Mac-mini com.apple.xpc.launchd[1] (com.apple.WebKit.GPU): Unknown key for string: _ProcessType
May 11 20:31:56 Davids-Mac-mini com.apple.xpc.launchd[1] (com.apple.WebKit.WebContent): Unknown key for string: _ProcessType
May 11 20:31:56 Davids-Mac-mini com.apple.xpc.launchd[1] (com.apple.WebKit.WebContent.Development): Unknown key for string: _ProcessType
May 11 20:31:57 Davids-Mac-mini com.apple.xpc.launchd[1] (com.apple.xpc.launchd.domain.pid.WebContent.12475): Path not allowed in target domain: type = pid, path = /Library/Apple/System/Library/StagedFrameworks/Safari/SafariShared.framework/Versions/A/XPCServices/com.apple.Safari.SearchHelper.xpc error = 147: The specified service did not ship in the requestor's bundle, origin = /Library/Apple/System/Library/StagedFrameworks/Safari/WebKit.framework/Versions/A/XPCServices/com.apple.WebKit.WebContent.xpc
May 11 20:31:57 Davids-Mac-mini com.apple.xpc.launchd[1] (com.apple.xpc.launchd.domain.pid.WebContent.12475): Path not allowed in target domain: type = pid, path = /Library/Apple/System/Library/StagedFrameworks/Safari/SafariShared.framework/Versions/A/XPCServices/com.apple.Safari.CredentialExtractionHelper.xpc error = 147: The specified service did not ship in the requestor's bundle, origin = /Library/Apple/System/Library/StagedFrameworks/Safari/WebKit.framework/Versions/A/XPCServices/com.apple.WebKit.WebContent.xpc

May 11 20:33:17 Davids-Mac-mini com.apple.xpc.launchd[1] (com.apple.WebKit.GPU): Unknown key for string: _ProcessType
May 11 20:33:17 Davids-Mac-mini com.apple.xpc.launchd[1] (com.apple.WebKit.WebContent): Unknown key for string: _ProcessType
May 11 20:33:17 Davids-Mac-mini com.apple.xpc.launchd[1] (com.apple.WebKit.WebContent.Development): Unknown key for string: _ProcessType
May 11 20:33:17 Davids-Mac-mini com.apple.xpc.launchd[1] (com.apple.xpc.launchd.domain.pid.WebContent.12692): Path not allowed in target domain: type = pid, path = /Library/Apple/System/Library/StagedFrameworks/Safari/SafariShared.framework/Versions/A/XPCServices/com.apple.Safari.SearchHelper.xpc error = 147: The specified service did not ship in the requestor's bundle, origin = /Library/Apple/System/Library/StagedFrameworks/Safari/WebKit.framework/Versions/A/XPCServices/com.apple.WebKit.WebContent.xpc
May 11 20:33:17 Davids-Mac-mini com.apple.xpc.launchd[1] (com.apple.xpc.launchd.domain.pid.WebContent.12692): Path not allowed in target domain: type = pid, path = /Library/Apple/System/Library/StagedFrameworks/Safari/SafariShared.framework/Versions/A/XPCServices/com.apple.Safari.CredentialExtractionHelper.xpc error = 147: The specified service did not ship in the requestor's bundle, origin = /Library/Apple/System/Library/StagedFrameworks/Safari/WebKit.framework/Versions/A/XPCServices/com.apple.WebKit.WebContent.xpc

May 11 20:34:11 Davids-Mac-mini com.apple.xpc.launchd[1] (com.apple.WebKit.GPU): Unknown key for string: _ProcessType
May 11 20:34:11 Davids-Mac-mini com.apple.xpc.launchd[1] (com.apple.WebKit.WebContent): Unknown key for string: _ProcessType
May 11 20:34:11 Davids-Mac-mini com.apple.xpc.launchd[1] (com.apple.WebKit.WebContent.Development): Unknown key for string: _ProcessType
May 11 20:34:11 Davids-Mac-mini com.apple.xpc.launchd[1] (com.apple.xpc.launchd.domain.pid.WebContent.12815): Path not allowed in target domain: type = pid, path = /Library/Apple/System/Library/StagedFrameworks/Safari/SafariShared.framework/Versions/A/XPCServices/com.apple.Safari.SearchHelper.xpc error = 147: The specified service did not ship in the requestor's bundle, origin = /Library/Apple/System/Library/StagedFrameworks/Safari/WebKit.framework/Versions/A/XPCServices/com.apple.WebKit.WebContent.xpc
May 11 20:34:11 Davids-Mac-mini com.apple.xpc.launchd[1] (com.apple.xpc.launchd.domain.pid.WebContent.12815): Path not allowed in target domain: type = pid, path = /Library/Apple/System/Library/StagedFrameworks/Safari/SafariShared.framework/Versions/A/XPCServices/com.apple.Safari.CredentialExtractionHelper.xpc error = 147: The specified service did not ship in the requestor's bundle, origin = /Library/Apple/System/Library/StagedFrameworks/Safari/WebKit.framework/Versions/A/XPCServices/com.apple.WebKit.WebContent.xpc
May 11 20:34:12 Davids-Mac-mini com.apple.xpc.launchd[1] (com.apple.mdworker.shared.08000000-0300-0000-0000-000000000000[12684]): Service exited due to SIGKILL | sent by mds[119]

2021-05-11 6:44:32 PM +0000 Handle: 0x100 disconnected, reason: 0x16
David Hanslík - myš disconnected
2021-05-11 6:54:37 PM +0000 Role change 0 for handle: 0x0
David Hanslík - myš connected, handle: 0x100

PS. It seems that WindowServer doesn't crash anymore since you have helped me

[zearp]

Yeah, I'm sorry those logs aren't helping us much. If you don't use the NVMe slot you can put a card in there and disable the Intel bt/wifi in the bios. There's a section on the repo about what it involves and what to do. It's also an option to desolder the sdcard reader chip and solder on something there. Or you could "gamble" on a cheap eBay dongle for your keyboard/mouse if thats all you need.

The main benefits with Apple cards is that all iCloud stuff will work flawlessly and you will gain HID-proxy. Which means your paired bluetooth keyboard and mouse will work outside of macOS too. The card will present them to the machine as usb devices. So you can enter the bios using the Apple keyboard if you wish, it will also work in Windows and Linux. They will just see 2 Apple usb devices. The main downside is that if you use the NVMe slot you can't add fast storage anymore. For normal usage I'd say an ssd is fine as long it has dram cache.

Whats best for you depends on your needs and wants. As for the battery drain if I were you I try Linux and Windows and if things are fine in there then at least we know it's related to macOS. If you can also try the Windows firmware on macOS then you can also rule in or out the firmware. If it still happens on macOS with the Windows firmware loaded then for sure it's the macOS bluetooth stack and how it interacts with this chip. If that can be solved is something I really don't know. It all depends on whats causing it.

So far on the NUC with native Apple bluetooth I got tonnes of logs and the keyboard went to sleep shortly before the machine also went to sleep. I will do the same test again on a NUC with Intel bluetooth and see what happens. With your Apple keyboard does it show a disconnected sign on screen after not using it for a while?

Check out this section for all the info on using Apple or 3rd party wifi/bt combo's: https://github.com/zearp/Nucintosh#apple3rd-party-bluetooth-and-wifi

PS. It seems that WindowServer doesn't crash anymore since you have helped me

I'm glad to hear that. It was a confirmed bug and also confirmed it wouldn't be fixed, so I'm glad replacing it with the newer method worked and I've also tested 4k still works, so it's all good! Thanks for reporting and testing it. I've tried to reproduce this back when I looked into it but wasn't able to crash, other could however. Now that the cause has been disabled it shouldn't happen again.

[Rogerthat12]

I don't have much time to testing things in windows or linux, butI will definitely try it if I have more time :)
I am using nvme for ssd, because I wanted smaller version of NUC so I don't have SATA port.
I bought NUC also with TP Link UB400, but It didn't work out of box. Maybe some kexts are needed?

[zearp]

Depending on the chipset inside wifi sticks you'll gonna need a driver pack. I would use the onboard intel wifi as its integrated with macOS whereas with driver packs you need to use a 3rd party utility to connect to networks.

I think if the script works for you and your devices reconnect fast its a good solution. I'm also not going to put too much time in it mainly because no matter what it takes a lot of time to test battery drain.

Even if the cause would be macOS not being able to set/enter sleep events properly, fixing it would involve fixing whatever is "broken" in the macOS bluetooth stack. Well above my pay grade.

At least the WindowServer crashes won't happen anymore. I think Avid may just have presented it with the right amount of memory pressure to cause the crash. It only happened under very specific memory loads.