dlach Posted June 29, 2010 Share Posted June 29, 2010 Thanks for the link, very interesting. That does not make the LPC-Warning more detailed, but it shows that all SSDT-Tables which are related to the C-States are loading fine. So the problem has to be fixed in the DSDT. For a while now I've had a suspicion the c-tables from the SSDTs may be loading at the wrong address. I don't have any hard evidence but based on the universal failure we've experienced, I believe if we use the new AnV bootloader variant of chameleon and remap the load addresses we may finally get somewhere. Check this LINK Link to comment Share on other sites More sharing options...
MorLipf Posted June 29, 2010 Share Posted June 29, 2010 But why we do not get the "_CST evaluation failed" error then? Is there a way to find out which memory adresses OSX is using for the C-States? It seems that there is no Voodoo Kernel for Snow Leopard. Isn't it possible that our LPC error is related to the SBus-Device? I have read in the ProjectOSX forum that regular desktop computers use a SuperIO for controlling the states and notebooks make use of the SMBus. Maybe the SBus device has to be integrated in the WSEC method inside of the LPC section (or is this already done?). Edit: I filmed the ACPI debug output on boot to check the hardcoded memory adresses. They are all correct. It is definitely not a problem with our SSDT. Has anyone a new idea? :-/ Link to comment Share on other sites More sharing options...
MorLipf Posted July 2, 2010 Share Posted July 2, 2010 Now that I am sure that the hardcoded C-State adresses are valid I have looked for differences between our DSDT and the original DSDT of an MacBookPro3,1. The MacBook Pro has the SMBus methods inside the LPC and EC function. We have the WSEC section in our DSDT. This should be similar to Apples EC section. The difference is that Apple included the SMBus device inside the EC part (look for SMB0) but our SBUS device is outside the LPC device. Maybe it will work when we integrate it into the WSEC section. Is anyone with DSDT modding skills able to do it? Edit: The original MacBook Pro DSDTs have also the SBUS-Device. But our DSDT does not have the SMB0-Device inside the WSEC function. This might be the problem. Link to comment Share on other sites More sharing options...
oSxFr33k Posted July 5, 2010 Share Posted July 5, 2010 I was able to get firewire to work using this file instead of the M1550 for the Dell D830. "DSDT_M1330_NVIDIA_ANYCPU_20100411.zip" Shutdown works flawless. The graphics card 8400GT is basically the same as the one on the Dell D830 NVS Quadro 140M. Only two things don't work: 1) Ethernet BCM5755 2) Sleep If I put it to sleep it goes to sleep but when it wakes it crashes. Would anyone know what I need to modify in the DSDT to fix that? The D830 and M1330 are nearly the same boards. Link to comment Share on other sites More sharing options...
donkey Posted July 5, 2010 Share Posted July 5, 2010 Now that I am sure that the hardcoded C-State adresses are valid I have looked for differences between our DSDT and the original DSDT of an MacBookPro3,1. The MacBook Pro has the SMBus methods inside the LPC and EC function. We have the WSEC section in our DSDT. This should be similar to Apples EC section. The difference is that Apple included the SMBus device inside the EC part (look for SMB0) but our SBUS device is outside the LPC device. Maybe it will work when we integrate it into the WSEC section. Is anyone with DSDT modding skills able to do it? Edit: The original MacBook Pro DSDTs have also the SBUS-Device. But our DSDT does not have the SMB0-Device inside the WSEC function. This might be the problem. glad someone is looking into the c-states... would be great to see this working! Link to comment Share on other sites More sharing options...
Wanna Hack Posted July 5, 2010 Share Posted July 5, 2010 I was able to get firewire to work using this file instead of the M1550 for the Dell D830. "DSDT_M1330_NVIDIA_ANYCPU_20100411.zip" Shutdown works flawless. The graphics card 8400GT is basically the same as the one on the Dell D830 NVS Quadro 140M. Only two things don't work: 1) Ethernet BCM5755 2) Sleep If I put it to sleep it goes to sleep but when it wakes it crashes. Would anyone know what I need to modify in the DSDT to fix that? The D830 and M1330 are nearly the same boards. Try removing AppleIntelCPUPowerManagement.kext from S/L/E and install SleepEnabler (for your current version of OS) using Kext Utility -- which will install SleepEnabler in S/L/E. I'm using a generic DSDT for m1530 and this was the only way to get sleep from Apple menu and clamshell to work. Auto sleep via Energy Saver Preference Pane does not seem to work. Link to comment Share on other sites More sharing options...
MorLipf Posted July 5, 2010 Share Posted July 5, 2010 A few days ago I tried to port the SMB0 device from the MacBookPro3,1-DSDT to our DSDT, but it did not change something. So I have continued to compare the DSDTs. Nearly every DSDT has a "OperationRegion (LPC0,...)" at the beginning of the LPCB block but our DSDT has not. I will try to get more information on that. Maybe I slowly get closer to a final solution. Link to comment Share on other sites More sharing options...
ab___73 Posted July 5, 2010 Share Posted July 5, 2010 A few days ago I tried to port the SMB0 device from the MacBookPro3,1-DSDT to our DSDT, but it did not change something. So I have continued to compare the DSDTs. Nearly every DSDT has a "OperationRegion (LPC0,...)" at the beginning of the LPCB block but our DSDT has not. I will try to get more information on that. Maybe I slowly get closer to a final solution. My latest findings..... Another difference is that our PM base address is 0x1000, all apple macs are 0x400, our CPU address is PMbase + 0x10h = 0x1010 and apple cpu base address is 0x410. I've decompiled the ACPI_SMC_PlatformPlugin binary in the ACPI_SMC_PlatformPlugin.kext and found that this kext is hardcoded to look at the PM base of 0x410. __ZN23ACPI_SMC_PlatformPlugin17registerLPCDriverEP9IOServicebPb: 000027b2 pushl %ebp 000027b3 movl %esp,%ebp ..... ..... 00002a36 movl (%eax),%eax 00002a38 movl %edx,(%esp) 00002a3b call *0x00000094(%eax) 00002a41 movl %eax,0x000000f4(%edi) 00002a47 movb $__ZNK23ACPI_SMC_PlatformPlugin12getMetaClassEv,0x00000151(%edi) 00002a4e cmpw $0x8086,0xd2(%ebp) 00002a54 jne 0x00002aab 00002a56 movb $0x01,0x00000151(%edi) 00002a5d calll __ZL12getCPUIDInfov 00002a62 cmpl $0x05,%eax 00002a65 jne 0x00002a76 00002a67 movl $0x00000410,__ZL13gIOPMBaseAddr <<--Assigns the 0x410 value into the IOPMbaseaddr address. 00002a71 jmpl 0x00002b51 00002a76 movl (%esi),%eax 00002a78 movl $__ZN23ACPI_SMC_PlatformPlugin19enableCStateSupportEb,0x04(%esp) 00002a80 movl %esi,(%esp) 00002a83 call *0x000004bc(%eax) 00002a89 andl $0xfe,%eax 00002a8c movl %eax,__ZL13gIOPMBaseAddr 00002a91 movb $0xa8,0x000000f8(%edi) 00002a98 movb $0x54,0x000000f9(%edi) 00002a9f movb $0x58,0x000000fa(%edi) 00002aa6 jmpl 0x00002b51 00002aab cmpw $0x10de,0xd2(%ebp) 00002ab1 jnel 0x00002b51 ..... ..... My theory is (sorry not good news) All LPC control is based on this PMBase address and this is one of the reasons why we cannot get the LPC Device to register correctly with the OS. I've also patched this binary to use the 0x1010 address and it still fails to register, so there must be other parts of the OS that hard codes this address into the code. It would be good if we could somehow change our PMBase to 0x400, this is assigned in the FADT.aml table but requires the BIOS to assign code or functions at this address for it work (i think). I've attached the decompiled binary. ACPI_SMC_PlatformPlugin.s.zip Link to comment Share on other sites More sharing options...
MorLipf Posted July 6, 2010 Share Posted July 6, 2010 That does not sound good. But thanks for the information. I will take a look into the FADT-Table later this day. Do all Macs use 0x400? Maybe it would be enough to change the model in smbios.plist. Edit: Are Gigabyte boards the only mainboards on which C-States work? I think only these boards make use of the same PMBase adress like Apples mainboards. So if we find a mainboard which support C-States under OSX with another PMBase than 0x400, the hardcoded adresses in the Kext cannot be the problem. Edit 2: I have seen that the FADT (FACP) table is for information only. I think the PMBase can only be changed by modifying the BIOS. This cannot be easy. :-/ Link to comment Share on other sites More sharing options...
ab___73 Posted July 6, 2010 Share Posted July 6, 2010 That does not sound good. But thanks for the information. I will take a look into the FADT-Table later this day. Do all Macs use 0x400? Maybe it would be enough to change the model in smbios.plist. Edit: Are Gigabyte boards the only mainboards on which C-States work? I think only these boards make use of the same PMBase adress like Apples mainboards. So if we find a mainboard which support C-States under OSX with another PMBase than 0x400, the hardcoded adresses in the Kext cannot be the problem. Edit 2: I have seen that the FADT (FACP) table is for information only. I think the PMBase can only be changed by modifying the BIOS. This cannot be easy. :-/ All mainboards I've came across that report C-States working have a PMBase of 0x400 and a CPU PMbase of 0x410. Can anyone disprove this? -- AB Link to comment Share on other sites More sharing options...
MorLipf Posted July 6, 2010 Share Posted July 6, 2010 I got rid of the LPC Warning at boot! But now I have slight boot problems. X-D Maybe I will get it to work tomorrow. Stay tuned! Link to comment Share on other sites More sharing options...
oSxFr33k Posted July 7, 2010 Share Posted July 7, 2010 Problem: I updated to 10.6.4 from 10.6.3 and I am seeing a few dependency warnings on boot. From system profiler I still get "There was an error while gathering this information" I am using the fakesmc from the Superhai CD version 5 and the smbios.plist from the first page link. Also the com.apple.boot.plist key for smbiosdefault no and the key for the path of the smbios.plist. Not sure if that script is needed anymore using AnVal Modified Chameleon 2 RC5Pre7 r144 I am only using 3 kexts in /e/e, AppleACPIPS2Nub.kext, ApplePS2Controller.kext, fakesmc.kext, and voodooHDA.kext in /s/l/e/ Partial Kernel Log: Jul 6 19:28:54 osxfr33ks-Mac kernel[0]: jnl: disk0s2: journal replay done. Jul 6 19:28:54 osxfr33ks-Mac kernel[0]: VoodooHDADevice[0x462bf000]::init Jul 6 19:28:54 osxfr33ks-Mac kernel[0]: Enabling output audio routing switching at node 10: Jul 6 19:28:54 osxfr33ks-Mac kernel[0]: Enabling input audio routing switching at node 14: Jul 6 19:28:54 osxfr33ks-Mac kernel[0]: Pin sense: cad 2 nid=10 res=0 Jul 6 19:28:54 osxfr33ks-Mac kernel[0]: setDesc change description Speaker (Analog) channel 0 assoc 0 Jul 6 19:28:54 osxfr33ks-Mac kernel[0]: Pin sense: cad 2 nid=14 res=0 Jul 6 19:28:54 osxfr33ks-Mac kernel[0]: switch nid 27 conn 0 off Jul 6 19:28:54 osxfr33ks-Mac kernel[0]: switch nid 27 conn 1 on Jul 6 19:28:54 osxfr33ks-Mac kernel[0]: setDesc change description Microphone (Digital) channel 1 assoc 1 Jul 6 19:28:54 osxfr33ks-Mac kernel[0]: NVDANV50HAL loaded and registered. Jul 6 19:28:54 osxfr33ks-Mac kernel[0]: Trying to change a collection in the registry Jul 6 19:28:54 osxfr33ks-Mac kernel[0]: Backtrace 0x4ff608 0x5b28d102 0x5b28d0d6 0x5b28d2c5 0x5b28d493 0x536ddd 0x537616 Jul 6 19:28:54 osxfr33ks-Mac kernel[0]: Kernel Extensions in backtrace (with dependencies):jnl: disk0s4: replay_journal: from: 1986560 to: 2490368 (joffset 0x18c000) Jul 6 19:28:54 osxfr33ks-Mac kernel[0]: com.apple.driver.AppleUSBMergeNub(4.0.0)@0x5b28c000->0x5b28ffff Jul 6 19:28:54 osxfr33ks-Mac kernel[0]: dependency: com.apple.iokit.IOUSBFamily(4.0.2)@0x5aeb5000 Jul 6 19:28:54 osxfr33ks-Mac kernel[0]: dependency: com.apple.driver.AppleUSBComposite(3.9.0)@0x5b24b000 Jul 6 19:28:54 osxfr33ks-Mac kernel[0]: Trying to change a collection in the registry Jul 6 19:28:54 osxfr33ks-Mac kernel[0]: Backtrace 0x4ff608 0x5b28d102 0x5b28d0d6 0x5b28d2c5 0x5b28d493 0x536ddd 0x537616 Jul 6 19:28:54 osxfr33ks-Mac kernel[0]: Kernel Extensions in backtrace (with dependencies): Jul 6 19:28:54 osxfr33ks-Mac kernel[0]: com.apple.driver.AppleUSBMergeNub(4.0.0)@0x5b28c000->0x5b28ffff Jul 6 19:28:54 osxfr33ks-Mac kernel[0]: dependency: com.apple.iokit.IOUSBFamily(4.0.2)@0x5aeb5000 Jul 6 19:28:54 osxfr33ks-Mac kernel[0]: dependency: com.apple.driver.AppleUSBComposite(3.9.0)@0x5b24b000 Jul 6 19:28:54 osxfr33ks-Mac kernel[0]: jnl: disk0s4: journal replay done. Jul 6 19:28:55 osxfr33ks-Mac kernel[0]: vmmon: Loaded @ 0x5b5d415c: Info 0x5b5e1d20 Name com.vmware.kext.vmx86 Version 3.0.0 build-261058 at May 21 2010 02:42:48 Jul 6 19:28:55 osxfr33ks-Mac kernel[0]: DSMOS has arrived Jul 6 19:28:55 osxfr33ks-Mac kernel[0]: vmmon: Service start Jul 6 19:28:55 osxfr33ks-Mac kernel[0]: vmmon: Instrumenting bug 151304... Jul 6 19:28:55 osxfr33ks-Mac kernel[0]: vmmon: Initial HV check: anyNotCapable=0 anyUnlocked=0 anyEnabled=0 anyDisabled=1vmmon: Fast clock thread started. Jul 6 19:28:55 osxfr33ks-Mac kernel[0]: vmmon: HV check: anyNotCapable=0 anyUnlocked=0 anyEnabled=0 anyDisabled=1 Jul 6 19:28:55 osxfr33ks-Mac kernel[0]: vmmon: Cycles 195 Jul 6 19:28:55 osxfr33ks-Mac kernel[0]: vmmon: Module initialized. Jul 6 19:28:55 osxfr33ks-Mac kernel[0]: vmmon: Registering for power state changes Jul 6 19:28:55 osxfr33ks-Mac kernel[0]: AirPort_Brcm43xx: Ethernet address 00:23:4d:a6:b9:44 Jul 6 19:28:55 osxfr33ks-Mac kernel[0]: IO80211Controller::dataLinkLayerAttachComplete(): adding AppleEFINVRAM notification Jul 6 19:28:55 osxfr33ks-Mac kernel[0]: AirPort: Link Down on en1. Reason 8 (Disassociated because station leaving). Jul 6 19:28:55 osxfr33ks-Mac kernel[0]: FakeSMC: key not found BEMB, length - 1 Jul 6 19:28:55 osxfr33ks-Mac kernel[0]: ACPI_SMC_PlatformPlugin::registerLPCDriver - WARNING - LPC device initialization failed: C-state power management not initialized Jul 6 19:28:55 osxfr33ks-Mac kernel[0]: AppleUSBCDCACMData: Version number - 4.0.1, Input buffers 8, Output buffers 16 Thanks Link to comment Share on other sites More sharing options...
MorLipf Posted July 7, 2010 Share Posted July 7, 2010 The dependency warnings should disappear, when you copy all Kexts to /S/L/E. A few new information regarding C-State support: It is getting a bit strange now. I reverted back to the original IOPlatformPluginFamily.kext to boot the OS again. Than I tried the same changes again and now the LPC warning stays and the system is still booting. I do not know what it was. My idea was the following: When you take a look at the Resource folder inside ACPI_SMC_PlatformPlugin.smc you will see model specific plist files. The MacBookPro3,1 is very close to our M1530. In its plist there is a C-State section which is missing in MacBookPro5,1.plist. Because we are using MacBookPro5,1 as the model name in smbios.plist I tried to port the C-State section to this plist. Here is a howto for Lenovo / IBM Thinkpads where they made this changes to get C-States to work. And when you look at the code snippets at this link, it seems that they also have a PMBase at 0x00001000. Edit: I was able to get rid of the LPC Warning again in combination with the boot problem. It takes a long time to get to the login screen. The C-States are not working though. What I have done is altering the PMBase like ab___73 mentioned above and the Plist file. Link to comment Share on other sites More sharing options...
raimdal Posted July 9, 2010 Share Posted July 9, 2010 someone have a specific dsdt for dell xps m1530 T7500? Link to comment Share on other sites More sharing options...
MorLipf Posted July 9, 2010 Share Posted July 9, 2010 Why do you need it? Brett's DSDT, link on page 1, should work fine. I think a specific DSDT is only needed to override the CPU voltages. But then you have to create your own one because the lowest possible voltages may differ. Link to comment Share on other sites More sharing options...
Claudio A. Posted July 12, 2010 Share Posted July 12, 2010 Hi, first of all thanks a lot for the work. I've installed iatkos s3 v2, then applied the dsdt from page 1º, added smbios file, and test it with coolbook, I see that speedstep is working because the clock is changing from 800 to 1200 or something. I've a dell xps1530 with T7250 (2Ghz). My question is, is it normal that the fun is almost always on? I'm using xubuntu and the fun is almost always off If I can give you any info, please don't hesitate to ask. (I'm using Macbookpro5,1 in my smbios, I've tied switching to all the specs that are listed in ACPI_SMC_PlatformPlugin (with IORegistry) with no luck) Thanks a lot for your time. Claudio. Link to comment Share on other sites More sharing options...
MorLipf Posted July 12, 2010 Share Posted July 12, 2010 We are still working at C-States support. Without it your CPU gets hotter and that is the reason why the fan sometimes runs at more rpm. Link to comment Share on other sites More sharing options...
Claudio A. Posted July 12, 2010 Share Posted July 12, 2010 We are still working at C-States support. Without it your CPU gets hotter and that is the reason why the fan sometimes runs at more rpm. Oh, Ok, great. Is there any chance that my CPU can burn out if its always between [55-70] ? I'm a little worry if I brake my CPU Can I do something to help you with C-States? Link to comment Share on other sites More sharing options...
MorLipf Posted July 12, 2010 Share Posted July 12, 2010 If the CPU temperature is under 100°C, the notebook will work fine. Not to worry about it. Your help on C-State support is always welcome. Just read the last 3-5 pages of this topic to get into it. I still have a few ideas on it but at the moment I am very busy. I will continue my work on it soon when the semester break begins. Link to comment Share on other sites More sharing options...
Claudio A. Posted July 12, 2010 Share Posted July 12, 2010 If the CPU temperature is under 100°C, the notebook will work fine. Not to worry about it.. Wow nice, using Macmini3,1 I'm around 62 now.. seems to be ok.. but the fun is always working... that is not so good Your help on C-State support is always welcome. Just read the last 3-5 pages of this topic to get into it. I still have a few ideas on it but at the moment I am very busy. I will continue my work on it soon when the semester break begins. I've read a little, and I made a dump of my ssdt tables under xubuntu, then I compare my values with the macbook2,1 ssdt and they are almost the same, but when i select macbook2,1 in my smbios it stops speedstep stops working... don't know why Which steps should I take if now I've all my DSDT and SSDT tables from Linux, is this useful to achieve c-states in mac os? Thanks! Link to comment Share on other sites More sharing options...
Claudio A. Posted July 12, 2010 Share Posted July 12, 2010 Wow! I have the exact same processor, Do you think that It should work? I'm having 55º - 65º .. how did you patch you dsdt? I'm really interested, thanks a lot! Claudio. great guide! Here my DSDT for m1530 with 8600m 256mb and T7250 pstates undervolted for vanilla speedsteep and all fixes of this guide. 800mhz 0.9000v 1200mhz 0.9000v 1600mhz 1.0000v 2000mhz 1.0000v idle: 46c/53c full load:60c/70c gpu: min 65c / max 80c i guess it works for T7300 too. Link to comment Share on other sites More sharing options...
benjamin1 Posted July 12, 2010 Share Posted July 12, 2010 Here is my DSDT.aml it's for XPS M1530 with T8100 and 8600M GT 256MB.Shutdown WORKS Sleep WORKS Restart it's not working (but with osxrestart.kext sometimes does) Video WORKS I want to thanks immo for the guide... I tried your dsdt.aml, it works fine ! thanks a lot, because I don't know how to create one, and don't have the time for the investigation. It seems to be quite hard to understand. Just a question : is your cpu recognized when clicking the field "about this mac" on the apple? Link to comment Share on other sites More sharing options...
jonesjunior3 Posted July 13, 2010 Share Posted July 13, 2010 Does anyone have a working DSDT for a XPS 1530 with t5750 CPU (2GHz). Just realised that the cpu is running at 80deg C all the time with Bretts DSDT, and the T-junction is 85. Runs around 50deg in windows. Any suggestions? Link to comment Share on other sites More sharing options...
Claudio A. Posted July 15, 2010 Share Posted July 15, 2010 Does anyone have a working DSDT for a XPS 1530 with t5750 CPU (2GHz).Just realised that the cpu is running at 80deg C all the time with Bretts DSDT, and the T-junction is 85. Runs around 50deg in windows. Any suggestions? Hi there, I have a XPS 1530 with a T7250 and I'm having the same problem, is not "always" near 80 but it tends to go that way... I've made a lot of tests but i can't manage to be near 50.. one thing that may help you is change you mac model to Macmini3,1 in your smbios. Did you make a vanilla install? If you did which guide did you follow? Link to comment Share on other sites More sharing options...
oSxFr33k Posted July 16, 2010 Share Posted July 16, 2010 I cannot get rid of this message in System Profiler Memory "There was an error while gathering this information." I remember for a while it worked then back to the message again. This was after reinstalling chameleon so I have to assume it gave me an updated smbios.plist which must fix it but I still need the information that Brett has scripted in his. Is the smbios.plist listed in the first post the one that should work for the M1330 and M1530 because that is the one I am using. XPS M1530 4GB, 667GHZ Hynix Memory (Dell default Memory) is installed. Should I remove the memory information sections and let Chameleon output this information or fix the smbios.plist? EDITED 7-24-10: The problem was in my com.apple.Boot.plist. I had to remove this key and string and it now works fine: System Profiler Memory info solved memory info now displayed properly. <key>SMBIOS</key> <string>rd(0,0)/Extra/smbios.plist</string> Link to comment Share on other sites More sharing options...
Recommended Posts