Some questions about DSDT patching and strange conflict with PS/2 mouse and AHCI on Rampage II Extreme

[Guest]

Hello all,

 

I tried to install Snow Leopard (retail) on the following configuration:

- Core i7 920 (stock freq)

- Asus Rampage II Extreme (bios 1639 - latest one)

 

...and just for info, I have some knowledges about system programming, but mostly under Linux. I don't claim to be an ACPI expert, but I also don't think being a total noob here .

 

 

Let me first explain you my experiments:

 

I have had a previous successful install of Leopard (using iAKTOS 7) with a DSDT.aml file that has been provided on their forum for bios 1504. As I was not so experienced with DSDT patching at this time, and as it was somehow working fine, everything was OK so far At that time, I was using Chameleon 1 as bootloader, w/o any specific smbios injections or boot directives.

 

Then I tried to install snow on a external USB drive to see how it was reacting. My installation was the following:

- Chameleon 2.0 RC4

- smbios.plist set to MacPro4,1 as model (attached)

- the only additional kexts where fakesmc and NullCPUPowerManagement, both in the Extra subfolder.

 

I then copied the DSDT.aml for the 1504 bios that I have had in the extra directory, and tried to boot...

- With Leopard, the boot itself was taking ~20sec. In this case, more than 2min.

- Some SATA drives where missing

- All of then got the orange icon (seems to be normal, as I did not use the IOAHCIBlockInjector kext)

 

First question here: Is this OK to use a DSDT.aml file created from another BIOS, or should I re-created one everytime I flash the MB with another BIOS revision ?

 

 

Then I decided to remove the DSDT.aml and try to boot without, to get a clean one, using fassl's DSDT patcher and compare, to get a clue what was wrong. More or less the same. So no issue there (attached as dsdt_extreme_untouched).

 

I then unplugged all my SATA devices and booted. Everything run fine this time! So I said to myself, there must be something wrong with the SATA part of the DSDT. As I am not an expert in this topic I was more experimenting than really knowing what I was doing there... but all the time with no luck.

 

I then googled (mainly here) to see if some have had some issue. I found the Rampage II Gene topic from dgsga (http://www.insanelymac.com/forum/index.php?showtopic=201758), downloaded the DSDT.dsl (attached), compiled it using the lasted iasl compiler (20091214) and booted with... Guess what, problem fixed. Yeah, I know this is bad, but as the Rampage II Gene is more or less a Rampage II Extreme "light" this wasn't too risky. (NB: The file attached is slightly different from the one on the topic, as I took the liberty to add THeKing's slow SATA fix).

 

 

Now the DSDT.dsl specific questions:

 

After diffing the Gene DSDT and the clean one for my board, I found out some major differences:

• Both PR01 and AR01 have 1 more item
  
• I did not care about the ESI and HDEF device as I have disabled the HD Audio sound card
  
• The LPCB (named SBRG) was a little bit different.
  
• PS/2 devices and related methods (SIOH and _L1D) were not in the Gene DSDT.dsl
  
• Some hex values slightly differs in the CUPI and UMVS methods
  
• Some _DSM methods were added for devices (mainly USB)
  
• The SATA device was completly different (The one in the Gene seems to be based on the MacPro4,1 one)
  
• An SBUS method was added
  
• Some additional "sensors" (temp, voltage etc...) were not present in the Gene DSDT. I guess there are simply not present on the board itself...
  
• and finaly the _PTS and _WAK methods were lots more complicated in the Rampage DSDT
  

 

After checking theses differences one by one, I found out that it was the PS/2 mouse methods that was the root of the issues. I checked the IRQ for the AHCI controller (looking at THeKiNG's post in http://www.insanelymac.com/forum/index.php...p;#entry1265443 both screenshots are attached) and attached the result with and w/o PS/2 mouse support (named dsdt_extreme_patched.dsl).

 

The DSDT.dsl file that I found working, disabling the PS2M device (I know it is not (yet) optimized, but I like to know what I am doing is also attached. The changes that I have done:

• Eliminating any warning or remarks from the iasl compiler
  
• Adding THeKiNG's slow SATA fix
  
• Renaming the devices as much as possible to stick to the MacPro4,1 naming scheme
  
• Adding Darwin recogintion in the OSYS method
  
• Changed the OEMID and OEM table ID in the DefinitionBlock signature (also to stick with MacPro4,1)
  
• Commented out everything related to the PS/2 mouse.
  

 

And finally, I remoed the NullCPUPowerManagement.kext, as I saw in some topics that when you have the right devices naming, the AppleCPUPowerManagement does not KP anymore (which is the case by the way). Some other thing to mention, is that with the attached DSDT, sleep seems to work correctly out of the box... but fails if NullCPUPowerManagment kext is loaded. I guess this is normal...

 

Now the questionS:

• Why is a DSDT.aml file working with Leopard and failing with Snow? Am I missing some kexts, or is it just because the mach kernel handles devices differently?
  
• What is exactly the problem with the PS/2 mouse? I suspect a shared IRQ, but I am definitly not 100% sure
  
• What are exactly the PR01 and AR01 packages? Is this some king of PCI bus descriptors ?
  
• I saw in some topics that the device naming is important. Is this only related to the AppleCPUPowerManagement kext or has it more deeper implications ?
  
• Is the SATA device replacement done in the Gene DSDT somehow "safe"... I mean, are there no side effects? Once again, I am not an expert here, so I cannot even check what are the real differences.
  
• I guess the _DSM methods are to spoof the device IDs and make them recognized as apple ones?
  
• What is the SBUS device good for? Is this just to stick once again to MacPro4,1 ?
  
• The PutInSleep and WakeUp methods are rather simple in the Gene DSDT. As the "complicated" ones that I got in the original ones seems to work also, is it really a good idea to replaced them with the Gene ones ?
  

 

If you are still reading this, I really thank you and appriciate that I really would like to get to know this DSDT stuff a little bit more, and would be gratefull if some of the local experts could answer the above questions and/or give me some hints on how to continue optimizations on the dsl file.

 

I have read the post for the P5K (or P5Q I don't remeber...) in which Master Chief is doing an amazing job, but I have to admit that sometimes, the reasons of the modifications he is making are a little bit obscure for me

 

Thanks in advance!

M.

smbios.plist.zip

dsdt_rampage_gene.dsl.zip

dsdt_extreme_untouched.dsl.zip

dsdt_extreme_patched.dsl.zip

[Guest]

Regarding the PS/2 mouse port issue, I am a little bit puzzled: The motherboard has only 1 PS/2 port on the rear panel connector. This connector is purple, so I guess it is a "keyboard only" connector.

 

Quoting the Asus manual:

PS/2 keyboard port (purple). This port is for a PS/2 keyboard.

 

But in some tests they are saying something different:

http://www.tweaktown.com/reviews/1662/asus...ard/index4.html

Turning our attention to the rear I/O ports, ASUS has a fantastic layout and design. Of note here, there is only one PS/2 port, but it has a half purple and half green colour scheme. This is a dual purpose port; if you have a PS/2 mouse, you can run it off the PS/2 port and run the keyboard off the USB, or vice versa. If you have both a PS/2 keyboard and mouse, you’re stuffed here; it’s time to pick up a USB mouse/keyboard.

 

I would definitly favor what is mentioned in the Asus motherboard... and this would be a possible explanation why it is causing problems... But then:

- why the PS2M device appears in the DSDT ?

- why with the same DSDT.aml file, leopard is working properly (all AHCI drives detected correctly) ?

[Detrich]

Hi mathf

 

ASUS use the same code for all it's mobo's, there are just differences in APIC tables(AR00, AR01...) and some minor cosmetics. Apple doesn't use PS/2 anymore, so to avoid conflicts, take an USB kb.

 

I'm going to edit your DSDT, but I also need your complete IOReg (w/o DSDT) and also your CPU _PSS state code

 

D.

[Guest]

Hi Detrich,

 

Thanks a lot for your time, but I would like to take the opportunity to learn all the stuff by myself I am a software dev. and I have to admit that it absolutly don't bother me to spend hours patching and investigating in order to know how my computer is internally working

 

I was even thinking about starting a thread, in which I would describe my steps, and also my learnings, to be somehow a mickey-mouse guide for DSDT patching. As for many developers, I really like to know the impact of any code change before applying it, so I sometimes ask A LOT of questions

 

 

For the PS/2 keyboard and mouse, I am not using any of this outdated devices anymore. I was just astonished to find code for bots PS2K and PS2M inside the original DSDT (which as far as I understood comes directly from the BIOS itself... confirmed by the fact that the /proc/acpi/dsdt is 100% similar under Linux).

-> As stated above, the Mobo has only 1 purple PS/2 port. And even under Windows, connecting a PS/2 mouse on it has no effect, except producing weird sounds in the internal speaker

 

I simply disabled the PS2M code related, recompiled, and tested the port with a PS/2 keyboard (after installing VoodooPS2 drivers of course, which IMHO is normal, as apple don't use PS/2 anymore, so I guess no native drivers are in SL) -> Works like a charm!

 

 

Regarding the CPU _PSS, I guess this is something relating to native SpeedStep support thru AppleIntelCPUPowerManagement right ?

 

M.

[Detrich]

Regarding the CPU _PSS, I guess this is something relating to native SpeedStep support thru AppleIntelCPUPowerManagement right ?

 

Yes, and it's most confused part of CPU section. Also about 90% of DSDT code on real macs is for Windows/Linux only, to use through bootcamp, PC users already have a BIOS, so we can strip this biggest part (my working DSDT is aprox 2Kb instead of 36Kb ...

 

PS: If you want to do it yourself, it will take alot of time, for me, for example, it has taken about 4 months of testing.

 

Happy Hacking!

[Guest]

Yes, and it's most confused part of CPU section. Also about 90% of DSDT code on real macs is for Windows/Linux only, to use through bootcamp, PC users already have a BIOS, so we can strip this biggest part (my working DSDT is aprox 2Kb instead of 36Kb ...

 

Regarding the SpeedStep, I saw a lot of topics quite detailed covering this. As far as quickly understood, you have to add _PSS and _CST method for each of your CPU device inside the _PR scope. And to be able to do this properly you have to define your C-State by hand, and these are always specific to your model. Mine is an i7 920, so quite common.

 

BtW, I am using different O.C. profiles depending on the "stuff" I am doing (I am basically overclocking only for playing games... but also sometimes when I compile a bunch of source code). Correct me if I am wrong, but I think I will have to have different P-States for each freq no ?

 

 

PS: If you want to do it yourself, it will take alot of time, for me, for example, it has taken about 4 months of testing.

 

Happy Hacking!

 

Don't get me wrong, I am not rejecting your help... Just that I would get a little bit frustrated to get a fully-working-dsdt without having to spend some nights of hacking But feel free to take a look to the one attached, and give me your hints.

 

Also I am currently reading the complete thread on the P5K Pro, checking the diff between each DSDT revision, and adapting them to mine. So I am currently learning really a lot every evening, and I have to say that I enjoy hacking nights

 

 

As stated in the original post, I still have questions (green highlighted) for which I didn't see a clean answer (I mean a clear 'yes' or 'no', and not a 'it depends' ).

-> One of them regards the (SATA) and (SAT1) devices inside the original DSDT. First of all, the Gene modified DSDT looks really like a copy-paste of the real MacPro4,1 one plus devices added for every connected hardware. Also, (SAT1) is not present anymore... is this (SAT1) comparable to the PS2 mouse? Present in the BIOS, but not physically on the board... I mean a second SATA controller?

[Detrich]

First question here: Is this OK to use a DSDT.aml file created from another BIOS, or should I re-created one everytime I flash the MB with another BIOS revision ?

 

Ok, to be clear, generally with every BIOS update, there are added support for new CPUs, this means, that ACPI table will be modified and this is very important, so, in our case, we should compare old APIC Resources (AR00,AR01...) with new one(I moved my APIC section on different scop, to be easely to find). Also, chek, if FACS Address hasn't changed.

 

-> One of them regards the (SATA) and (SAT1) devices inside the original DSDT. First of all, the Gene modified DSDT looks really like a copy-paste of the real MacPro4,1 one plus devices added for every connected hardware. Also, (SAT1) is not present anymore... is this (SAT1) comparable to the PS2 mouse? Present in the BIOS, but not physically on the board... I mean a second SATA controller?

 

Yes,SAT1 is refered to second ICH port(in my case, I have it) , if it's not present in IORegistryExplorer, you can remove it from DSDT.

 

Also I am currently reading the complete thread on the P5K Pro, checking the diff between each DSDT revision, and adapting them to mine. So I am currently learning really a lot every evening, and I have to say that I enjoy hacking nights

MC does a good job, also look on gigabyte thread.

 

Regarding the SpeedStep, I saw a lot of topics quite detailed covering this. As far as quickly understood, you have to add _PSS and _CST method for each of your CPU device inside the _PR scope. And to be able to do this properly you have to define your C-State by hand, and these are always specific to your model. Mine is an i7 920, so quite common.

 

_CST, by default, should be common for all Intel CPUs(check original MAC dumps). Just _PSS is specific to your model(VID/FID, check also Win7 power manegement section).

 

D.

[Guest]

First of all, thanks for all your explanations.... Regarding upgrading the DSDT when flashing a newer BIOS, this confirms what I was suspecting. So the following would normally work:

• keep an untouched version of the BIOS dsdt.dsl for previous revision
  
• get the new BIOS dsdt.dsl
  
• track the diffs... I guess a simple diff dsdt.old.dsl dsdt.new.dsl will do the job
  
• backport all the changes and additions to the optimized dsdt.dsl that I am currently building
  

If I miss something, feel free to comment

 

 

SATA and SAT1 devices

 

Regarding the SATA and SAT1 devices, I have a got this inside the ICH10 datasheet PDF (Section 5.16, page 176):

The SATA function in the ICH10 has three modes of operation to support different operating system conditions. In the case of Native IDE enabled operating systems, the ICH10 utilizes two controllers to enable all six ports of the bus. The first controller (Device 31: Function 2) supports ports 0–3 and the second controller (Device 31: Function 5) supports ports 4 and 5. When using a legacy operating system, only one controller (Device 31: Function 2) is available that supports ports 0 - 3. In AHCI or RAID mode, only one controller (Device 31: Function 2) is used enabling all six ports.

 

Correspond to SATA (0x001F0002) for the first controller, and SAT1 (0x001F0003) for the second. I guess that real Apple devices does not let you configure the SATA function of the ICH10, and puts it by default in AHCI. That's why SAT1 (or any other device name with the address) 0x001F0003 is not part of the MacPro DSDT.

-> Sounds completely acceptable, as according to section 5.16.1, most SATA features are disabled if IDE is selected.

 

So yes, SAT1 does not appear in my IORegistryEditor, as my SATA is configured in AHCI. I will play a little bit around with the BIOS settings tomorrow (as it is now 2.30 AM here ) and see what happens when I put my SATA controller to IDE. I guess in this case I will see SAT1 poping up, controlling the 2 last SATA ports (I don't risk so much by doing this, as SL is currently on an external USB HDD).

 

 

 

Now a question that will sound reallly stupid:

 

I have this USB5 device in my DSDT. As far as I see from the ICH10 pdf, it has the address 0x001D0003 (D29, F3), so this is the "famous" invisible port. Master Chief stated here (post 55) that it is unused in the default 6+6 config. Totally agree on that for the ICH10 also (see 5.19.8.1). But it is definitly used in the "8+4" configuration

 

As stated in the datasheet (5.19.8),

D26:F2 can be configured as D29:F3 during BIOS post.

 

So the question is, under which circumstances might this reconfiguration occur. There is no BIOS setting to specify the 6+6 or 8+4, so I guess this might be some internal BIOS logic no? The aim for this question is simple... If I comment out like MC has done, I might miss 2 USB ports IF for one reason or another the port is switch during POST, right ?

 

 

 

Again, thanks for your help! I found it really..... aheum.... helpful

M.

[Detrich]

Correspond to SATA (0x001F0002) for the first controller, and SAT1 (0x001F0003) for the second. I guess that real Apple devices does not let you configure the SATA function of the ICH10, and puts it by default in AHCI. That's why SAT1 (or any other device name with the address) 0x001F0003 is not part of the MacPro DSDT.

-> Sounds completely acceptable, as according to section 5.16.1, most SATA features are disabled if IDE is selected.

 

Apple already have a support for SATA in IDE mode(AppleIntelPIIXATA.kext) but for 1st port only (0–3 in your case) and ICH9,ICH10,... are not suported anymore. To make all ports working in IDE we'll need a patched one(check DuNe's thread).

 

I have this USB5 device in my DSDT. As far as I see from the ICH10 pdf, it has the address 0x001D0003 (D29, F3), so this is the "famous" invisible port. Master Chief stated here (post 55) that it is unused in the default 6+6 config. Totally agree on that for the ICH10 also (see 5.19.8.1). But it is definitly used in the "8+4" configuration

 

USB5 or USB3(USB1112 in my case) are real internal connectors and not used by default, are used to connect additional USB module, purchased separately. Apple don't have this one. But,if you want to use it, in IOReg will apear as a Hub under 0x001D0003 adress.

 

I was suspecting. So the following would normally work:

keep an untouched version of the BIOS dsdt.dsl for previous revision

get the new BIOS dsdt.dsl

track the diffs... I guess a simple diff dsdt.old.dsl dsdt.new.dsl will do the job

backport all the changes and additions to the optimized dsdt.dsl that I am currently building

 

With next BIOS update, you should see additional parts under AR00 .

 

PS: Could u share your full IOReg dump?

[Guest]

USB5 or USB3(USB1112 in my case) are real internal connectors and not used by default, are used to connect additional USB module, purchased separately. Apple don't have this one. But,if you want to use it, in IOReg will apear as a Hub under 0x001D0003 adress.

 

You mean USB port plugs on the Mobo ? I have all twelve ports running (using front panel from my case (2 connectors, so 4 ports) and also a backplate with 2 additional ports that takes the last connector on the mobo. I definitly don't have anything under the 0x001D0003 address.

 

 

PS: Could u share your full IOReg dump?

 

I will as soon as I get back home

[Detrich]

You mean USB port plugs on the Mobo ? I have all twelve ports running (using front panel from my case (2 connectors, so 4 ports) and also a backplate with 2 additional ports that takes the last connector on the mobo. I definitly don't have anything under the 0x001D0003 address.

Hmm, sorry, seems, we really have F0/F1/F2, according to table 16-2, F3(0x001D0003) remains as reserved...

[Guest]

Hmm, sorry, seems, we really have F0/F1/F2, according to table 16-2, F3(0x001D0003) remains as reserved...

 

Sorry, but I don't get you here... The question is, when is this "Eight plus Four" configuration enabled? I know this 0x001D0003 is not appearing in my ioreg, but it is cleary stated in the datasheet, that it is upon the BIOS Post to decide if it will use it or not.

 

 

PS: I have attached my ioreg dump. I hope this is what you wanted

dump.ioreg.zip

[Detrich]

Sorry, but I don't get you here... The question is, when is this "Eight plus Four" configuration enabled? I know this 0x001D0003 is not appearing in my ioreg, but it is cleary stated in the datasheet, that it is upon the BIOS Post to decide if it will use it or not.

 

About "Eight plus Four" MC wasn't correct imho, D26:F2 can be configured as D29:F3 during BIOS post by SYSTEM not by USER, read PCI Configuration Map p.295 for this subjective answer

 

PS: I have attached my ioreg dump. I hope this is what you wanted

 

Already got it, I'll look on it later

[Guest]

About "Eight plus Four" MC wasn't correct imho, D26:F2 can be configured as D29:F3 during BIOS post by SYSTEM not by USER, read PCI Configuration Map p.295 for this subjective answer

 

So, I think we share the same opinion about it: Keep it in the DSDT right ?

[Detrich]

So, I think we share the same opinion about it: Keep it in the DSDT right ?

 

For SL, it's not necessary.

 

OK, here is ur striped DSDT, don't forget to add Performance System States part _PSS) in (_PR) scop. Should work for any actual i-series CPUs.

 

D.

[Detrich]

Hi, mathf

 

I've made some fixes for RTC(changed to UTC and will not cause KP at boot), AHCI(removed orange icons), Device Localization(will improve better speed at start-up), fireware hot-plug(not tested), also added jMicron ID for native support(x32 only. because apple don't have x64 kext yet) and WakeUp Remote(_PRW) for some devices.

 

Tell me, if it works for you.

 

D.

Rampage_II_Extreme_DSDT_RTC_Fix.zip

[mussonero]

hi

 

i would like to join you regarding this motherboard and DSDT. i have tried Detrich Last DSDT and it seems work fin under leopard and snow as well .

[Thursdayy]

Hi, mathf

 

I've made some fixes for RTC(changed to UTC and will not cause KP at boot), AHCI(removed orange icons), Device Localization(will improve better speed at start-up), fireware hot-plug(not tested), also added jMicron ID for native support(x32 only. because apple don't have x64 kext yet) and WakeUp Remote(_PRW) for some devices.

 

Tell me, if it works for you.

 

D.

 

I have the same motherboard and installed SL onto a 1TB hd. The only thing I dont use/have is the dsdt and plist. Are these files unique for each config? I have everything working except my Black Magic Intensity Pro which utilizes a PCI-Express x1 Lane. For some reason, my registry info says no PCI cards have been installed. I have already installed the drivers from the blackmagic-design.com/support but I'm wondering if the PCI is not working because I need a dsdt and plist file?

[Detrich]

I have the same motherboard and installed SL onto a 1TB hd. The only thing I dont use/have is the dsdt and plist. Are these files unique for each config? I have everything working except my Black Magic Intensity Pro which utilizes a PCI-Express x1 Lane. For some reason, my registry info says no PCI cards have been installed. I have already installed the drivers from the blackmagic-design.com/support but I'm wondering if the PCI is not working because I need a dsdt and plist file?

 

Thursdayy

 

This DSDT should work for you as well. About Black Magic, I think you'll need to enable it in BIOS, read mobo's manual about PCI Express x1 configuration.

[Thursdayy]

Thursdayy

 

This DSDT should work for you as well. About Black Magic, I think you'll need to enable it in BIOS, read mobo's manual about PCI Express x1 configuration.

 

Normally, under Linux and Windows 7, I did not have to go into the BIOS and set the PCI Cards. I will try using that DSDT you have posted earlier later tonight.

 

What happens is that I turn on Snow Leopard. I go to the Apple Icon -> About This Mac. Then I hit something similar to More Info... which brings up something similar to device driver in Window. When I go to PCI Cards, it says "NO PCI CARDS INSTALLED".

 

This happen when Ethernet and Audio were not working. IT would say "No Ethernet adapter has been installed" The fix around those two were kexts obviously. That is why I think it has something to do with maybe plist or dsdt because that is the only two things I dont have in my root directory.

[Thursdayy]

Normally, under Linux and Windows 7, I did not have to go into the BIOS and set the PCI Cards. I will try using that DSDT you have posted earlier later tonight.

 

What happens is that I turn on Snow Leopard. I go to the Apple Icon -> About This Mac. Then I hit something similar to More Info... which brings up something similar to device driver in Window. When I go to PCI Cards, it says "NO PCI CARDS INSTALLED".

 

This happen when Ethernet and Audio were not working. IT would say "No Ethernet adapter has been installed" The fix around those two were kexts obviously. That is why I think it has something to do with maybe plist or dsdt because that is the only two things I dont have in my root directory.

I got home and screwed around with the BIOS. No go, it still says "No PCI cards have been installed". I also copied your dsdt rtc fixed file and placed it in root ( / ). I am still unable to get my Black Magic Intensity Pro to work. I know it works because it works under Linux and Windows fine, just not the hackintosh set up.

[Detrich]

Thursdayy

 

DSDT should be in Extra folder...

 

Now, can you upload your IORegistry dump? I want to see what's happen.

 

PS: My Audiophile192 also have "NO PCI CARDS INSTALLED", but is fully working.

[Thursdayy]

Thursdayy

 

DSDT should be in Extra folder...

 

Now, can you upload your IORegistry dump? I want to see what's happen.

 

PS: My Audiophile192 also have "NO PCI CARDS INSTALLED", but is fully working.

I had a feeling that it should of stayed in the /Extra folder. I tried both /Extra and / . Neither worked. Now that you told me it stays there, I put it in there, and it still not working.

 

Attached is my IORegistry.

 

Also to explain to you my hardware set-up:

Motherboard: Asus Rampage II Extreme

CPU: Intel Core i7 920

RAM: 12GB DDR3 1066mhz

HD: 1TB (where snow leopard resides)

HD: 750GB (where media files reside, NTFS for windows /linux /mac to share)

RAID: (SoftRaid on Snow Leopard utilizing 4x1.5TB) = 6 in total.

GFX: PNY NVidia GTX 275 (I had to use an older NVidia card to install Snow Leopard, then used GTX 275 kexts to install my GTX 275 card. I might suspect these kexts do something? maybe not? The EFI String method did not work for me.

Soundcard: The one that came with the motherboard: Creative X-FI 7.1

Extra hardware: Black Magic Intensity Pro

venus___s_Mac_Pro.zip

[Detrich]

Thursdayy

 

First, rename ur hack as MacPro4,1 for better compatibility, also, add PSS for ur CPU under _PR scop for vanilla speedstep. You can also, remove Platform UUID.kext and OSX Restart.kext, use the last chameleon(Dr.Hurt), that already have this fixes.

 

PS: I've seen, that ur Black Magic, is recognized by system, adress 1C,3. My edited DSDT, don't provide APIC resources for this adress. I'll add it later and will see, if this can change something(you should test).

[Thursdayy]

Thursdayy

 

First, rename ur hack as MacPro4,1 for better compatibility, also, add PSS for ur CPU under _PR scop for vanilla speedstep. You can also, remove Platform UUID.kext and OSX Restart.kext, use the last chameleon(Dr.Hurt), that already have this fixes.

 

PS: I've seen, that ur Black Magic, is recognized by system, adress 1C,3. My edited DSDT, don't provide APIC resources for this adress. I'll add it later and will see, if this can change something(you should test).

 

 

Attached is screenshots of my PState and also IOReg dump since I deleted the DSDT.aml you provided to mathf and I also added his smbios.plist for MacPro4,1 Hack.

ioregdump_thursdayy.zip

pss.zip