DSDT - Vanilla Speedstep - Generic Scope (_PR)

[blackosx]

I wonder if this saves you revs at startup. Does it?

No difference unfortunately.

[mm67]

Thank you for the confirmation!

 

And thus as a golden rule... from now on: When you see (a) SSDT-n table(s) in there, then you should use DropSSDT=yes when you changed / fixed your DSDT. Otherwise it has no meaning.

 

Why would using DropSSDT option be necessary. What about this statement from Acpispec:

SSDTs are a continuation of the DSDT. Multiple SSDTs can be used as part of a platform description. After the DSDT is loaded into the ACPI Namespace, each secondary description table listed in the RSDT/XSDT with a unique OEM Table ID is loaded. This allows the OEM to provide the base support in one table, while adding smaller system options in other tables.

Note: Additional tables can only add data; they cannot overwrite data from previous tables.

 

To me this looks like our own PSS and CST tables override ones from SSDT tables.

[Aargh-a-Knot]

So.

 

When I did an SSDT dump in Ubuntu, it gave me 5 files. But, looking in ssdt_CpuM.aml, it says:

 

Scope (\)
{
	Name (SSDT, Package (0x18)
	{
		"CPU0IST ", 
		0x9FEE7E80, 
		0x0000022A, 
		"CPU1IST ", 
		0x9FEE8340, 
		0x00000152, 
		"CPU0CST ", 
		0x00000000, 
		0xF000E816, 
		"CPU1CST ", 
		0x00000000, 
		0xF000E816, 
		"CPU2IST ", 
		0x9FEE84A0, 
		0x00000152, 
		"CPU3IST ", 
		0x9FEE8600, 
		0x00000152, 
		"CPU2CST ", 
		0x00000000, 
		0xF000E816, 
		"CPU3CST ", 
		0x00000000, 
		0xF000E816
	})

 

Is this supposed to be a list of all the files associated with the SSDT? Because the other 4 files that I got were the 4 CPUxlst files. I did not get any CPUxCST files.

 

I want to incorporate these into my DSDT so I can use DropSSDT=Y, change the _PCT method in the manner I linked to above, and see if it will indeed enable stepping of my voltage along with the P-States. If so, I think this something to figure out. It seems some people have voltage stepping, and some don't. If we can get it working for the people who don't, I think it may shed some light on why it does not work for some. Maybe there is an easier way, but to test the concept, I'd like to add what is necessary from the SSDT with the changes suggested by AsereBLN and set DropSSDT to Y. I'm just not sure how to incorporate it into the DSDT. The examples I have seen in my searches just add the code at the end of the DSDT. OK, but here are some questions I still have:

 

1) My four CPUxlst files are all identical. They contain methods PPC, PCT, PSS, SPSS, and NPSS...

1a) Can I just add these methods the way they are, once at the end of the DSDT, and satisfy the requirements that the four CPUxlst files were fulfilling?

1b) Since PSS is again defined in these four SSDT files, but with different info than what is defined in my DSDT, could I just add this extra info to my original DSDT PSS? (The info in the SSDT PSS is 3 If/Then statements)

 

2a) Would I also need to add the content from the root dsdt file (CpuPM)?

2b) If so, do I need to change any of the info at the beginning, that seems to be stating what other files belong within the scope of the SSDT as a whole? (ie Name(SSDT) list that I posted above in this post) If this is the purpose of this block of code, and I am putting all the info in the same file, it seems that this would no longer be necessary.

 

3) If that package in Name(SSDT) is indeed referring to other files to associate with the SSDT, what about the CPUxCST files it refers to? Would I need to find these, and incorporate additional content from these, other than what I have in my DSDT's CST section? I don't know why I didn't get these when I did the dump. I will have to go back and see if I can figure out what I did wrong...

 

OK, so I thought I had a simple request, but after spelling out what it is that I need to know to try this out, it seems like a lot... If What I am trying to do does not make sense, please see HERE to better understand.

 

If anyone can answer these questions, I'd be much obliged...

[Aargh-a-Knot]

Why would using DropSSDT option be necessary. What about this statement from Acpispec:

SSDTs are a continuation of the DSDT. Multiple SSDTs can be used as part of a platform description. After the DSDT is loaded into the ACPI Namespace, each secondary description table listed in the RSDT/XSDT with a unique OEM Table ID is loaded. This allows the OEM to provide the base support in one table, while adding smaller system options in other tables.

Note: Additional tables can only add data; they cannot overwrite data from previous tables.

 

To me this looks like our own PSS and CST tables override ones from SSDT tables.

 

As the information within the PSS tables in our DSDT is different from the PSS tables in the SSDT, it is not overriding it, but rather adding to it. This is why when I tried to override the CFGD value, it had no effect.

[FKA]

That's IMHO because you don't have a Nehalem which use new / different techniques to reduce power usage. You need a Legacy kext to get it working, but the question remains if it does anything useful.

 

Indeed and indeed again!

[Master Chief]

No difference unfortunately.

Would you mind checking your RSDT table? Please post the before / after usage of DropSSDT=yes. Thanks.

 

 

Why would using DropSSDT option be necessary. What about this statement from Acpispec:

SSDTs are a continuation of the DSDT. Multiple SSDTs can be used as part of a platform description. After the DSDT is loaded into the ACPI Namespace, each secondary description table listed in the RSDT/XSDT with a unique OEM Table ID is loaded. This allows the OEM to provide the base support in one table, while adding smaller system options in other tables.

Note: Additional tables can only add data; they cannot overwrite data from previous tables.

 

To me this looks like our own PSS and CST tables override ones from SSDT tables.

No. The ACPI specification does not account for cases where you unload and replace the ACPI tables. Which is exactly what we do when using our own / modified dsdt.aml and the DropSSDT=yes parameter. I mean you cannot override anything that has been removed, because it is like Blackosx confirmed it... they are gone. In fact it appears to be more important now that I know this, because we don't want old junk flying around.

 

Good that I removed the Load () statements from the DSDT, because now we won't even have to worry about it. I mean since it isn't even loaded to start with. Some will say that the tables are loaded, at least initially. Which is true, but they are removed (unloaded) when it loads my dsdt.aml And since I don't have Load () statements anymore in my DSDT...

 

p.s. This is only true for people who don't have SSDT tables in IORegistryExplorer (with or without the DropSSDT=yes parameter) because then the Load () statements needs to be removed – these tables are not visible after load in IORegistryExplorer.

 

So.

 

When I did an SSDT dump in Ubuntu, it gave me 5 files. But, looking in ssdt_CpuM.aml, it says:

Scope (\)
{
	Name (SSDT, Package (0x18)
	{
		"CPU0IST ", 
		0x9FEE7E80, 
		0x0000022A, 
		"CPU1IST ", 
		0x9FEE8340, 
		0x00000152, 
		"CPU0CST ", 
		0x00000000, 
		0xF000E816, 
		"CPU1CST ", 
		0x00000000, 
		0xF000E816, 
		"CPU2IST ", 
		0x9FEE84A0, 
		0x00000152, 
		"CPU3IST ", 
		0x9FEE8600, 
		0x00000152, 
		"CPU2CST ", 
		0x00000000, 
		0xF000E816, 
		"CPU3CST ", 
		0x00000000, 
		0xF000E816
	})

Is this supposed to be a list of all the files associated with the SSDT? Because the other 4 files that I got were the 4 CPUxlst files. I did not get any CPUxCST files.

Yes. And you don't need any of it. Especially since there is no _CST support loaded whatsoever (using 0x00000000 - 0xF000E816 is a placebo filler only).

 

TIP: Start (re)reading from page one, instead of asking question about stuff that has been addressed a long time ago. This way you are not getting anywhere soon...

[mitch_de]

"TIP: Start (re)reading from page one, instead of asking question about stuff that has been addressed a long time ago. This way you are not getting anywhere soon..."

I agree - but in case of not reading old stuff, i would say we indeed getting somewhere : into an psychatric clinic

[blackosx]

Would you mind checking your RSDT table? Please post the before / after usage of DropSSDT=yes. Thanks.

No problems. Here they are,

RSDT_BeforeAndAfter.zip

[mitch_de]

New iaslMe dsdt disassembler/complier available (news / updates).

[Aargh-a-Knot]

TIP: Start (re)reading from page one, instead of asking question about stuff that has been addressed a long time ago. This way you are not getting anywhere soon...

 

 

Fair enough. Even I am annoyed by my questions. I understand how the things that I'm asking about would be bothersome to those of you who know more about all this than I do.

 

Could you answer me this: Is the "stuff that has been addressed a long time ago" the how to incorporate the SSDT part, or the trying to get my voltage to step with the P-States part?

 

In any case, I have learned an immense amount from reading everyone's posts here over the last few weeks, so thanks. Apparently not enough to ask the right questions however...

 

I guess I'll go back through this Dostoyevsky of a thread again, and see what I missed.

[Master Chief]

No problems. Here they are,

Brilliant. Exactly as I said; shorter. SSDT tables removed. Let's share the output with everyone else here. Here's the one without dropSSDT=yes:

[024h 0036  4]       ACPI Table Address   0 : 00C1F000
[028h 0040  4]       ACPI Table Address   1 : DFEE7E00
[02Ch 0044  4]       ACPI Table Address   2 : DFEE7E80
[030h 0048  4]       ACPI Table Address   3 : DFEE7EC0
[034h 0052  4]       ACPI Table Address   4 : DFEE7D00
[038h 0056  4]       ACPI Table Address   5 : DFEEEBA0
[03Ch 0060  4]       ACPI Table Address   6 : DFEEED30
[040h 0064  4]       ACPI Table Address   7 : DFEEEEC0
[044h 0068  4]       ACPI Table Address   8 : DFEEF050
[048h 0072  4]       ACPI Table Address   9 : DFEEF1E0

And here's the one with dropSSDT=yes

[024h 0036  4]	   ACPI Table Address   0 : 00C1F000
[028h 0040  4]	   ACPI Table Address   1 : DFEE7E00
[02Ch 0044  4]	   ACPI Table Address   2 : DFEE7E80
[030h 0048  4]	   ACPI Table Address   3 : DFEE7EC0
[034h 0052  4]	   ACPI Table Address   4 : DFEE7D00

This should cover it. And this shows me that you really should be using dropSSDT=yes Most definitely.

 

Fair enough. Even I am annoyed by my questions. I understand how the things that I'm asking about would be bothersome to those of you who know more about all this than I do.

I am not annoyed, but want to help you solve your problem. We all want that for you, but...

 

Could you answer me this: Is the "stuff that has been addressed a long time ago" the how to incorporate the SSDT part, or the trying to get my voltage to step with the P-States part?

But of course. I am not trying to be an *ss. Not at all.

 

Now. If by incorporating SSDT you mean the _PSS and _PSD object data, then yes. We've covered this already. And you don't need anything else from your SSDT. But more importantly; I am convinced that what you see in VoodooMonitor is the Intel SpeedStep Technology at work – hence the lack of voltage changes – and not the Apple kext. I've been there myself.

 

In any case, I have learned an immense amount from reading everyone's posts here over the last few weeks, so thanks. Apparently not enough to ask the right questions however...

Keep reading and we'll keep trying to help you. And even I as you see, but it would be nice when you listen, read what I said earlier and follow directions because again... your P-States are NOT working. Not yet that is.

 

Now let's see what you are using: A Gigabyte EP45-UD3P with a Intel Q6600 Nothing special. No offense. Most definitely in use by others here so it can be done. You might want to ask (but search first / check signatures) for a working DSDT in the DSDT fixed for GigaByte boards thread. This way you can skip a few parts. Make it work without too much hassle.

 

p.s. Aussie Aussie Aussie, Oi Oi Oi keeza is using the same board (see his signature) and his DSDT can be found in the: "DSDT fixes for GigaByte boards" thread!

[mm67]

No. The ACPI specification does not account for cases where you unload and replace the ACPI tables. Which is exactly what we do when using our own / modified dsdt.aml and the DropSSDT=yes parameter. I mean you cannot override anything that has been removed, because it is like Blackosx confirmed it... they are gone. In fact it appears to be more important now that I know this, because we don't want old junk flying around.

 

Putting something into DSDT actually does override SSDT. It is very easy to check this on my MSI board which has speedstepping working out of the box, as in no modifications to DSDT. Factory IST table has 5 P-states defined and that is what PerformanceStateArray in IORegistryExlorer also shows. If I add a 2-state PSS table to DSDT and don't use DropSSDT=y option then IORegistryExplorer shows that I only have 2 P-states and VoodooMonitor also shows only 2 voltage values being used.

[keeza]

p.s. Aussie Aussie Aussie, Oi Oi Oi keeza is using the same board (see his signature) and his DSDT can be found in the: "DSDT fixes for GigaByte boards" thread!

 

Lyrical Geniuses us Aussies eh?

 

I'm working on some additions at the mo to my dsdt so the one MC refers to in the Gigabyte thread is probably a bit behind, mm67 has one going, you can download it Here I'm sure he won't mind. He, like me has a Q9550.

[Aargh-a-Knot]

You might want to ask (but search first / check signatures) for a working DSDT in the DSDT fixed for GigaByte boards thread. This way you can skip a few parts. Make it work without too much hassle.

 

 

Whoa there Chief. No need to throw the baby out with the bathwater...

 

As I'm about to explain, that is precisely what got me into this mess to begin with.

 

I've worked really hard making my DSDT specific to my setup, the last thing I want to do is try to use some random person's DSDT off of this forum. (No offense keeza, I'm sure your's is a fine one) My DSDT is based on mm67's model, and I have done a thorough comparison of his original to mine, and made the changes for my hardware. I have been following along with everyone else here the last few weeks, making the relevant patches.

 

The one section that I didn't get the values for myself, turned out to be the problem. I had downloaded someone's DSDT a while back, who also has the UD3P/Q6600 combo. He said everything was working, and that you had helped him with it. This was the first DSDT that I had working with any manner of Speedstepping at all, but I didn't quite understand it enough at that time to see that my P-States were actually only half working. Well, when I started over from mm67's model, I just plugged those same PSS values in to my new DSDT. This turned out to be the culprit, because after getting the FID and VID values myself using PStateChanger, I suddenly see my voltage stepping along with the frequency and multiplier.

 

So, I am sorry to have run in here with my {censored} on fire asking about merging my SSDT into my DSDT. I should have checked those values first. When I first noticed that my voltage wasn't stepping and I saw in the ACPI specs that it probably should be, I started looking around to see if this was normal. I came across a post by AsereBLN, in which he described having to edit his SSDT in order for the voltage to properly step, so I just assumed that this was something that I also needed to do. Hence why I came into this thread asking what I was asking.

 

An interesting note: after replacing my PSS values, I did see my voltage stepping, but now noticed that the frequency was not changing... WTF? I thought about it, and seeing that _PSS in the SSDT is pulling the frequency values from NPSS, I remembered that I had set DropSSDT=Y, so how is it going to get those values if the table is not being loaded? Sure enough, setting DropSSDT to N gives me 100% working P-States.

 

The lessons I've learned here?

~Don't trust someone else's FID and VID values just because they have the same CPU as you.

~Make sure you really don't need any of the tables in the SSDT before using DropSSDT=y

~Take a deep breath and think a few moments before running in the room with your {censored} on fire screaming OMG! OMG! People will assume you are a complete idiot and treat you that way.

 

Sorry to have clogged up this thread with so much useless speculation. I did learn from the experience, and so consider it a successful outcome. Hopefully, there is something here for others to learn as well?

[Master Chief]

Putting something into DSDT actually does override SSDT. It is very easy to check this on my MSI board which has speedstepping working out of the box, as in no modifications to DSDT. Factory IST table has 5 P-states defined and that is what PerformanceStateArray in IORegistryExlorer also shows. If I add a 2-state PSS table to DSDT and don't use DropSSDT=y option then IORegistryExplorer shows that I only have 2 P-states and VoodooMonitor also shows only 2 voltage values being used.

Yes we can override things in SSDT. Like we do for so long for our custom _PSS and _CST objects. Nothing new here. However. You have to load the tables first. Otherwise you are defining things like object and other data. Not overriding them!

 

There are two possible scenarios: 1) The SSDT tables are loaded because they appear in the RSDT entries or 2) they are loaded at ACPI CA runtime with help of Load () statements (for blackosx 1 and for me 2).

 

And you either see SSDT tables in IORegistryExplorer or not. The latter case doesn't necessarily mean that you don't have SSDT tables. Just that you don't see them. They simply don't show up after Load (). Weird but true.

 

Also. There are different types of SSDT tables, like the onces related to P-States and others to C-States. Just to name two examples because there can also be tables related to SATA et all. And most people here call the P-States tables IST tables and the onces for C-States CST tables. Neither one might be correctly named, but that's what is used here.

 

Some DSDT's use a chain loader (CPUPM) to load other tables – I am referring to the MatthewL case here, for which I wrote a little _INI method to load his other tables. And for most people Load () statements were used to load the IST / CST tables. Which we removed some time ago. And not loading SSDT tables would simply mean that they have to define things like _PSS objects. Not that they are overriding anything.

 

Working P-States out of the box is nice, but the question remains: How is it implemented? Presumably by utilizing your IST tables. Or just the DSDT. Most likely not by using so called CST tables and thus: Is your factory DSDT using Load () statements or are the (all) tables part of your RSDT table? In your case probably RSDT since you removed (?) all Load statements. Am I correct? That would at least explain why it works without modifications. Do you see voltage changes also> I mean without any modification whatsoever related to _PSS and the like?

 

Now back to our case: The factory DSDT gets replaced with our custom one. Using DropSSDT=yes will cause that the SSDT tables are unloaded and remove from the RSDT table (clearly visible in the dump provided by blackosx) and the next step is that ACPI is re-initialized. At this point there isn't any SSDT table data left to work with.

 

Only people with SSDT tables in IORegistryExplorer who are not using DropSSDT=yes have SSDT tables. Other people won't, becase we removedthe Load () statements, and thus cannot override stuff in SDDT tables anymore.

 

Your case might be (slightly) different, but I doubt it. And since we worked hard to reduce the (file) size of our DSDTs. By ripping unused parts... why shouldn't people do the same for SSDT tables?

 

@Aargh-a-Knot: What is wrong about learning by example? I mean looking at other peoples (working) DSDT's is a great way to learn new things and to locate errors. Even if it the DSDT is for a completely different board. It's still ACPI code...

 

And apparently I was right all the time – your P-States didn't work. I'm also still convinced that you don't need SSDT tables. Let's rule out errors. Please attach your complete ACPI dump so that we can have a look at it. Me might be missing something important here.

[mm67]

Yes we can override things in SSDT. Like we do for so long for our custom _PSS and _CST objects. Nothing new here. However. You have to load the tables first. Otherwise you are defining things. Things like object and other data. Not overriding them!

 

There are two possible scenarios: 1) The SSDT tables are loaded because they appear in the RSDT entries or 2) they are loaded at ACPI CA runtime with help of Load () statements (for blackosx 1 and for me 2).

 

And you either see SSDT tables in IORegistryExplorer or not. The latter case doesn't mean that you don't have SSDT tables, just that you don't see them. They simply don't show up after Load (). Weird but true.

 

Also, there are different types of SSDT tables, like the onces related to P-States and others to C-States. Just to name two examples because there can also be tables related to SATA et all. And most people here call the P-States tables IST tables and the onces for C-States CST tables. Neither one might be correctly named, but that's what is used here.

 

Some DSDT's use a chain loader (CPUPM) to load other tables – I am referring to the MatthewL case here, for which I wrote a little _INI method to load his other tables. And for most people Load () statements were used to load the IST / CST tables, and thus not loading these tables would simply mean that they have to define things like _PSS objects. Not that they are overriding anything.

 

Working P-States out of the box is nice, but the question remains: How is it implemented? Presumably by utilizing your IST tables. Or just the DSDT. Most likely not by using so called CST tables and thus: Is your factory DSDT using Load () statements or are the (all) tables part of your RSDT table? In your case probably RSDT since you removed (?) all Load statements. Am I correct? That would at least explain why it works without modifications. You see voltage changes also, without any modification whatsoever related to _PSS and the like?

 

When you see SSDT tables in IORegistryExplorer, then you can unload them with DropSSDT=yes. Which has been clearly demonstrated by the output of blackosx. And since his tables have been removed, are no longer there, then he cannot override anything in them anymore. He then starts to define things. And from scratch. What else is the point of removing these tables?

 

Now back to our original case: The factory DSDT gets replaced with our custom one. Using DropSSDT=yes will cause that the SSDT tables are unloaded and remove from your RSDT table. Which in turn is clearly visible in the dump provided by blackosx. And then ACPI is re-initialized.

 

And since most people here no longer have Load () statement in their DSDT, they are not overriding anything, but defining things like _PSS objects. Only people with SSDT tables in IORegistryExplorer or people who are still using Load () statements can override stuff in SDDT tables. The rest of don't have SSDT tables anymore.

 

Your case might be different, but the pizza arrived so food first....

 

Here is a full acpidump of my MSI board, I am running this without any modifications to factory powermanagement.

ACPI.zip

[Master Chief]

Here is a full acpidump of my MSI board, I am running this without any modifications to factory powermanagement.

ACPI.zip

Thanks. I'll check it right after this reply. I wonder what I am missing here...

 

Edit: Remarkably well written. Using the chain load technique I described (from CpuPm) to load your SSDT tables. Possibly BIOS driven setting (looking at: CFGD 0x0020BCF2) to prevent table loading. In that case you won't ever need to specify DropSSDT=yes I am jealous!

[FKA]

The lessons I've learned here?

~Don't trust someone else's FID and VID values just because they have the same CPU as you.

~Make sure you really don't need any of the tables in the SSDT before using DropSSDT=y

~Take a deep breath and think a few moments before running in the room with your {censored} on fire screaming OMG! OMG! People will assume you are a complete idiot and treat you that way.

 

You make me laugh Aargh

 

~Don't trust someone else's FID and VID values just because they have the same CPU as you.

Of course they may well be overclocked - even if you are too it may not be to same level!

~Make sure you really don't need any of the tables in the SSDT before using DropSSDT=y

The orgional method I'd used involved adding all of the SSDT tables to DSDT so using DropDSDT=y meant you wouldn't miss anything! I know this discusion is ongoing .....

~Take a deep breath and think a few moments before running in the room with your {censored} on fire screaming OMG! OMG! People will assume you are a complete idiot and treat you that way.

LMAO - i do it all the time!

 

D

[mm67]

Thanks. I'll check it right after this reply. I wonder what I am missing here...

 

I am only saying that DropSSDT option doesn't seem very important to me. If I define something in DSDT then that is what is used, like if I define a PSS table in DSDT then it doesn't matter what kind of table SSDT has. Mostly useless, but I could for example make a 10-state PSS table for my MSI board and leave everything else to factory settings.

[Master Chief]

Lyrical Geniuses us Aussies eh?

A great cheer indeed. And good to see you back!

[Master Chief]

I am only saying that DropSSDT option doesn't seem very important to me. If I define something in DSDT then that is what is used, like if I define a PSS table in DSDT then it doesn't matter what kind of table SSDT has. Mostly useless, but I could for example make a 10-state PSS table for my MSI board and leave everything else to factory settings.

Clear. I also agree with you about the SSDT tables... most of it is not used in OS X. This is also exactly why I want people to use the DropSSDT option. To get rid of it. This way we can be certain that people are using the newly added code (from their DSDT). Without intervention of some unknown ACPI code. A fully independent solution, without intervention of BIOS settings so to speak.

 

I mean what if Aargh-a-Knot is right, and people here are indeed still using 'something' from (one of) their SSDT tables? That would be news to me and thus I have to find it out. Annoying maybe, but true.

[mm67]

Edit: Remarkably well written. Using the chain load technique I described (from CpuPm) to load your SSDT tables. Possibly BIOS driven setting (looking at: CFGD 0x0020BCF2) to prevent table loading. In that case you won't ever need to specify DropSSDT=yes I am jealous!

 

Same sees to apply to all newer MSI boards, no need to mess with powermanagement and Ehci devices. I won't anymore even consider a Gigabyte board.

[FKA]

I am only saying that DropSSDT option doesn't seem very important to me. If I define something in DSDT then that is what is used, like if I define a PSS table in DSDT then it doesn't matter what kind of table SSDT has. Mostly useless, but I could for example make a 10-state PSS table for my MSI board and leave everything else to factory settings.

 

With the Scope (_PR) I'm using - operationally it also makes absolutly no difference to me if I use DropSSDt=y or =N

 

D

 

mm67 - this is dump is from MSI P45 Neo??

[Master Chief]

With the Scope (_PR) I'm using - operationally it also makes absolutly no difference to me if I use DropSSDt=y or =N

 

D

Me neither. Might only be handy for people with SSDT tables in IORegistryExplorer. Making me wonder even more about Aargh-a-Knot's case.

[keypox]

i can't get pstatechanger to display my pstates. Do I have to use kext helper or something to install voodoopstate? Or can i just place in E/E? I put it in E/E and its not working... but i dont want ot isntall it with kext helper, cause i dont know how ot get rid of it later that way lol.