You may have seen something like this in one of your ACPI tables:
Store ("Some text", Debug)
And you may wonder what you need to do to see the debug messages at startup. Well. That is easier than you might expect. And no. You don’t need to install anything. Just add this to: /Library/Preferences/SystemConfiguration/com.apple.Boot.plist
-v debug=0x12a acpi_layer=0x08 acpi_level=0x02
The number one reason for telling you this is that it enables you to check what ACPI Methods in the processor scopes are being called/evaluated.
I did the same and here I only see the debug messages for the following ACPI Methods in the processor scopes: _INI, _PDC, APSS, ACST and _DSM. The latter of course only for CPU0 on Ivy Bridge and Haswell configurations, where we inject a ‘plugin-type’ property, set to 1, to trigger the load of the required plugins. And thus, all other methods in power management related ACPI tables is cruft and can be removed/forgotten.
Oh and here is another tip. The output may scroll too fast, as it did here, but you can stop it by adding Sleep (10000) in the last Processor Scope. This way it waits for 10 seconds before continuing. I also use my iPhone/iPad to film the output.
Note: I am aware of other tools that dump the debug messages, but I love to share anything that may help us. This may not be the best solution for you, but this is what I use today.
Update
Download debugMachKernel.sh and change your boot arguments to:
-v debug=0x12a acpi_layer=0x08 acpi_level=0x02 msgbuf=309212
Reboot and the debug output can be found in: /var/log/system.log or use: sudo dmesg | grep ACPI.
Update-2
With macOS Sierra we only need:
debug=0x12a acpi_layer=0x08 acpi_level=0x02
Reboot and enter:
log show --predicate 'process == "kernel"' --debug --last "5m"
This is everything that you need to do.
Pike's Universum 
Which tools dump the debug output? I looked for ages to capture the IGPU debug text which didn’t get logged anywhere. Serial port is a No-no for me as I don’t have the LPC board to connect to the debug header 😦
AppleACPIPlatform.kext dumps the Store (“something”, Debug) data to the console, when you use the provided boot arguments, but for IGPU only logging you need to set the right debug boot argument (add: igdebug=0xff).
That doesn’t really answer my question, perhaps I misunderstood what you were saying in the first place. I thought you meant there were products that capture the debug output for later viewing, like to a file.
I wasn’t talking about other tools, but I was replying to this part of your comment: “I looked for ages to capture the IGPU debug text which didn’t get logged anywhere.” and with the correct boot arguments… it does work. Then you should find it during startups, but it won’t get logged in any file.
Edit: Oops. I forgot that it does log this info:
direction: 1, GT_CORE_STAT 1000040, GT_PERF_STAT 85e, therm_stat: 88450000, fLastRequestedPState: 9
I know it doesn’t get logged in a file, it scrolls past like lightning and taking pics of the screen or a vid just doesn’t yield clear images.
Hence when I saw this I thought you knew if a tool to capture it. I know how to enable the debug as you told me previously (thanks!)
Yeah I know. It is indeed quick. Too fast. Maybe a kernel mod can help.
I tried this, but could not see any output in system.log (I tried adding a debug to _WAK) then checked system.log after wake from sleep. Nothing.
I prefer my tool: https://github.com/RehabMan/OS-X-ACPI-Debug.
It works, and can dump Packages, Buffers, Strings, Integers, etc.
I’m aware of your kext. Thanks for the link, but the idea here is to explain boot arguments that enable people to dump power management related methods – hence the reference to _PDC, APSS, ACST and _DSM methods – at startup, without using anything but OS X. Without the need of proprietary methods. I should have made that clear…
BTW. AppleACPIPlatform.kext uses kprintf() and not IOLog() so you won’t find anything in /var/log/system.log
OK… no worries…
kprintf… not so useful then. To resolve all but the simplest of problems, you need logs to a file for later analysis.
There’s a kernel boot option msgbuf (or msgbufsize) that one can set which will increase the buffer size from 16k to whatever you like, i.e.:
-v debug=0x12a acpi_layer=0x08 acpi_level=0x02 msgbuf=131072
This way you don’t need to sleep any process or film with your mobile, just dmesg from the root shell.
Bah, some of the stuff does not get recorded in the buffer because of kprintf vs printf. Well, obvious next step is to force the kernel to give us what we want. 🙂
Assuming virgin mach_kernel 10.9, at the offset 0x4e8ff1 the following bytes: 55 48 89 e5 41 57 should be replaced by: e9 ab 6f b4 ff 90, to get a more “chattery” kernel.
Exactly! All we need are a few changed bytes (_kprintf: jmpq to _printf:) and we’re ready to roll. Thanks for sharing this here!
Hi Pike 🙂
I don’t know how to contact you 🙂
So i try here… it’s Offtopic 🙂 Sry for that!
But can you add i7-4558U (HM87/Iris5100)
to the ssdtPRGen Script?
Thank you very much! 🙂
PS: If you want to experiment with me, i have an (Asus UX301LA)
You are really welcome for any experiments with my laptop 🙂
Contact details can be found in ssdtPRGen.sh but sure. No problem. I’ll add it later today.
We’re also going to have a few more/other updates soon. Before 2014.
Thank you very much! 🙂
No problem. New data now available!
Pike?
Do you have an idea, how i can debug _WAK/WAK?
i get a sucessfull sleep, but reboot on wake (It tryes to wake and reboot) 🙂
the only one output i get on wake is only:
Jan 17 00:59:40 ramas-mbp.fritz.box WindowServer[109]: _CGXHWCaptureWindowList: No capable active display found.
But that says nothing to me…
I tryed already RehabMans debug way… and its working on every part of the dsdt… but not on wake… (for me…)
Du you have any ideas?
PS: if you need, i decompiled some tables from the newest MacbookAir/pro/iMac ‘s
https://github.com/Ramalama2/UX301_DSDT
Im sorry to mess you with my problems… but im really at the end now with my nervs, after 3 weeks of trying xD
Thank you Pike! 🙂
Use a patched mach_kernel to figure out what is going on.
About the decompiled tables. We have a script for it as well. Thanks.
Thank you Pike! But where i can find patched mach_kernel for osx 10.9.1?
Ive seen that only for 10.8.5 or something older…
Ps: I have used your script… i asked that, because if you or someone else need that… dont need todo the work again…
Thank you Pike 🙂
Sorry. No idea. I have a script that I used. Will look it up and add it to my Dropbox (some day soon).
And it wasn’t me who write the script. I only changed it so that it extracts more ACPI tables.
do you know of any tool or something to monitor acpi events, eg. USB. My system freezes if I enable usb3 in the bios. I tried everything but nothing works ( I am talking about native usb3 based on intel xhc controller). I’d like to see what happens when the system freezes. Maybe a call to some method. I don’t know, console doesn’t help as the system freezes as soon as usb3 is invoked (usb3 device in usb3 port under yosemite, while instant freeze during boot under el capitan). I have a series 7 mb.
No, but I don’t think it would help anyone to fix USB related problems. And the best tip I could think of right now is to visit this thread http://www.insanelymac.com/forum/topic/306777-guide-usb-fix-el-capitan-1011/page-1
Yes I know about usb problems in 10.11. Though I have a peculiar problem. The system freezes completely if XHC controller is enabled in bios. I couldn’t find any solution. DSDT is patched correctly. Everything is set as it should. In single user verbose mode I can see the system hangs at AppleUSBLegacyRoot::init
Hi Chris,
That’s about when you should see: “[ PCI configuration begin ] “…
What motherboard brand/model are you using?
The mb is x401a series 7 in Asus f301a laptop (x301a x401a and x501a) all share the same MB.
Chipset is hm76. XHC controller 1e318086.
I’ve been reading all morning, about to start testing adding the debug calls to my DSDT. Just enabling the output in the log files has helped me start to understand the boot sequence better. Is my understanding correct that I can add debug messages to _INI and _DSM methods in the DSDT to see when those processes are being called in debug mode with mach.kernal? Will be testing shortly, would just like to avoid repeated disk swaps when I might have to fix things. Thank you!
Well yes, but you can add it to any ACPI method.
Thank you. Added it, to start, to all INI and DSM methods. I now have an error reporting, seems to be right at when a Thunderbolt SSDT I made starts loading. The line is “0 kernel: (AppleACPIPlatform) Unsupported module-level executable opcode 0x70 at table offset 0x141C8”. I feel this just started after I added the debug messages, though I admit to not checking the log after every reboot. How can I look at this line and begin to trace the error I have made?
Open the ACPI table in a hex editor and go to the reported offset. There should be some readable text that gives you a clue as to where to look in the disassembled ACPI table.
Thank you
… and not to be greedy, as I’m running down tables and seeing where this will help me… but it appears this reports the text to the debug log. Is there a possible way to output, say the result of an _OSC method to the output to the debugger? If that is a lengthy process, would you mind pointing me in the right direction to figure it out?
Think VM machine 😉