Contribute
Register

DSDT Debugging/Tracing to system.log

Status
Not open for further replies.
Wow it would be mighty weird for Cupertino to set _OS to "Microsoft Windows NT" :lol:
If they did, they are taking a **** cause it detects a hackingtosh.
Most likely is that the BIOS has default value of "Microsoft Windows NT" and YS never sets up the _OS variable ?

No. The OS implements _OS in the ACPI host code. They probably get some code from Intel here and simply forgot to change it!

...
Is safe to take out all the code for OS checks in _INI and simply setup the SMIP, OSFL and OSFX to the values that works for all three OS's ?

Yes.

Also, how do I PUSH out what _OSI contains as it seems like a function that return a Boolean ?

Correct. It returns true/false (0/1). You can print it for any input you like...
 
Thx.
So I took out the checks on the _OS and _OSI and now simply have :
Code:
                Method (^_INI, 0, NotSerialized)  // _INI: Initialize
                {
[COLOR=#ff0000]                    \RMDT.P2 ("in Method _INI, _OS = ", _OS)[/COLOR]
                    Store (0x59, SMIP)
                    Store (Zero, OSFL)
                    Store (0x04, OSFX)
                    Store (One, AMAC)
[COLOR=#ff0000]                    \RMDT.P6 ("Exit Method _INI, SMIP = ", SMIP, "OSFL =", OSFL, "OSFX =", OSFX)[/COLOR]
                }
...and three OS's behave ...i.e. wake from Sleep.
SL is the best behaved in that it instantly sleeps and instantly wakes and I mean within a second.
MV takes about 20 seconds to sleep and wakes instantly
YS takes about 30 seconds to sleep (HDD light thrashing) and wakes instantly.

Theoretically, this (getting rid of OS checks) would break Virtual Machines ?
That is, if I ran Windows or Linux virtual machine, does it inherit the DSDT of OS X ?
 
Thx.
So I took out the checks on the _OS and _OSI and now simply have :
Code:
                Method (^_INI, 0, NotSerialized)  // _INI: Initialize
                {
[COLOR=#ff0000]                    \RMDT.P2 ("in Method _INI, _OS = ", _OS)[/COLOR]
                    Store (0x59, SMIP)
                    Store (Zero, OSFL)
                    Store (0x04, OSFX)
                    Store (One, AMAC)
[COLOR=#ff0000]                    \RMDT.P6 ("Exit Method _INI, SMIP = ", SMIP, "OSFL =", OSFL, "OSFX =", OSFX)[/COLOR]
                }
...and three OS's behave ...i.e. wake from Sleep.
SL is the best behaved in that it instantly sleeps and instantly wakes and I mean within a second.
MV takes about 20 seconds to sleep and wakes instantly
YS takes about 30 seconds to sleep (HDD light thrashing) and wakes instantly.

You might disable hibernation...

Code:
sudo pmset hibernatemode 0

Note that Mavericks & Yosemite have a built-in delay before sleep starts. Theorize that is for the case the user accidentally sleeps and changes their mind quickly...

Theoretically, this (getting rid of OS checks) would break Virtual Machines ?
That is, if I ran Windows or Linux virtual machine, does it inherit the DSDT of OS X ?

I've never played with VMs on OS X. My guess is that the VM host provides its own DSDT completely unrelated to the native DSDT.
 
Hibernation is turned off on all 3 OS's.
YS is definitely saving something when it goes to sleep.

Oh, BTW the 2 hourly wakes during night are a "feature" of YS.
Lot of real Mac owners are complaining of the systems waking up every 2 hours.
Macbook Pro users do not notice it so much as their fans are so quite.
It's something to do with the mdnsresponder being replaced by a new daemon.
 
Hibernation is turned off on all 3 OS's.
YS is definitely saving something when it goes to sleep.

Check hibernation mode.

Also background processes (pmset -g assertions) can delay sleep.

Oh, BTW the 2 hourly wakes during night are a "feature" of YS.
Lot of real Mac owners are complaining of the systems waking up every 2 hours.
Macbook Pro users do not notice it so much as their fans are so quite.
It's something to do with the mdnsresponder being replaced by a new daemon.

Yes.
 
Check hibernation mode.

Also background processes (pmset -g assertions) can delay sleep.
Just checked hibernation and assertions:
Code:
[COLOR=#34BBC7][FONT=Menlo]MacNB[/FONT][/COLOR][COLOR=#000000][FONT=Menlo]@[/FONT][/COLOR][COLOR=#34BD26][FONT=Menlo]MacNB-Mac-Pro:[/FONT][/COLOR][COLOR=#AFAD24][FONT=Menlo][B]~[/B][/FONT][/COLOR][COLOR=#000000][FONT=Menlo]$ pmset -g [/FONT][/COLOR][FONT=Menlo]Active Profiles:[/FONT]
[FONT=Menlo]AC Power        -1*[/FONT]
[FONT=Menlo]Currently in use:[/FONT]
[FONT=Menlo] hibernatemode        0[/FONT]
[FONT=Menlo] womp                 0[/FONT]
[FONT=Menlo] networkoversleep     0[/FONT]
[FONT=Menlo] sleep                10[/FONT]
[FONT=Menlo] Sleep On Power Button 1[/FONT]
[FONT=Menlo] ttyskeepawake        1[/FONT]
[FONT=Menlo] hibernatefile        /var/vm/sleepimage[/FONT]
[FONT=Menlo] autorestart          0[/FONT]
[FONT=Menlo] disksleep            10[/FONT]
[FONT=Menlo] displaysleep         5[/FONT]
[FONT=Menlo][COLOR=#34bbc7]MacNB[/COLOR]@[COLOR=#34bd26]MacNB-Mac-Pro:[/COLOR][COLOR=#afad24][B]~[/B][/COLOR]$ pmset -g assertions[/FONT]
[FONT=Menlo]2014-11-06 22:32:51 +0000 [/FONT]
[FONT=Menlo]Assertion status system-wide:[/FONT]
[FONT=Menlo]   BackgroundTask                 0[/FONT]
[FONT=Menlo]   ApplePushServiceTask           0[/FONT]
[FONT=Menlo]   UserIsActive                   1[/FONT]
[FONT=Menlo]   PreventUserIdleDisplaySleep    0[/FONT]
[FONT=Menlo]   PreventSystemSleep             0[/FONT]
[FONT=Menlo]   ExternalMedia                  0[/FONT]
[FONT=Menlo]   PreventUserIdleSystemSleep     0[/FONT]
[FONT=Menlo]   NetworkClientActive            0[/FONT]
[FONT=Menlo]Listed by owning process:[/FONT]
[FONT=Menlo]   pid 70(hidd): [0x0000030c00090194] 00:02:50 UserIsActive named: "com.apple.iohideventsystem.queue.tickle" [/FONT]
[FONT=Menlo]    Timeout will fire in 162 secs Action=TimeoutActionRelease[/FONT]
[FONT=Menlo]Kernel Assertions: 0xc=USB,BT-HID[/FONT]
[FONT=Menlo]   id=500  level=255 0x4=USB mod=06/11/2014 21:22 description=EHC2 owner=AppleUSBEHCI[/FONT]
[FONT=Menlo]   id=501  level=255 0x4=USB mod=06/11/2014 21:22 description=EHC1 owner=AppleUSBEHCI[/FONT]
[FONT=Menlo]   id=504  level=255 0x4=USB mod=06/11/2014 21:29 description=UHC5 owner=AppleUSBUHCI[/FONT]
[FONT=Menlo]   id=509  level=255 0x8=BT-HID mod=01/01/1970 01:00 description=com.apple.driver.IOBluetoothHIDDriver owner=BNBMouseDevice[/FONT]
[FONT=Menlo][COLOR=#34bbc7]MacNB[/COLOR]@[COLOR=#34bd26]MacNB-Mac-Pro:[/COLOR][COLOR=#afad24][B]~[/B][/COLOR]$ ls -al /var/vm/sleepimage[/FONT]
[FONT=Menlo]ls: /var/vm/sleepimage: No such file or directory[/FONT]
[COLOR=#34BBC7][FONT=Menlo]MacNB[/FONT][/COLOR][COLOR=#000000][FONT=Menlo]@[/FONT][/COLOR][COLOR=#34BD26][FONT=Menlo]MacNB-Mac-Pro:[/FONT][/COLOR][COLOR=#AFAD24][FONT=Menlo][B]~[/B][/FONT][/COLOR][COLOR=#000000][FONT=Menlo]$[/FONT][/COLOR]
Not sure what it's showing me but one process com.apple.iohideventsystem.queue.tickle is listed but not sure what it does (looks like bluetooth related).
 
Hi, Mr Rehabman, I'm learning how to use your new ACPIKeyboard.kext.

I almost can understand whole README, but "ADB keystroke" and "delegated keydown" or "non-delegated keydown".

I try to google "ADB keystroke", but I just get the result that "Android Debug Bridge", so I would like to confirm to you what is the meaning of the word and "delegated keydown" or "non-delegated keydown".

Sorry for my poor english.
:cry:
 
Hi, Mr Rehabman, I'm learning how to use your new ACPIKeyboard.kext.

I almost can understand whole README, but "ADB keystroke" and "delegated keydown" or "non-delegated keydown".

I try to google "ADB keystroke", but I just get the result that "Android Debug Bridge", so I would like to confirm to you what is the meaning of the word and "delegated keydown" or "non-delegated keydown".

Sorry for my poor english.
:cry:

Note, slightly off-topic, but in regards to: https://github.com/RehabMan/OS-X-ACPI-Keyboard

ADB codes are what IOHIKeyboard uses for keycodes (codes that represent keys being pressed/released on a keyboard).

The actual codes correspond to a keymap that describes the purpose of the key. You will find the keymap in ACPIKeyboard.cpp, function ACPIKeyboard::defaultKeymapOfLength. You can see each ADB code in the comment at the end of the ADB keycode definition.

For example, in that keymap, 0x00 is the 'A' key, 0x28 is the 'K' key. And 0x90 is brightness up, 0x91 is brightness down.

The difference between delegated and non-delegated ADB codes is that non-delegated keycodes are sent from the ACPIKeyboard itself, and delegated keycodes are sent through the installed PS2 driver. Because the PS2 driver in use may return a different keymap in its implementation of defaultKeymapOfLength, the ADB codes for the PS2 driver may not be the same as the ADB codes used by ACPIKeyboard. For example, the keymap for the ELAN driver is decidedly different from ACPIKeyboard and my version of VoodooPS2Keyboard. You can see the keymap bits in the HIDKeyMapping property in ioreg. That was how I determined the codes for brightness up/down that are used by the ELAN driver.

The ADB codes used by ACPIKeyboard.kext are the same as the ADB codes used by my version of VoodooPS2Keyboard.kext. That is, they each return the same data from defaultKeymapOfLength.

The advantage of sending delegated keycodes is that the keys appear to come from the real PS2 keyboard instead of a separate keyboard. This makes modifier keys (such as Ctrl, Shift, Option, Command) work with the events generated via ACPIKeyboard. Non-delegated codes appear to the system as coming from a separate keyboard (because ACPIKeyboard is a separate [virtual] keyboard), and therefore are not affected by modifier keys on the real PS2 keyboard.

Think of it this way... If you had two USB keyboards connected to the system, you would not expect modifier keys held down on one keyboard to affect keystrokes on the other. But in this case, since the keys actually do originate from the same physical device (although handled by two separate software components), that's exactly what is desired.
 
ADB codes are what IOHIKeyboard uses for keycodes (codes that represent keys being pressed/released on a keyboard).

The actual codes correspond to a keymap that describes the purpose of the key. You will find the keymap in ACPIKeyboard.cpp, function ACPIKeyboard::defaultKeymapOfLength. You can see each ADB code in the comment at the end of the ADB keycode definition.

For example, in that keymap, 0x00 is the 'A' key, 0x28 is the 'K' key. And 0x90 is brightness up, 0x91 is brightness down.

The difference between delegated and non-delegated ADB codes is that non-delegated keycodes are sent from the ACPIKeyboard itself, and delegated keycodes are sent through the installed PS2 driver. Because the PS2 driver in use may return a different keymap in its implementation of defaultKeymapOfLength, the ADB codes for the PS2 driver may not be the same as the ADB codes used by ACPIKeyboard. For example, the keymap for the ELAN driver is decidedly different from ACPIKeyboard and my version of VoodooPS2Keyboard. You can see the keymap bits in the HIDKeyMapping property in ioreg. That was how I determined the codes for brightness up/down that are used by the ELAN driver.

The ADB codes used by ACPIKeyboard.kext are the same as the ADB codes used by my version of VoodooPS2Keyboard.kext. That is, they each return the same data from defaultKeymapOfLength.

The advantage of sending delegated keycodes is that the keys appear to come from the real PS2 keyboard instead of a separate keyboard. This makes modifier keys (such as Ctrl, Shift, Option, Command) work with the events generated via ACPIKeyboard. Non-delegated codes appear to the system as coming from a separate keyboard (because ACPIKeyboard is a separate [virtual] keyboard), and therefore are not affected by modifier keys on the real PS2 keyboard.

Think of it this way... If you had two USB keyboards connected to the system, you would not expect modifier keys held down on one keyboard to affect keystrokes on the other. But in this case, since the keys actually do originate from the same physical device (although handled by two separate software components), that's exactly what is desired.

I got it.

Thanks for your time for my curiosity. :)

Thanks again.

:thumbup:
 
I know you had said my system is to old to try and troubleshoot sleep/wake/shutdown so I am giving your ACPIDebug/DSDT RMDT patching a try. I have EmlyDinesh helping me with this and he suggested to try the ACPIdebug/DSDT RMDT patch to see if we can catch anything. There are complaints on real iMacs and older MacBookPros suffering from the same conditions. After googling a bunch I have tried everything I am sure there is more to try but here is my System.log. All I get out of this is the error code for sleep which I am assuming is a kernel generated code maybe generic? I attached the System.log.

Sleep failure code 0x00000000 0x1f006700

My System is Asus G51JX-X2 i7-720QM with Nvidia GTS 360m. No problems in Yosemite. I am having a debug session with him later this morning but if you see anything from your experience in the log please let me know.

I have not tried ioio in terminal yet looking over all the messages in console.

Thanks
 

Attachments

  • system.log.zip
    162.6 KB · Views: 137
Status
Not open for further replies.
Back
Top