Just wondering if the fix for BCM43XX wifi cards that several users tried is still ok as some were reporting initial kernel panics.
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
macOS 10.12 Sierra Unsupported Macs Thread
- Thread starter redheeler
- WikiPost WikiPost
- Start date
- Sort by reaction score
- Status
Just a general question - I'm running Sierra 10.12.1
Hardware is a late 2009 macPro 4.1, flashed to 5.1, I pulled the 2.66 quad-core 2.66 and swapped in 3.33 hexcore processor board, upped it to 24g memory, upgrade to a newer Mac Graphics card (NVIDIA GeForce GTX 285 1024 MB graphics) and an updated Broadcom WiFi card ...
Card Type: AirPort Extreme (0x14E4, 0x111)
Firmware Version: Broadcom BCM43xx 1.0 (7.21.171.47.1a8)
MAC Address: ac:29:3a:9b:96:f9
Locale: RoW
Country Code: US
Supported PHY Modes: 802.11 a/b/g/n/ac
The Big question is - when I coldstart the machine, I am using less that 1/4 of the memory - but over a few days I see more and more memory is in use (not released) and with a few firefox windows open I can have nearly 3/4 of the memory is use.Without Photoshop or any hogs like that.
When I check Activity Monitor, with Firefox quit, it looks like the biggest thing is use is 1.5 gig or so tied up with the kernel.
Any ideas where to look?
Hardware is a late 2009 macPro 4.1, flashed to 5.1, I pulled the 2.66 quad-core 2.66 and swapped in 3.33 hexcore processor board, upped it to 24g memory, upgrade to a newer Mac Graphics card (NVIDIA GeForce GTX 285 1024 MB graphics) and an updated Broadcom WiFi card ...
Card Type: AirPort Extreme (0x14E4, 0x111)
Firmware Version: Broadcom BCM43xx 1.0 (7.21.171.47.1a8)
MAC Address: ac:29:3a:9b:96:f9
Locale: RoW
Country Code: US
Supported PHY Modes: 802.11 a/b/g/n/ac
The Big question is - when I coldstart the machine, I am using less that 1/4 of the memory - but over a few days I see more and more memory is in use (not released) and with a few firefox windows open I can have nearly 3/4 of the memory is use.Without Photoshop or any hogs like that.
When I check Activity Monitor, with Firefox quit, it looks like the biggest thing is use is 1.5 gig or so tied up with the kernel.
Any ideas where to look?
Out of curiosity, does the com.DD1.SIPLD.plist launch agent disable SIP if needed? Not sure what benefit checking csrutil status would be if SIP went active and disabled legacy USB support.
I can't disable SIP from within the OS; that must be done after booting the Recovery Partition. The LaunchAgent is designed to pop up an alert message on boot when SIP is enabled, and warn the user that USB may stop working. (USB will continue working until a kextcache rebuild is triggered, which usually doesn't happen until awhile later. However, I am working on an automated solution to automatically boot Recovery HD, disable SIP, and reboot itself back into the OS, completely seamlessly without any user interaction.
[doublepost=1480818842][/doublepost]
That's perfectly normal... That's just how Mavericks and newer manage memory.
Last edited:
Thanks for the info dosdude1. That seems like a lot of work to take on. Depending on implementation, it might freak users out if their machine starts rebooting. Almost seems like it is better to disable SIP during the initial installation and include a notice about what might enable SIP and how to deal with it. Is there no way to simply change the OS to allow for the necessary .kexts instead of all these SIP workarounds? Or has macOS rootless locked out that avenue?
Oh, one general request for the post-patch tool. Would it be possible to add tool tips for each patch option? It would help explain what each option does and help users decide what to choose.
[doublepost=1480832013][/doublepost]
As dosdude1 already indicates, macOS memory management doesn't release memory until it has to. You can force the OS to free memory by using terminal and executing "sudo purge". Doing so actually might slow down system because it will have to reload everything it needs back into memory again.
I would disable SIP from within the setup, however that is not possible to do... Apple only allows that to be done from within the Recovery Partition environment. Secondly, the auto-rebooting disabling SIP procedure I had in mind would warn users in the form of a dialog box, explaining exactly what will happen and asking them if they'd like to proceed. The only way to allow the kexts to load on a machine with SIP enabled would be to sign them, which requires the Apple $100/yr developer license along with kext signing permission by Apple.
Yes that was to be expected .. will probably nobody get the beta 4, according to the present state of things.
Supplement:
Update Beta4 has come (23 hours Sunday German-Time) on my Mac mini3,1 late 2009
Why so late? That is probably the question.
Supplement:
Update Beta4 has come (23 hours Sunday German-Time) on my Mac mini3,1 late 2009
Why so late? That is probably the question.
Last edited:
Weird, I disabled SIP while booted with the patched USB installer. I assumed if it could be done then, it could be done with the installer..
If you had a developer account with Apple, all this would be a lot easier. Maybe someone here has a developer license and could help?
Eventually Apple will probably not permit SIP disable, so it might be good devise alternatives. I think you might get some excellent ideas from here about how to gain rootless.install + rootless.install.heritable entitlements during install/upgrade to bypass SIP check entirely. If I understand it correctly, if done this way, we could leave SIP enabled and avoid this complication.
That method isn't new by any means, I've already used it months prior (in a separate discovery) with the Legacy Installer, which used a modified InstallESD image that didn't prompt a need to disable SIP, and already came with patches integrated in the macOS image. Either way, it's only useful for replacing files in the system (during upgrades) in protected locations. You can place kexts in system folders with it (which can already be done with other methods), but it doesn't stop kernel checks once it starts the attempt of linking against unsigned kexts, which is the actual problem at hand.
You could try to get around it by pre-linking a kernel and dropping it in during the installation phase, but it doesn't stop it getting overwritten after App Store updates, or if the SIP flag in NVRAM is accidentally changed, causing a re-link, which is what I think is causing most of the "USB/Keyboard/Mouse" losses in this thread.
Thanks for the clear reply. What I don't understand is how SIP checks would know to remove added .kexts if they were installed with rootless entitlements. Does SIP simply remove any file without proper signing? So if I understand it, then other than wholesale disabling of SIP, the only other way around this issue is to get properly signed kernel extensions? Is there any way to find someone with a developer license to do this?
SIP as a system has multiple functions to prevent unwanted software from executing, and unwanted changes to the system. One of them is to prevent files from being written to system folders. Another function is to prevent the kernel from loading kernel extensions that weren't signed by Apple or a valid developer.
macOS Sierra (and other modern OS X versions) no longer load kernel extensions directly from their individual files. Rather, there is a "linking" process that essentially combines the base kernel with all the known extensions that are installed on the system, into one big "file" that is faster to run on startup (which is known as the pre-linked kernel). This process is ran by the kernel itself, on the first time macOS is installed, on every OS update, whenever the SIP flag is changed, if the pre-linked kernel somehow is corrupted, or if you manually trigger it.
When the "SIP" flag in NVRAM (the collection of EFI variables in system memory) is set to enabled, the kernel seeks all the kernel extensions it can find (mainly in /System/Library/Extensions, for stock extensions, and /Library/Extensions, for 3rd party extensions, even though both are treated equally), checks for a valid signature from Apple in the extension, does a few processes like dependency resolution, etc, and if it's valid, then it adds it to the pre-linked kernel. Those that don't pass the check are just ignored, not deleted, and an error is returned (MyKernelExtension.kext has invalid signature; omitting.) When that's done, it reboots into the newly combined pre-linked kernel, which has the extensions that were accepted already in it.
The key here is that each individual extension has its own signature within its bundle, just like macOS Apps, and the kernel is directed to only allow all the ones with a valid signature (when SIP is on). The signature check doesn't care how it got there (whether it be via an app, installation program, or pure magic), just that the binary is signed properly. When SIP is disabled (and the NVRAM flag is disabled), then the kernel skips the signature check and adds it like any other extension.
Can someone please tell me if running the patch (I checked the box to fix the ALS) will cause any issues? I have the 5,2 MBP and I can't really tell if the ALS is working properly or not.
Thank you in advance
So far no trace of beta 5 .. maybe it also takes again 1 week delay before it comes.
The Mac mini3,1 late 2009 will be bought in the next days, but then the trouble has done.
Well, it is with my Hackintosh machines, with much better performance, such problem is not there, the Dev. Updates come immediately, as well as supported Mac's synonymous.
The Mac mini3,1 late 2009 will be bought in the next days, but then the trouble has done.
Well, it is with my Hackintosh machines, with much better performance, such problem is not there, the Dev. Updates come immediately, as well as supported Mac's synonymous.
It happened again two more times, (MacBook Pro Mid 2009 15inch 5,3) that when I booted my macbook pro with Sierra my touchpad and keyboard suddenly where not working anymore and could not login. This seems to happen when big software (or maybe lauch agents/demons) is installed/uninstalled and this seems to reenable partially SIP.
However this time I found a solution that does not need having the patched sierra installer (and the macOS Post Install) on a usb pen with you:
You need a working recovery partition on you mac and for this you need to have applied the recovery partition patch using dosdude1 macOS Post Install tool during first Sierra install (or, just once, rerun the dosdude macOS Post Install from usb and apply the recovery partition patch)
Boot in recovery partition.
Check that SIP is disabled using "csrutil status" command in terminal
It will say that is disabled (since you installed sierra on an unsupported mac)
Do not care about this message, the problem of mouse and keyboard not working is indeed due to SIP partially enabled
Reenable SIP with the following command:
csrutil enable
then disable it again with
csrutil disable
now reboot normally. Keyboard and mouse will now work (at least for me)
However this time I found a solution that does not need having the patched sierra installer (and the macOS Post Install) on a usb pen with you:
You need a working recovery partition on you mac and for this you need to have applied the recovery partition patch using dosdude1 macOS Post Install tool during first Sierra install (or, just once, rerun the dosdude macOS Post Install from usb and apply the recovery partition patch)
Boot in recovery partition.
Check that SIP is disabled using "csrutil status" command in terminal
It will say that is disabled (since you installed sierra on an unsupported mac)
Do not care about this message, the problem of mouse and keyboard not working is indeed due to SIP partially enabled
Reenable SIP with the following command:
csrutil enable
then disable it again with
csrutil disable
now reboot normally. Keyboard and mouse will now work (at least for me)
Last edited:
On my 2009 MacBook Pro 5.4 I get the keyboard and touchpad error on startup about once a month. I turn my computer off every night. A restart always fixes it.
This is why I am hoping someone with a developer license can get the .kexts signed. Then this SIP crap wouldn't be a problem.It happened again two more times, (MacBook Pro Mid 2009 15inch 5,3) that when I booted my macbook pro with Sierra my touchpad and keyboard suddenly where not working anymore and could not login. This seems to happen when big software (or maybe lauch agents/demons) is installed/uninstalled and this seems to reenable partially SIP.
However this time I found a solution that does not need having the patched sierra installer (and the macOS Post Install) on a usb pen with you:
You need a working recovery partition on you mac and for this you need to have applied the recovery partition patch using dosdude1 macOS Post Install tool during first Sierra install (or, just once, rerun the dosdude macOS Post Install from usb and apply the recovery partition patch)
Boot in recovery partition.
Check that SIP is disabled using "csrutil status" command in terminal
It will say that is disabled (since you installed sierra on an unsupported mac)
Do not care about this message, the problem of mouse and keyboard not working is indeed due to SIP partially enabled
Reenable SIP with the following command:
csrutil enable
then disable it again with
csrutil disable
now reboot normally. Keyboard and mouse will now work (at least for me)