Yes. It is two seconds quicker. Look at the spinner below the Apple logo, and notice a slight improvement before your sceen is initialized. That's where the improved should be noticed.


In that case additional testing is required (for P5K VM users). I understand that it hangs at a point where your BIOS screen should be displayed, which makes me wonder if OSXRestart.kext is still loaded as the same thing happens when I unload the kext and try to restart from the Apple menu.

You might want to try: sudo kextunload OSXRestart.kext before entering sleep, and use: sudo kextload OSXRestart.kext after sleep, before doing a restart, to see if that helps. And restart-after-sleep fails in both 32 and 64 bit mode?

I'm talking about skipping the BIOS initialization, which slows down the boot process considerably. Just ask William Parker

Note: I want firmware (BIOS) to load the kernel without any initialization whatsoever, because OS X can handle it... enter Google OS – I am pretty sure that its source code is being read a lot these days. People looking for clues...

That's the "PCI Express Port 1" which is a root domain controller. Look for PCITOPLevel in ioreg -l output. There's your answer (the other ports are linked to it).


And P0P4 should not be visible when the Jmicron controller is disabled in the BIOS. However, you may have forced a connection from your DSDT. And you could check this by looking at the ioreg output, because it should not be there without anything connected to it. Or there's something else active. Just to give you some ideas.

p.s. You may want to renamed these, because it was confusing the heck out of me


You agree? Should I read this as a confirmation?

And thank you for the wake up call

Ok, Just asking, to be sure. Are other P5K-VM users here having a similar restart problem?


That might indeed be a problem. You could disconnect the drive to see if that solves it. At least then you know for sure?


You should only see active ports with ioreg and IORegistryExplorer, where some sort of connection has been established. And not only by inserting a PCI(E) card, because P0P8 won't show up until I enable the PATA device in my BIOS. Just to name one example

p.s. I ripped another 365 bytes, not by removing features or functionality, but by re-writing some of the code.

No problem here, but my DSDT is optimized to work with OSXRestart.kext – see attachments in post #3


No, unfortunately not. You may remove this code. And what exactly is the problem? The drive won't spin down for sleep?


No! These are part of each ICH9 chip set. Even the ICH10 and older chipsets. And the minute people plug in something BOOM

Thanks


Yes, because the _Sn data is static in Apple DSDT's and it isn't expecting a shift in S state.

Absolutely! Good catch – a failing last minute change. Thanks!


I wouldn't know why, but I will try to figure it out – by adding a dummy _CST object under CPU2.

Edit: No change whatsoever with a dummy object. Not to mention that Apple DSDT's are using:
So I don't think so. I mean it isn't using any _CST object on the second Processor definition block. That's why I removed it a while ago

Another highly optimized DSDT, with a massive code reduction (25%) is now available (as example) in the P5K PRO Snow Leopard Thread.

Happy Hacking!


Great – I was a little busy the other day, but I will have a look at it, later today.



Now imagine a smart boot loader, one selecting ACPI mode for your chipset... problem solved – you end up with a blistering fast boot process (no more ACPI nagging at boot time).

DSDT V3.2 has been released today – see attachments in post #3

The size of our previous update was:
dsdt.dsl 111.179 bytes
dsdt.aml 10.690 bytes

And todays update:
dsdt.dsl 95.260 bytes
dsdt.aml 7.957 bytes

A massive 25% off. Which makes it a rather significant update. With lots of new comments. Making the code reduction of dsdt.dsl even more impressive, since I have been adding so much spaces/text. Let's have a look at a few examples:
And this one:
Again highly optimized – without going back in terms of readability – to squeeze out even the very last byte. And not a single change was done by 'trial and error' but after doing a lot more, additional, reading of the ACPI specification. Quite a few hours to be honest – I don't go change anything anymore without first knowing what it does / how it works.

And while I was working on code reduction of GPRW, which I have eliminated with this update, I realized to have made an error. That is why I moved the buffers out of Methods MCID and MCBN into the global name space, because this way we reduce the memory footprint. Yup. Learned something new again.

I also know that this update might be a little too much for some. A judgment error. Which is entirely my fault. And if DB1 hadn't mentioned a new release... it might have been Christmas by now. Yeah, I should have released an update earlier, but I didn't realize what I had done since V3.1. Well, just hang in, and feel free to ask for help. As long as it's you doing most of the work

Well. I think this covers it. And as always; Happy Hacking!

@julia24 & blackosx: Thank you!

Thanks, and you are right. We're going to release DSDT V3.2 Saturday (in a few hours).

I am going to waste spent some time today trying to change this code snippet:
One of the reasons is that I looked at it a couple of times, and I keep wondering about the red line. I mean S2 isn't even supported on our Asus board so what is it doing there? Why add something when you, as developer, know that it is useless? A contractor getting payed by the line maybe?

Not to mention that this code is called up to 16 times at boot time (UHC[1-6], P0P[2-9], PCIB, EHCI and UHCI). 14 times minimum (without EHCI and UHCI). And all this bit shifting can be done with one single line. I think. What if I make it static? I mean it sure isn't going to change at run time. Does it? Nah. No way. Yeah. Let me give it a try. I like to burn my fingers on other peoples code...

This should work:
At least it compiles. ACPI CA Debugger started... Oops. I forgot to add ShiftLeft (SLPM, One, SLPS) Method _PIC is my temporarily target for it. And now it works. I think. Testing... Done. It works.

Uhg. A mere four bytes smaller. Not exactly what I hoped for, but it wasn't my main concern. Boot speed is

And the names might change. Probably. Already done. BTW: The new Field (BIOS... should be put under your current one. Do not replace it with the new one! It's an addition to the current one, to get the byte value of the sleep state bits.

Note: This is an Asus specific change. Do not add Method (GPRW) when you don't already have one. However, every BIOS with Power Management (and sleep) settings should have something like this.

This change will also be part of DSDT V3.2

Right. Kids are home from school so daddy is going to have some quality time now. Later folks.

And as always... Happy Hacking!

That was actually part of a previous post (#378) but here's the one to get the sleep byte:

sudo reggie_se -D PhysAddr -r -a 0xCFF8E064 -B 8

Note: Most other values in the BIOS table are 32 bit wide so you have to change the 8 in 32. And change the address of course

Lines are cut off. Do a lspci -xxxvvv in a terminal window and ZIP/attach it.

Tip: Don't use .rtf but .txt next time



Yes, you can remove these, along with UAR1 and all junk used by it.



Which is a smart thing to do, because this way you free IRQ's!

How many of you have ACPI enabled for all SATA ports, instead of just the boot drive? You might want to give this a try, for dedicated OS X machines, since this will reduce your boot time!

Someone asked me why I use this:
Instead of the old:
And:
instead of:
Which I think was a good question and thus here goes:

It isn't only shorter in terms of lines numbers, but also saves a few extra bytes in your dsdt.aml due to the fact that my code is highly optimized. The first one reduced the AML code by 15 bytes, and the latter by 4. And that for each time this was used! And thus I thought this to be worth the trouble.

Here's the first part of the Asus BIOS table:
This is my own, personal interpretation. Not officially documented information, and thus I might be wrong. We also no longer include TOPM and ROMS (wasn't used anyway) but IOST will also be gone in DSDT V3.2

The P5K Pro BIOS has one sleep setting, and the table below shows you how the sleep bits change, when you select one of the options:

1001 S1 (POS) only
1100 S3 only
1101 Auto

Next up: The IOST one, which is the only one I am uncertain about. Testing... doesn't seem to change. Is used in Device (FDC) and Device (UAR1) both connected via the Winbond Super IO Chip. Whatever. I removed these for the next update so who cares.

Note: I used reggie_se to get the values (for my board and BIOS settings).

Right. Now enter: ioreg -l in a terminal window and attached the output, as a compressed (ZIP) file here.


And everything else but sleep works? Nice.


You're welcome. And the omission of the card in System Profiler, well that is just a cosmetic glitch (need ioreg output for fix). Let's address that sleep problem first shall we. Or at least give it a try

Let's try some good old logic:

1) Remove the card.
2) Test sleep.
3) Result: Sleep either works now, or still fails.


That's because Asus boards have functional BIOS features, which appears to be missing, or failing on (some) GB boards.

It is good to hear that other people are using it, and that it works for them... thank you for the confirmation and the newly added signature, but it is taking up quite a bit of vertical space. You may want to change it into 3-5 long lines. I mean think about the poor notebook users. Not to mention that I have to concentrate real hard before I can even read the green parts. Pretty distracting right now. Or are my old eyes losing it?

I wouldn't be surprised when the Asus card simply reads PICM, especially since Method _PIC returns nothing, and this is Asus. You could add the one used in your Asus DSTD – which I presume is PICM – and see if that helps.

Nice. Might this be a post test card? Link?

Edit: Never mind. Found it. This is the Asus test card supplied by Asus with certain motherboards.


That means that Apple is doing things differently. Let me check this after my reply.


The card might be looking for something under a different name. There's nothing in the manual about it? They don't have a support forum for this card? I mean maybe you can ask it there.


Not if you are talking about the: "Start up after a power failure" because that is still part of my Energy Saver panel.


Oh right. Sorry. I copied SystemVersion.plist to ServerVersion.plist because I tried to install OS X 10.6 in VMware Fusion (which is what I use for EFI hacking) which works now with a simple script.

Edit: The upgrade to 10.6.2 completed without a hitch. Another swell Apple upgrade.

This isn't related to any kind of restart fix. Unfortunately not. Shutdown only. And most likely for Asus boards only.

BTW: I am still waiting for someone with a GB board to test the Asus BIOS table address, minus one, to see if that points to Sleep State bits, so please give it a go for me

Great. Now you are in par for the next set of changes

Ok. Time for another update. Try this:
Next would be the one I am using. And while you're at it, remove this:
And change this:
into:
These will also be gone in DSDT V3.2 along with 13K unused code.


Unfortunately not no (Asus is tight lip about it) but I do know that it is doing the same as what I did with:
The other parts are most likely related to either fan control, power management, or both.

I am going to try use this stripped down, over-simplified copy of Method _PTS:
Edit: Just did a quick sleep - wake - sleep - wake - shutdown - boot, without any problem whatsoever. And another one. Both sleep and shutdown work. Time to add back the missing pieces

And this is it:
Additional comments in DSDT V3.2

p.s. This is funny; The Asus support site has an option for MAC OS. I wonder what their response is when you select it... not-supported I guess

That doesn't look right. You first trigger sleep state (S3) and then change that into shutdown. Which is what we used to do, simply because Asus did it this way, but I like to change it... because it makes no sense. And I don't seem to need it anymore. This is what I use now:
I verified the Energy Settings setting: "Start up automatically after power failure" which has no influence on the sleep/shutdown process here – both on and off work. I also verified the BIOS settings under APM Configuration where I have everything set to [Disabled] except for the first one, being: "Restore on AC Power Loss" which I can set to (from the top of my head): Power On, Power Off or Last State. Either one works.

p.s. Please add a signature (My Control) because I don't know what hardware you are using, only after downloading the attached DSDT, which makes things a little more complicated for me. Thank you!


I'll have a quick look at your DSDT, right now... The attached DSDT includes most of the patches, but little changes to Method _PTS. Please give it a try.