114 replies to this topic

[magnifico]

d00d, on Dec 4 2010, 03:41 PM, said:

Yes, my boot drives are 2 x 80 GB Intel SSDSA2MH080G1GC OS X RAID 0.

Hello Dood. .have you  screen of the bios of yours motherboard ?

[d00d]

magnifico10, on Dec 5 2010, 03:43 PM, said:

Hello Dood. .have you  screen of the bios of yours motherboard ?

There are many screens, which one?
I included the important settings in post 1.

[magnifico]

d00d, on Dec 6 2010, 12:07 AM, said:

There are many screens, which one?
I included the important settings in post 1.

I want to say the shielded ones of the bios..thanks

[Tutor1]

d00d, on Oct 7 2010, 02:56 PM, said:

Unmodified and item 1 modified DSDTs from SR2 and BIOS A41 through A49, with S3 sleep: DSDT_SR2.zip

Unmodified and item 1 and 2 modified DSDTs from SR2 and BIOS A41 through A50, with S3 sleep: DSDT_SR2-2.zip

d00d, where and how is the DSDT file/folder placed?  Thanks.

[d00d]

Tutor1, on Dec 8 2010, 01:54 PM, said:

d00d, where and how is the DSDT file/folder placed?  Thanks.

The aml file should be renamed to DSDT.aml and placed where your bootloader expects to find it.

[banini_jeque]

Which mod was it that finally made speedstep work? On my EVGA X58 SLI3 (e767) I have the X58 equivalents of all your mods, plus all the standard ones for Gigabyte X58 boards, and it still doesn't seem to be working. I was using DropSSDT=yes, and GenerateCStates=yes, and I had an ssdt.aml, so I'm dumping those now and I'll report back in a few.

Edit:

Still not working.
I have C2RC5 r635
In the bios I have S3, HPET 64bit, AHCI, Turbo, C1E, Speedstep on
DSDT has HPET, LPCB, TMR, IPIC, SBUS with BUS0, RTC, cosmetic fixes, and maybe some things I'm forgetting
I've tried DropSSDT y/n, GenerateCStates y/n, GeneratePStates y/n, with or without ssdt.aml
I did the change in fakesmc
I've tried iMac11,1, MacPro4,1, MacPro5,1 (after deleting the TyMCE kext), and PowerMac3,4 with my legacy kext just for fun (My case is a PowerMac3,4 case).
At one point I made a legacy kext, but I think those are only helpful if you can boot without NullCPUPM in the first place, because once I got it right it caused a panic.

[d00d]

banini_jeque, on Dec 8 2010, 05:16 PM, said:

Which mod was it that finally made speedstep work? On my EVGA X58 SLI3 (e767) I have the X58 equivalents of all your mods, plus all the standard ones for Gigabyte X58 boards, and it still doesn't seem to be working. I was using DropSSDT=yes, and GenerateCStates=yes, and I had an ssdt.aml, so I'm dumping those now and I'll report back in a few.

Edit:

Still not working.
I have C2RC5 r635
In the bios I have S3, HPET 64bit, AHCI, Turbo, C1E, Speedstep on
DSDT has HPET, LPCB, TMR, IPIC, SBUS with BUS0, RTC, cosmetic fixes, and maybe some things I'm forgetting
I've tried DropSSDT y/n, GenerateCStates y/n, GeneratePStates y/n, with or without ssdt.aml
I did the change in fakesmc
I've tried iMac11,1, MacPro4,1, MacPro5,1 (after deleting the TyMCE kext), and PowerMac3,4 with my legacy kext just for fun (My case is a PowerMac3,4 case).
At one point I made a legacy kext, but I think those are only helpful if you can boot without NullCPUPM in the first place, because once I got it right it caused a panic.

For the EVGA SR-2 only an AppleLPC related DSDT modification was needed. Compare the lspci output against your Apple[HPET|LPC|RTC] kexts to make sure your related DSDT modifications are needed and correct.
Assuming those are correct, and the BIOS has HPET and CStates enabled, AppleIntelCPUPowerManagement[|Client] kexts should load and you will have NPM.
If you get a boot panic, that may give clues.
Otherwise kernel.log may have clues.

[banini_jeque]

Well let's see. lspci says my LPC is 8086:3a16, and in my DSDT I have it patched to 3a18. AppleLPC loads, and in IORegistryExplorer it shows the device id as <18 3a 00 00>, but still shows the IOName as pci8086,3a16. Is that correct? AppleHPET and AppleRTC also load, but I don't know how to identify their output in lspci.

[d00d]

banini_jeque, on Dec 8 2010, 06:54 PM, said:

Well let's see. lspci says my LPC is 8086:3a16, and in my DSDT I have it patched to 3a18. AppleLPC loads, and in IORegistryExplorer it shows the device id as <18 3a 00 00>, but still shows the IOName as pci8086,3a16. Is that correct? AppleHPET and AppleRTC also load, but I don't know how to identify their output in lspci.

That's correct, and AppleHPET and AppleRTC loads so they're good there too.
Clues in panic or kernel.log?
Do the AppleIntelCPUPowerManagement[|Client] kexts load?
In IOService:/AppleACPIPlatformExpert/CPU0@0/AppleACPICPU/ACPI_SMC_PlatformPlugin do you see SpeedStep's CPUPLimit with a value of 0x0, CState's CSTinfo, and the PState's PerformanceStateArray?

[banini_jeque]

I don't know how to identify clues in the panic, so I've attached a pic.

In kernel.log I have these possible clues:

ACPI_SMC_PlatformPlugin::start - waitForService(resourceMatching(AppleIntelCPUPowerManagement) timed out
ACPI_SMC_PlatformPlugin::gatherCStateOverrides - failed to set c-state demotion data: -1

AppleIntelCPUPowerManagement loads (seen in ASP, and kextstat), but the Client doesn't.

I do have the PerformanceStateArray with 13 values, which I'm pretty sure is correct for the i7 950, but I don't have CPUPLimit nor CSTInfo, and I've never seen them even when I use GenerateCStates or my ssdt.aml. I've checked for them many times during the past few weeks.

Attached Files

•  kernel_panic.png   49.29K   31 downloads

[d00d]

banini_jeque, on Dec 8 2010, 07:51 PM, said:

I don't know how to identify clues in the panic, so I've attached a pic.

In kernel.log I have these possible clues:

ACPI_SMC_PlatformPlugin::start - waitForService(resourceMatching(AppleIntelCPUPowerManagement) timed out
 ACPI_SMC_PlatformPlugin::gatherCStateOverrides - failed to set c-state demotion data: -1

AppleIntelCPUPowerManagement loads (seen in ASP, and kextstat), but the Client doesn't.

I do have the PerformanceStateArray with 13 values, which I'm pretty sure is correct for the i7 950, but I don't have CPUPLimit nor CSTInfo, and I've never seen them even when I use GenerateCStates or my ssdt.aml. I've checked for them many times during the past few weeks.

The panic on the AppleIntelCPUPowerManagement kext is a `type 13=general protection' fault.
If it had involved HPET there would be a DSDT fix, but the AppleHPET kext loads on your machine.
There's some information on how to debug at;
http://developer.app...002/tn2063.html

Your kernel.log is typical for when you allow the NullCPUPowerManagement kext to load to prevent the panic, but doing so prevents you from having CStates.

I'm holding out hope for a bootloader fix for this and my AppleTyMCEDriver issue.

Slice is getting into some low level stuff with his RC5 branch;
http://www.projectos...?showtopic=1106

I also want to try returning 0x0501 for my six core CPUs;
http://forge.voodoop...leon/issues/49/

[banini_jeque]

Most of that stuff is a "bit" over my head, (pun intended), but my best guess is that it has something to do with Reserved Bit Checking, page 10-58 in the Intel 64 and IA-32 Architectures Software Developer’s Manual, Volume 3A: System Programming Guide, Part 1. I'll look at it more later today when I have time, and try Slice's latest. I also have the AppleTyMCEDriver issue if I use MacPro4,1 or 5,1.

[banini_jeque]

Well, I tried Slice's Chameleon, and it didn't make a difference. I tried a couple of other RC5 versions, and then I even went back to RC4. I get the same type 13 panic in all versions. I also tried booting in 32 bit mode, and I still got the panic, but it came slightly later, which I would guess is just because of where the code is located or whatever.

[d00d]

banini_jeque, on Dec 10 2010, 04:52 PM, said:

Well, I tried Slice's Chameleon, and it didn't make a difference. I tried a couple of other RC5 versions, and then I even went back to RC4. I get the same type 13 panic in all versions. I also tried booting in 32 bit mode, and I still got the panic, but it came slightly later, which I would guess is just because of where the code is located or whatever.

That's disappointing.
When I get several hours of free time I'll experiment to see if the extracted DSDT, when booting without one, is different when different settings are changed in the BIOS.
Experiments with the Gigabyte MB showed that changing from S1(POS) to S3(STR) sleep would change the resulting DSDT.
So it's possible that my testing various BIOS options that may have helped, were being masked by my DSDT overriding them.

[banini_jeque]

I haven't done a whole lot of stuff like that, but I did compare airwalk667's DSDT from his EVGA X58 with the SZ2Z bios to mine, and there really isn't much of anything that I could see, aside from the alignments for the TMR and RTC devices being different. I looked at a DSDT from a UD5 and it had a lot of other little differences that might account for things. I also looked at my FADT extracted from linux, but I don't know much about what's in there.

[sch8mid]

simply the best

[banini_jeque]

I was about to give up on my X58 SLI3 completely, but then I realized that I don't really like the looks of the current Asus or Gigabyte boards that much. I think I'll hold out and see what comes in January (G1 Killer?), or if I get CPUPM loading right on here I'll just keep this. Do you think netkas would have any ideas?

[banini_jeque]

I'm looking at maybe modding the bios by replacing the evga cpu microcode with Gigabyte's. Do you think that would do it?

Check my post here for more details.

[d00d]

banini_jeque, on Dec 23 2010, 05:03 AM, said:

I'm looking at maybe modding the bios by replacing the evga cpu microcode with Gigabyte's. Do you think that would do it?

Check my post here for more details.

AFAIK the microcode comes from Intel, and the MB vendor just adds it to their BIOS.
I'm assuming it's the EVGA difference of the BIOS that causes AICPM and TyMCED issues.
It may be something that's exposed in the DSDT, and therefore can be changed, or a change to the bootloader may help.
You may want to try a BIOS editor to see what changed between versions;
http://www.rebelshav...52;t=000004;p=0

[banini_jeque]

Yeah I've been messing around with some of those already. I noticed the size of the cpumicrocode is like 85k in evga bios version 77, while for the latest gigabyte x58a-ud3r bios it was only 50k. Do you know what parts of the bios I should be looking at? Would it be in the ACPI table?

I'm posting on the evga forums to research differences between sz2z and 44, but it's hard to do without being able to say exactly why I want to know. Apparently 44 was really bad and had all kinds of bugs related to changes they made for 32nm/6 core support, and they said it caused a lot of problems for 45nm/4 core chips as well, so maybe it's a lingering bug that hasn't been fixed yet.