Some questions, also sort of an introduction.

[Attica]

Hello everyone.

 

actually this is my first post, but I've been kind of a longtime lurker.

 

Anyway, today, out of boredom, I installed iatkos l2 on an old 2ghz, 1gb ram System, which was collecting dust.

To my suprise, it worked quite well and after some problems, I got everything working... at least everything that I need.

Amazingly, it's not even that laggy.

 

And tbh, I really DO like it. A lot.

 

So I'd like to finally, FINALLY make the switch from Windows (been on Linux more than once but I need Photoshop and no, Gimp is not an option. :/ ).

 

My main rig:

Amd x6 1055T

Intel x25-M 80 Gig

8 gigs of ram

Asrock 870 Extreme3

GeForce 9600GT

 

I know that my X6 is a no go and I don't want to wait for a kernel that may or may not be released at all.

So I'm thinking about getting an i7 2600 and a nice board.

The other stuff should, afaik, work out of the box or with some minor tweaks, right?

 

Since I'm quite new to the Hackintosh Community, I'd like to hear your opinion on this.

If you can personally recommend a board, I'd also like to know which one.

And since I have Lion already running on this machine (the one I'm typing on right now), I'd like to know if i can move my Stuff to my main rig, if everythings done.

Can I just make a System backup and put it on the other machine?

 

That's all for now.

Also, I'm english is not my first language, so please bear with my poor spelling.

 

Edit: Gosh, forgot to change the title, sorry. :/

[bindubai]

Hint:

Google HCL 10.7.2

There you are!!

 

100's of boards to choose from, you can see people experience too and you know what you're going for.

 

I hope this will help.

[Foxic]

Go for a gigabyte board.

The board in my signature is £115 from hardwareking.info.

 

I use an i7 920 and get a geek bench of about 12300 @3.4GHz.

 

Since you have lion already running it should be pretty simple to just clone your existing system to another hard drive, remove the custom kexts you have installed, replace them with kexts for the hardware the OS will be running on, swap the HDD back to the target PC and boot up.

If you do get the ex58-ud5 I can give you everything to get yourself running 100% (even auto-sleep works).

[Attica]

Sorry for the late reply, I had to work and totally forgot about the Thread.

 

So, in the end, I got a P67.

Found one on Ebay and the price was too good to pass up.

 

Yesterday, I put everything together and right now I'm on my new System.

It took me quite some time to get it running, mostly because I haven't had a CD drive since god knows when.

And the only USB Stick I have a crappy is only 4gb.

 

Anyway, it's all up and running now.

 

I don't really want to open a new thread, just for some basic questions, so...

 

These are the Kexts I've installed:

 

 

ACPIMonitor.kext

AppleIntelE1000e.kext

FakeSMC.kext

IntelCPUMonitor.kext

NVClockX.kext

NVEnabler 64.kext

NullCPUPowerManagement.kext

SuperIOFamily.kext

VoodooHDA.kext

 

Is this the correct approach? (putting those kexts inside /System/Library/Extensions)

Of course, I'm trying to learn myself but there are so may guides out there and I'm quite tired of Kernel Panics.

At least for today.

 

Thanks again for your replies James and Bin. really appreciated.

[Foxic]

You don't want NullPowerManagement installed if you can help it.

 

Clone your OS X partition to another partition/HDD (this will be a backup/rescue partition)

Install chameleon 2.1 (r1700 ish),

remove NullPowerMangement,

repair permissions,

reboot.

At chameleon, type GenerateCStates=Yes GeneratePStates=Yes

 

If you get to your desktop, great, this means AppleCPUPowerManagement has loaded, you now have native power management.

You should notice a drop in temperature and an improvement in performance.

You can now add the 2 boot flags to your org.chameleon.Boot.plist to save you typing them at each boot.

 

If you can't reach your desktop, boot from your backup partition and extract your DSDT using DSDT Editor.

Post the DSDT in the DSDT section with a brief description of whats happening andd hopefully some kind soul will patch it for you.

 

To answer your other question about next location:

In Lion all kexts are placed in S/L/E/ and the boot flag 'UseKernelCache=Yes' added to org.chameleon.Boot.plist.

[Attica]

Hello James,

 

after learning the hard way, I set up an installer partition on another drive, so if something goes wrong, I can access my local installation via terminal.

I will try to get it running without NullPowerManagement and post the results.

 

About DSDT's:

 

I read DSDT's, while a lot more complex, give better compatibility than kexts do.

Is this correct?

I kind of understand the basics, but most posts/tutorials only go so far (getting your dsdt and patching it)

 

Again, thanks for your help.

Hopefully, I'll be back soon. (without having to fix everything. )

[Attica]

So, I updated to Chameleon 2.1 r1814, removed the

NullCPUPowerManagement.kext and set the flags at boot.

 

Gives me a Kernel Panic though.

Booted into my other partition and moved the kext back to the extensions folder.

 

On http://olarila.com/forum/packs.php, there's a Patch for my Board.

Could/Should I use this?

My Board is a Rev3, this just says p67 Sabertooth.

 

I know, a lot of Questions, please bear with me.

 

 

Edit:

 

Someone else seems to have used that patch with a Rev3 Board and everything except sleep seems to be working fine.

[Foxic]

That DSDT appears a good starting point, mainly for reference though.

 

You are free to try the DSDT, place it in Extra and reboot.

If it panics, reboot with DSDT=none at chameleon (this disables dsdt).

 

A DSDT SHOULD ONLY EVER BE USED ON THE HARDWARE ON WHICH IT WAS CREATED.

 

Forgive the caps but this is very important.

 

Your best option may be to extract your own dsdt and compare it with the patched one.

You may be able to apply the same patches to your own DSDT but I would not advise using the DSDT from a different motherboard.

 

*Saying all this, if others with the same board as you have had luck with this DSDT and the only thing not working is sleep you should be ok*

 

Though I still think you would be better off patching your own (or asking someone to patch it for you, possibly using the DSDT you found as a reference).

 

To answer your question about DSDT vs kext:

 

They essentially achieve the same thing - working hardware.

You can typically either add a few kexts to enable certain hardware, or enable that hardware through DSDT.

Sometimes enabling certain hardware works better when done via one method vs the other, but the main difference comes when apple incrementally updates something.

 

Say you are using the patched kext (i.e. made by apple, patched by us) xyz.kext to make your audio work. Apple release their next update which overwrites xyz.kext with a newer version, this destroys the patch.

You then have to re-patch this new version of xyz.kext.

If you had enabled your audio via DSDT rather than via a kext it would not have been overwritten. (DSDT is part of your BIOS)

 

Can you see why DSDT is better in the long run even if it is more complex.

[Attica]

Your best option may be to extract your own dsdt and compare it with the patched one.

 

Well, I took my own DSDT and patched it with the Patch from Olarilla, just like the guy in the other post did.

It gave me some errors, just like the Guide I used said it would.

After fixing those, everything worked out and i got my DSDT.

 

So, when putting this DSDT in my /Extra folder, I assume that I have to remove my own kexts first?

 

Further, I've seen some people with an extensions folder under /Extra.

Would I put my remaining kexts there? (if there are any)

[Foxic]

The only kext you need to remove is NullCPUPowerManagent, leave the others alone for the moment.

 

Place ALL kexts in System/Library/Extensions.

Rebuild caches

Add

<string>UseKernelCache</string>
<key>yes</key>

to your org.chameleon.Boot.plist in /Extra

 

Extensions are only put in /E/E in snow leopard.

[Gringo Vermelho]

So, when putting this DSDT in my /Extra folder, I assume that I have to remove my own kexts first?

 

No. DSDT cannot drive hardware and does not replace kernel extensions - when the kernel extension is a driver*.

 

You can patch certain things in your DSDT to improve compatibility with OS X (such as removing forced IRQs in order to allow OS X to use the IRQs it wants to use), and to trick OS X into loading the appropriate, Apple-provided kernel extension for your hardware, as long as it is "similar enough" to the hardware used in real Intel Macs.

 

This is known as "injection" because by doing this you are effectively "injecting" desired properties of a device into the OS X IORegistry. "EFI" Device Property Strings, as well as Chameleon's GraphicsEnabler and EthernetBuiltIn settings also work this way.

 

Examples:

 

How to trick AppleLPC.kext to load on ICH10R Southbridge via DSDT device ID patch: http://www.projectos...findpost&p=2532

And here, about removing IRQs to resolve sound stuttering and slow SATA transfers: http://www.projectos...p?showtopic=564

 

*note that there are community provided kernel extensions such as LegacyAppleRTC.kext that are not drivers, the purpose of these is to patch existing Apple drivers, in this case AppleRTC.kext. A Legacy kext will have only an info.plist inside that overrides specific contents in the info.plist inside the driver that it's supposed to patch.

Instead of using this particular Legacy/AKA plist-only kext, you could do the same thing via DSDT by patching the RTC device code.

This is not possible with all Legacy kexts though.

[Attica]

Well, I tried to boot with my DSDT, with and without NullCPUPowerManagement.kext.

 

When I boot without it, I get the usual com.Apple.driver.AppleIntelCPUPowerManagement Panic.

If I try it, while NullCPUPowerManagement.kext is installed, I get another Kernel Panic, but because of Voodoo.

 

 

To Gringo:

 

I was thinking more along the lines of something like this:

If my Sound for example, is working thanks to some Kext I had to download, but is now working because I have a nice DSDT installed...

Wouldn't there be some kind of conflict between the apple kext that's now being loaded and the one I provided?

Or am I missing something?

[Foxic]

The DSDT only edit allows the apple kext to load, it does not replace it.

A kext's windows equivalent is a driver if that makes more sense to you.

 

The only time a kext is not needed after a DSDT edit is when that kext dealt with injection, which the DSDT edit does replace.

[Attica]

I understood that part.

 

Sorry, I'm not a native, so my english isn't as good as it should be.

I was wondering if loading TWO drivers at the same time would cause problems.

 

Example:

 

I download a kext for my audio, let's say kext1.kext.

Now I get a nice DSDT and with it, I can get the original apple.kext to work with my system.

Wouldn't those two kexts then conflict with each other, since they're both for the same piece of hardware?

[Gringo Vermelho]

You can't write a sound driver in DSDT. It's like I said, DSDT can't drive hardware.

 

HDAEnabler.kext can be replaced by a generic HDEF device in your DSDT, but neither is a driver, the driver is AppleHDA.kext.

For example: If you were using HDAEnabler before adding the generic HDEF device to your DSDT, then you can now delete HDAEnabler.

 

If you're using VoodooHDA.kext for audio, do not add the HDEF device code to your DSDT as this will make AppleHDA.kext load and cause a conflict with VoodooHDA.kext. VoodooHDA is a community developed driver and it doesn't care what code is in your DSDT.

 

Your example in post #12 is meaningless, it has too many unknowns, if you want answers that you can use you need to be more specific when you ask questions.

 

But yes, like in the example with VoodooHDA and AppleHDA above, if you're trying to get unmodified Apple drivers to load for your hardware by patching DSDT, then you should not use other drivers that drive the same hardware at the same time.

 

This is a rare situation because there are very few 3rd party drivers in existance that will work with hardware that is already supported by Apple drivers. Because, what would be the point.

 

It's hard to generalize about these things because there are so many different ways to work around the issues you might have on a Hackintosh. You must find your own way and use the methods that work for you, on your hardware. Read, study, follow in the footsteps of others and learn what your possibilities are and which tools are available to you. Learn to use these tools. IORegistryExplorer for example is invaluable when working with your DSDT.

 

You need to know how to differentiate between a driver.kext and a property injection kext or method (read my earlier post again, I made an attempt to explain it there). While you will run into trouble using two different drivers for the same hardware, it is entirely possible (though rarely necessary) to mix property injection methods. For example, it is entirely possible to use Chameleon GraphicsEnabler while at the same time injecting additional properties for your video card via Device-Properties string (in the old days this was known as EFI string) or DSDT gfx0 device.

[Attica]

If you're using VoodooHDA.kext for audio, do not add the HDEF device code to your DSDT as this will make AppleHDA.kext load and cause a conflict with VoodooHDA.kext.

 

THIS was exactly what I meant.

Thanks Gringo.

I was just wondering if a conflict would arise if I were to do that.

 

Damn, sorry to cause you guys some headache.

[Gringo Vermelho]

No problem Attica, I wouldn't be doing this if I didn't enjoy it.

 

Good luck.

[Attica]

Thanks.

 

Well, everything's working, so it's not a big deal anyway.

I never use features like sleep so I haven't tested those nor do I really care about them.

Everything else is working great and I've yet to encouter problems (well, except for small stuff like voodoo preferences not saving settings).

 

So, in the next few days, I'll try to get my DSDT patched/working and opt for removing

NullCPUPowerManagement, without a kernel panic, that

is.