Jump to content

hackcat

Members
  • Content count

    61
  • Joined

  • Last visited

About hackcat

  • Rank
    InsanelyMac Protégé
  1. Using your appended ssdt tables with borrowed c-states, I just changed the following: Name (SPSS, Package (0x03) { Package (0x06) { 0x0C80, 0x0135BA, 0xA0, 0x0A, 0x082A, 0x082A }, Package (0x06) { 0x0AF0, 0x01025F, 0xA0, 0x0A, 0x0726, 0x0726 }, Package (0x06) { 0x0960, 0x00CD35, 0xA0, 0x0A, 0x0620, 0x0620 } }) Name (NPSS, Package (0x03) { Package (0x06) { 0x0C80, 0x0135BA, 0x0A, 0x0A, 0x082A, 0x082A }, Package (0x06) { 0x0AF0, 0x01025F, 0x0A, 0x0A, 0x0726, 0x0726 }, Package (0x06) { 0x0960, 0x00CD35, 0x0A, 0x0A, 0x0620, 0x0620 } }) Those p-states work for me when I put them upfront in the dsdt without appending ssdt tables: Processor (CPU0, 0x00, 0x00000410, 0x06) { Name (_PPC, Zero) Name (_PCT, Package (0x02) { ResourceTemplate () { Register (FFixedHW, 0x10, // Bit Width 0x00, // Bit Offset 0x0000000000000199, // Address ,) }, ResourceTemplate () { Register (FFixedHW, 0x10, // Bit Width 0x00, // Bit Offset 0x0000000000000198, // Address ,) } }) Name (_PSS, Package (0x03) { Package (0x06) { 0x0C80, 0x0135BA, 0x0A, 0x0A, 0x082A, 0x082A }, Package (0x06) { 0x0AF0, 0x01025F, 0x0A, 0x0A, 0x0726, 0x0726 }, Package (0x06) { 0x0960, 0x00CD35, 0x0A, 0x0A, 0x0620, 0x0620 } }) } BTW, using an overclocked e6750 which only has 3 p-states. x8 is 3200 @ 1.372v, x7 2800 @ 1.308v, x6 2400 @1.212v
  2. Just playing audio cpu-i shows me pretty much pegged at the lowest p-state x6. I only get the stutter issue by adding c-states to my dsdt. I finally added my p-states without appending ssdt tables to the dsdt. I defined my p-states at the beginning of the dsdt. Doing so, you also only have the 0x0A latency value defined. When I had the ssdt tables appended, the NPSS had the 0xA0 and the SPSS had the 0x0A values for transition latency. Suggesting my stutter could be fixed there?
  3. Are c-states processor dependent? Since I didn't have c-state tables on my mobo, I just borrowed from this thread. The more I think about it, my audio stutter could have been because I was rapidly dropping in and out of a c-state. If I did a bit more activity like moving the mouse a lot, the audio stopped stuttering. So the heuristics as when to idle or not were wrong for me, i.e playing audio was just at the threshold of when to drop into a c-state (perhaps even just C0) and the latency switch back and forth accounted for the stutter.
  4. UHCI/EHCI built in

    I chose to avoid appending ssdt tables to the dsdt, so yes no _CST method. You can still declare your p-states at the beginning of your dsdt, there are examples of that on the speedstep thread. Using an e6750, overclocked to 3.2Ghz. Have only 3 p-states (x6 x7 x8). Are c-states processor dependent?
  5. UHCI/EHCI built in

    Well it turns out the problem isn't with defining p-states but borrowing c-states from MacPro3,1. Using a dsdt with only p-states I don't have the stutter problem, nor do I have problems going to sleep.
  6. I chose to go only for adding p-states to my dsdt without borrowing the MacPro3,1 c-states. That works for me. I shave off maybe 5 to 7°C, but not quite the lower consumption that having the c-states enabled. With the c-states borrowed per core temps dropped up to 15°C. But this way, no audio stutter, no patchy animations. So at least I narrowed down the source of my problems.
  7. Chameleon with SMBIOS patching

    Edit: This problem happens only when I try to activate c-states, have no problems just defining p-states in my dsdt. So I doubt the following describes the problem I had. When I enable vanilla speedstep I get audio stutter and blocky animations. This seems to be a clock problem with speedstep (my dsdt has the rtc fix). I was wondering since my E6750 does not get its clock values and bus values derived programmatically, must use SMmaximalclock and SMexternalclock, whether that would mess some timings say audio and dock animations. From sysctl: hw.cpufrequency_max: 3200000000 hw.cpufrequency_min: 3200000000 hw.cpufrequency: 3200000000 hw.busfrequency_max: 1600000000 hw.busfrequency_min: 1600000000 hw.busfrequency: 1600000000 I would expect that minimal frequency would get set at my x6 step or 2.4Ghz. If I move the mouse very fast the audio stutter goes away, maybe speedstep jumps into a higher state?
  8. UHCI/EHCI built in

    Check outDSDT - Vanilla Speedstep - Remove _cst errors for MB without C-states If you install cpu-i (check linked thread) and your board has p-states you can get the values for your cpu easily. You can also use a calculator posted in that thread. I had speedstep working but i think I ended up with a pretty bad stutter case on audio and choppy dock animations. Also sleep no longer worked. Although strangely if I moved my mouse a lot, the stutter went away. Despite all those problems it did transition nicely to the different speedsteps. You might have better luck.
  9. Well pruning the scope segment for just 2 cores didn't change anything, I still get the audio stutter. I'm going to reread what you have done as I found out some interesting stuff such as I can't just define one x8 pstate in NPSS and SPSS segments, I still get a x6 step at x8 voltages. Thanks for the suggestions so far, I think I'll table this for a bit as I have everything I want working without trying to enable vanilla speedstep.
  10. I only copied the scope part and modified SPSS and NPSS. I also checked in Everest what my ssdt tables were, and well they matched for the first 2 cores. I see we have the same mobo (P35-DS4). The only tables available to me in windows via Everest were the first 2 cores. I didn't see the need to remove those for the other cores. Following is based on the p-states I got from my mobo via cpu-i, not the best voltages but I can figure that out later. x8 3200 @ 1.372v x7 2800 @ 1.308v x6 2400 @ 1.212v Is that right that the bus latency between NPSS and SPSS are different, 0xA0 and 0x0A? The funny part is if I move my mouse fast I get rid of the audio stutter issue. Name (SPSS, Package (0x03) { Package (0x06) // P-state 1 { 0x0C80, 0x0135BA, 0xA0, 0x0A, 0x082A, 0x082A }, Package (0x06) // P-state 2 { 0x0AF0, 0x01025F, 0xA0, 0x0A, 0x0726, 0x0726 }, Package (0x06) // P-state 3 { 0x0960, 0x00CD35, 0xA0, 0x0A, 0x0620, 0x0620 } }) Name (NPSS, Package (0x03) { Package (0x06) // P-state 1 { 0x0C80, 0x0135BA, 0x0A, 0x0A, 0x082A, 0x082A }, Package (0x06) // P-state 2 { 0x0AF0, 0x01025F, 0x0A, 0x0A, 0x0726, 0x0726 }, Package (0x06) // P-state 3 { 0x0960, 0x00CD35, 0x0A, 0x0A, 0x0620, 0x0620 } })
  11. A few questions about SpeedStep and my e6750

    Check out DSDT - Vanilla Speedstep - Remove _cst errors for MB without C-states I have an e6750 overclocked to 3.2Ghz and a P35-DS4 rev 2.0, and used my mobos p-states so it might not be the most tuned ones. I think I have some room to lower core voltage across all states. x8 3200 @ 1.372v x7 2800 @ 1.308v x6 2400 @ 1.212v Name (SPSS, Package (0x03) { Package (0x06) // P-state 1 { 0x0C80, 0x0135BA, 0xA0, 0x0A, 0x082A, 0x082A }, Package (0x06) // P-state 2 { 0x0AF0, 0x01025F, 0xA0, 0x0A, 0x0726, 0x0726 }, Package (0x06) // P-state 3 { 0x0960, 0x00CD35, 0xA0, 0x0A, 0x0620, 0x0620 } }) Name (NPSS, Package (0x03) { Package (0x06) // P-state 1 { 0x0C80, 0x0135BA, 0x0A, 0x0A, 0x082A, 0x082A }, Package (0x06) // P-state 2 { 0x0AF0, 0x01025F, 0x0A, 0x0A, 0x0726, 0x0726 }, Package (0x06) // P-state 3 { 0x0960, 0x00CD35, 0x0A, 0x0A, 0x0620, 0x0620 } }) Do note I haven't yet figured out how to make everything work using vanilla speedstep on 10.5.8 ( no sleep and an audio stutter issue, stable otherwise)
  12. Thanks FormerlyKnownAs for the tutorial. I got to input the proper p-states for my overclocked E6750 and use the smbios.plist w Chameleon to inject the MacPro3,1 value. CPU-i did show my setup throttling through my 3 p-states. I kept the ssdt tables unchanged as they seemed to be the same as for your mobo (I had fewer because only using a dual core cpu but did not remove those for the other cores). This is on a P35-DS4 rev 2.0 with an all vanilla OS X 10.5.8 + fakesmsc.kext, AHCIPortInjector, IOAHCIBlockStorageInjector and UUID.kext. Unfortunately it brought in more problems then it solved: For one I got a serious audio stutter My dock animations and window dragging are less fluid I lost the ability to sleep Before tackling the c-states p-state stuff I had the uhci/ehci fix in my dsdt and also fixed my hdef audio using id 66 on an alc889a, + nic fix and gfx fix. The stutter for both audio and the dock animations seem related as moving my mouse wildly would lessen the amount of stutter. Is this the mouse lag problem? (It isn't my mouse that seems unresponsive). Sleep and wake from keyboard were working before adding the ssdt tables and p-states in my dsdt.
  13. UHCI/EHCI built in

    Should have mentioned I'm using this fix on 10.5.8 so unsure as how this relates to SL. In the end I copied Tapper00's usb fixes directly, they worked as is on the DS4.
  14. UHCI/EHCI built in

    OK, perplexed. Maybe I was dyslexic or actually updating my BIOS to v14 from 14a made the difference but I now have wake from usb working (p35-DS4 rev 2.0). I did disable USB legacy storage after the BIOS update, not sure if that could have played a role in it. Great stuff. Now I just have to fix c-state tables and if I care get rid of sound assertions and this hack will be all good.
  15. UHCI/EHCI built in

    On a GA P35-DS4 v14a of BIOS I'm going to check my BIOS settings, but this fix while it does properly reset the USB buses as built-in prevents my setup from going to sleep. It could before. Not sure I want to start disabling HPET as another user suggested. There was only a small change for my setup, USB3 and US31 had the reverse addresses. I'm going to try without changing the EHCI devices and see if that works for me. Would be nice to power up from keyboard.
×