Jump to content

Lyle M

Donators
  • Content count

    54
  • Joined

  • Last visited

About Lyle M

  • Rank
    InsanelyMac Protégé

Contact Methods

  • Website URL
    http://

Profile Information

  • Gender
    Male
  • Location
    Maryland, USA
  1. I made the following change: <key>Threshold_Low</key> <array> <integer>0</integer> <integer>97</integer> <integer>97</integer> <integer>98</integer> </array> My Cinebench R15 score when up to 93. The stuttering in Heaven is gone. While typing this, my GPU core reads 50MHz, but after I navigate some web sites, the core goes to 405MHz and sticks there for quite a while. I may try 0,95,95,97 next. UPDATE: 0,95,95,97: GPU core doesn't idle at 405MHz for near as long. Cinebench score hovering around 90. No stuttering in Heaven. I think I'll keep these settings for a while.
  2. First, a big thanks for this posting. I was getting lots of windowserver crashes prior to editing the AGPM kext. After my first edits, I was getting similar Cinebench results (35) to those quoted above on my GTX 560 ti on 10.9 using the conservative setting in the first post. I later changed Info.plist in the AGPM kext as follows: <key>MacPro5,1</key> <dict> <key>Vendor10deDevice1200</key> <dict> <key>Heuristic</key> <dict> <key>ID</key> <integer>0</integer> <key>IdleInterval</key> <integer>250</integer> <key>SensorOption</key> <integer>1</integer> <key>SensorSampleRate</key> <integer>4</integer> <key>TargetCount</key> <integer>5</integer> <key>Threshold_High</key> <array> <integer>25</integer> <integer>75</integer> <integer>90</integer> <integer>100</integer> </array> <key>Threshold_Low</key> <array> <integer>0</integer> <integer>0</integer> <integer>94</integer> <integer>98</integer> </array> </dict> <key>LogControl</key> <integer>1</integer> <key>control-id</key> <integer>18</integer> </dict> I'm no ace at this by any stretch. My goal is to get to the higher power states faster and at lower levels, and remain there longer. I imagine there's still some refinement needed. I monitored my GPU core frequency with HWMonitor while I was benchmarking. When seeing the lower than expected scores, my GPU was typically at 405MHz. With the above settings, my benchmarks improved dramatically and my GPU mostly remained at 822MHz while testing. When the benchmark finished, my GPU core dropped to 50MHz. My Cinebench results improved as follows: My Novabench score hits 1121. Certainly no GTX 570! My Heaven benchmark improved significantly. However, I noted that every 6 seconds the video would stutter. The graph of my CPU Core speed showed a corresponding frequency drop. I'm guessing that I'll need to further adjust the Threshold_Low figures. However, I'm wondering if adjusting the intervals or sample rates might help. I'd be grateful for any feedback. I think my logs convey this stutter (note the 6 second interval): 11/5/13 3:03:40.000 PM kernel[0]: AGPM: updateGPUHwPstate(1, 0): fHwPstate = 0 fFB = 0xffffff8020acc800 11/5/13 3:03:40.000 PM kernel[0]: AGPM: updateGPUHwPstate(): state = 1. Calling fFB->setAggressiveness()... 11/5/13 3:03:40.000 PM kernel[0]: AGPM: GPU = display G-state set to 1 from 0, ControlID = 18. SW occupancy updated. 11/5/13 3:03:41.000 PM kernel[0]: AGPM: updateGPUHwPstate(0, 0): fHwPstate = 1 fFB = 0xffffff8020acc800 11/5/13 3:03:41.000 PM kernel[0]: AGPM: updateGPUHwPstate(): state = 0. Calling fFB->setAggressiveness()... 11/5/13 3:03:41.000 PM kernel[0]: AGPM: GPU = display G-state set to 0 from 1, ControlID = 18. SW occupancy updated. 11/5/13 3:03:47.000 PM kernel[0]: AGPM: updateGPUHwPstate(1, 0): fHwPstate = 0 fFB = 0xffffff8020acc800 11/5/13 3:03:47.000 PM kernel[0]: AGPM: updateGPUHwPstate(): state = 1. Calling fFB->setAggressiveness()... 11/5/13 3:03:47.000 PM kernel[0]: AGPM: GPU = display G-state set to 1 from 0, ControlID = 18. SW occupancy updated. 11/5/13 3:03:48.000 PM kernel[0]: AGPM: updateGPUHwPstate(0, 0): fHwPstate = 1 fFB = 0xffffff8020acc800 11/5/13 3:03:48.000 PM kernel[0]: AGPM: updateGPUHwPstate(): state = 0. Calling fFB->setAggressiveness()... 11/5/13 3:03:48.000 PM kernel[0]: AGPM: GPU = display G-state set to 0 from 1, ControlID = 18. SW occupancy updated. 11/5/13 3:03:54.000 PM kernel[0]: AGPM: updateGPUHwPstate(1, 0): fHwPstate = 0 fFB = 0xffffff8020acc800 11/5/13 3:03:54.000 PM kernel[0]: AGPM: updateGPUHwPstate(): state = 1. Calling fFB->setAggressiveness()... 11/5/13 3:03:54.000 PM kernel[0]: AGPM: GPU = display G-state set to 1 from 0, ControlID = 18. SW occupancy updated. 11/5/13 3:03:55.000 PM kernel[0]: AGPM: updateGPUHwPstate(0, 0): fHwPstate = 1 fFB = 0xffffff8020acc800 11/5/13 3:03:55.000 PM kernel[0]: AGPM: updateGPUHwPstate(): state = 0. Calling fFB->setAggressiveness()... 11/5/13 3:03:55.000 PM kernel[0]: AGPM: GPU = display G-state set to 0 from 1, ControlID = 18. SW occupancy updated. 11/5/13 3:04:01.000 PM kernel[0]: AGPM: updateGPUHwPstate(1, 0): fHwPstate = 0 fFB = 0xffffff8020acc800 11/5/13 3:04:01.000 PM kernel[0]: AGPM: updateGPUHwPstate(): state = 1. Calling fFB->setAggressiveness()... 11/5/13 3:04:01.000 PM kernel[0]: AGPM: GPU = display G-state set to 1 from 0, ControlID = 18. SW occupancy updated. 11/5/13 3:04:02.000 PM kernel[0]: AGPM: updateGPUHwPstate(0, 0): fHwPstate = 1 fFB = 0xffffff8020acc800 11/5/13 3:04:02.000 PM kernel[0]: AGPM: updateGPUHwPstate(): state = 0. Calling fFB->setAggressiveness()... 11/5/13 3:04:02.000 PM kernel[0]: AGPM: GPU = display G-state set to 0 from 1, ControlID = 18. SW occupancy updated. 11/5/13 3:04:08.000 PM kernel[0]: AGPM: updateGPUHwPstate(1, 0): fHwPstate = 0 fFB = 0xffffff8020acc800 11/5/13 3:04:08.000 PM kernel[0]: AGPM: updateGPUHwPstate(): state = 1. Calling fFB->setAggressiveness()... 11/5/13 3:04:08.000 PM kernel[0]: AGPM: GPU = display G-state set to 1 from 0, ControlID = 18. SW occupancy updated. 11/5/13 3:04:14.000 PM kernel[0]: AGPM: updateGPUHwPstate(2, 0): fHwPstate = 1 fFB = 0xffffff8020acc800 11/5/13 3:04:14.000 PM kernel[0]: AGPM: updateGPUHwPstate(): state = 2. Calling fFB->setAggressiveness()... 11/5/13 3:04:14.000 PM kernel[0]: AGPM: GPU = display G-state set to 2 from 1, ControlID = 18. SW occupancy updated.
  3. I'll try to keep this short. I consistently found those NVDA related errors in the log around the time my system would stop responding (mouse moves but nothing else responds, clock stops, and beach ball spins). Going on the assumption that my GTX 560 ti card was somehow connected to my problems, I focused my research there. Before I found the solution, I went ahead and migrated to Mavericks. Instead of freezes, I would experience Window Server crashes which would return me to the login window. Although less painful than a freeze, they occurred more often. The crashed thread always made reference to com.apple.GeForceGLDriver and com.apple.CoreGraphics. More clues. I then stumbled upon a posting about how to patch your AGPM (Apple Graphics Power Manager). I'm going to risk posting it here even though it's from another site that isn't quite popular with the die-hard open source crowd. http://www.tonymacx86.com/mountain-lion-desktop-support/93022-560ti-fermi-freeze-back-latest-drivers-10-8-3-a-9.html#post578549 My apologies if I'm breaking any rules. I just want to help. I'm on two days without any windowserver crashes (which I believe are the 10.9 analogue to the freezes in 10.8.5). Worth mentioning is that in 10.9, step 2 of the instructions (edit the info.plist file) require the terminal as this file is now invisible. Use terminal to navigate to the contents directory of the kext in question. Then do a ls -al if you want to see what you can't see in the Finder. To edit the plist, you can either use pico, or open it with something like open -a /Applications/TextEdit.app/ Info.plist Once the kext was edited, my kernel log started to show wonderful things like this... 10/30/13 10:22:14.000 PM kernel[0]: AGPM: updateGPUHwPstate(2, 0): fHwPstate = 1 fFB = 0xffffff8020ea0000 10/30/13 10:22:14.000 PM kernel[0]: AGPM: updateGPUHwPstate(): state = 2. Calling fFB->setAggressiveness()... 10/30/13 10:22:14.000 PM kernel[0]: AGPM: GPU = display G-state set to 2 from 1, ControlID = 18. SW occupancy updated. I'm 90% sure my troubles are behind me. I think there's a good chance this will fix the issue for anyone who also sees errors like: NVDA(OpenGL): Channel timeout! I'll post back if I'm horribly mistaken. Cheers.
  4. Hi mattsnowboard, 1. The smbios file is used to define which Mac you're telling the OS you have. You can create multiple smbios.plist files in your /Extra directory and manually specify which one to load when your bootloader is listing your bootable volumes. For instance, if you create a file named smbios51.plist you can load it on demand by entering SMBIOS=/Extra/smbios51.plist - If it works, great! If not, you reboot and let your original, default SMBios.plist file load. Your logic for selecting the iMac13,2 is sound, but I had audio problems with that choice. I suggest grabbing a copy of Chameleon Wizard to help build your smbios file. It's selection of prebuilt system models isn't completely up to date, but it's a great tool to get a feel for building a smbios file. Aside from that, it can be used to mod your org.chameleon.boot file and update your version of Chameleon. It does plenty more than that too. It's a powerful tool, so be sure to use it with caution. I think I just convinced myself to make a donation to the author! So, yes, you can change back to your original smbios after installing the driver. HOWEVER, my system ultimately locked around 9pm and the NVDA log entries returned around 5:20pm. I also found that the Nvidia drivers come with a preference pane that let you toggle between the default OS X drivers and the Nvidia web drivers. I couldn't get the choice for the web drivers to stick. So, I was likely running on the OS X drivers the whole time. I read somewhere that the Nvidia drivers broken with the 10.8.5 supplemental update. I'm not sure if this is the version that has that problem, or if this is how the problem manifests itself. Either way, this may simply be a dead end. 2. I don't sleep my system. I tried it in response to your post and the system immediately work up on its own. I'm not even going to give that a 2nd thought, or I might end up obsessing! To answer the question, it sometimes locks while unattended. Most of the time, it locks at the moment I close an app window (seen it most often in Safari and Mail.app). The 'lock' manifests by the system clock no longer advancing and being unable to manipulate anything on the screen except the mouse pointer. When the mouse pointer is hovering over the app that was active when the freeze occurred, the pointer changes to a spinning beach ball. 3. Apple's disk utility does support adding partitions. If you click the 'partition' tab, you'll see a + button below the partition layout image. Hover over the + button and it will describe its function. I've used that feature once, and it worked fine. However, I would never use it on a drive for which I don't already have a backup - I'm just paranoid that way. Hard drives are relatively cheap and my data is not replaceable. For cloning, I suggest Carbon Copy Cloner. It's not free, but it's awesome - dare I say, a must-have tool. Over the weekend I'm going to pull my 560 card and run off the Intel video for a few days. We'll see if the 560 really is related to the freeze. If I don't post a reply here, I'll update the thread where you originally found me. Cheers.
  5. Drat. I came home tonight and found that darn thing frozen again. The NVDA errors re-appeared in my logs around 5:38pm and continued until 8:52pm (10/11/13 8:52:24.000 PM kernel[0]: NVDA(OpenGL): Channel timeout!). I can't be sure that this is the cause of the problems, but I've read other posts about freezes related to the 560ti card. I was running this card in my x58 system on 10.7.5 for quite a while with no difficulties. Also annoying is that the Nvidia installer has a pref pane in which you can toggle between the Apple default drivers and the Nvidia web driver. I found that selecting the web driver and rebooting does nothing, it always returns to the OS X default driver. I'll keep looking into the video card as the root cause. If I have the energy, I may remove the 560 and run off the HD 4600 for a while. For now, I think I'll have a drink and watch some TV with the Mrs. Cheers.
  6. I temporarily switched my smbios identity from MacPro6,1 to MacPro5,1 so I could install the Nvidia drivers that are available on their web site. I'm still running as a MacPro5,1 for testing. I haven't seen a freeze, or any of the NVDA timeouts since this morning. I don't consider this a definitive success, but it's promising. A few notes: 1. I couldn't boot my system with the MacPro5,1 smbios unless I removed the AppleTyMCEDriver.kext from /S/L/E 2. The Nvidia driver installer will only run on systems defined as MacPro3,1 4,1 or 5,1. It may be possible to extract the kexts from the package and manually install them - I didn't try. 3. I'm running DSDT-free and do not currently have the HD 4600 enabled. I'll post back with any further developments.
  7. Hi mattsnowboard, This morning I installed the drivers available on the nvidia web site. It's been over 6 hours and I haven't seen any of these errors: 10/11/13 8:14:58.000 AM kernel[0]: NVDA(DMA): Channel exception! exception type = 0x1f = Fifo: MMU Error 10/11/13 8:15:18.000 AM kernel[0]: NVDA(OpenGL): Channel timeout! 10/11/13 8:15:38.000 AM kernel[0]: NVDA(OpenGL): Channel timeout! 10/11/13 8:15:58.000 AM kernel[0]: NVDA(DMA): Channel timeout! 10/11/13 9:27:52.000 AM kernel[0]: NVDA(Private): Channel timeout! You likely won't be able to run the installer with a iMac13,2 smbios. I'm currently running my machine as a macpro5,1, which is supported by the installer. Note that I couldn't boot as a MacPro5,1 until I removed the AppleTyMCEDriver.kext from /System/Library/Extensions. I can't say that 6 hours is a definitive win for my circumstances, but it's a pretty good run. Also, my scenario appears to differ slightly from yours. But, I wanted to give you something to try. Please make sure you clone your boot drive before changing anything so I don't feel any guilt if you hose your system following any of my advice. :-) Also, note that I am using GraphicsEnabler=Yes, and that I currently have the integrated Intel 4600 video disabled in the EFI/BIOS. Cheers.
  8. Are you seeing any of these in your system log: kernel[0]: NVDA(OpenGL): Channel timeout! kernel[0]: NVDA(Private): Channel timeout!
  9. Hi Acronator, Thanks for sharing your experiences with your Haswell build. I'm using the same board and CPU and have also experienced system freezes. My first noted freeze was during a wake from sleep. I've since set my system to not sleep and my drives to remain spinning and have not seen that specific freeze since (several days now). My other 'freeze' - which I've seen several times - I've only noted when closing a window in Safari. I'm curious if you've noticed any similar pattern. (update: I've now experienced the freeze on various other occasions. Nothing of use appears in the log files at the time of the freeze. I've tried with smbios.plist files defining my machine as a MacPro3,1 and 6,1. I'll try some others as Picasso suggests below) My install was done using a method from another site. I haven't reviewed the insanelymac forum rules in a while, so I'll leave out their name in case that's a violation. Suffice it to say, they use pre-built installers to get the job done. USB 2&3, Video (both discreet and integrated), Audio are all good. Only USB oddity is I have to connect my keyboard directly to a USB 2 port (off a header) to get my Apple keyboard recognized during POST. I disconnected my Bluetooth adapter after seeing a bunch of errors in the logs and after learning that a 10.8.5 supplemental update with a BT reference is forthcoming. I haven't delved deep into any of the power saving tech as yet (sleep, speedstep, etc). I'd be surprised if they are working as they should. I'll keep plugging away at the freeze problem and share anything of use. However, I have a feeling that ultimately I'll be installing 10.9 as the "fix." I'll share my /Extra plists for reference: smbios: <key>SMbiosdate</key> <string>06/12/13</string> <key>SMbiosvendor</key> <string>Apple Inc.</string> <key>SMbiosversion</key> <string>MP61.88Z.0099.B00.1306121724</string> <key>SMboardproduct</key> <string>Mac-F60DEB81FF30ACF6</string> <key>SMfamily</key> <string>Mac Pro</string> <key>SMmanufacturer</key> <string>Apple Inc.</string> <key>SMproductname</key> <string>MacPro6,1</string> <key>SMserial</key> <string>obfuscated</string> <key>SMsystemversion</key> <string>1.0</string> boot: <key>EthernetBuiltIn</key> <string>Yes</string> <key>GenerateCStates</key> <string>Yes</string> <key>GeneratePStates</key> <string>Yes</string> <key>GraphicsEnabler</key> <string>Yes</string> <key>Kernel</key> <string>mach_kernel</string> <key>Kernel Flags</key> <string>-v darkwake=0</string> <key>Legacy Logo</key> <string>Yes</string> <key>Timeout</key> <string>2</string> <key>UseKernelCache</key> <string>Yes</string> Regards.
  10. I can't help myself. Worse, your script makes it even easier. Cheers, Lyle
  11. For what it's worth... I have Lion on a drive for testing. I ran the 10.7.2 combo update with no problems. On reboot I noticed that my boot caches weren't loading (booting with each kext loading one-by-one). The system did startup ok after that. The boot cache issue was easily fixed by re-running the kext/kernel installer from the HackInstaller script. On my Lion drive, I'm using Chameleon v2.1svn r1625. No DSDT, no SleepEnabler.kext. I can post other config info if anyone needs it. Regards.
  12. Hey MAJ, Thanks for getting this out. Getting one of your new scripts is like getting new toys on xmas. I jumped right into the bootloader installer and ran the check for updates option. It found the r1544 update and appears to have downloaded and compiled it (per the "Chameleon_v2.1-RC5_change_log.txt" file). However, the Bootloader Installer page still lists it as... Current Chameleon bootloaders available to install: 2) Chameleon v2.1svn r1331:1449 - Current! (revertible to r1518) - Unofficial release. Most fully-featured bootloader. Lion OS support. Meanwhile, the Chimera version indicates that r1523 is available... 3) Chimera v1.5.4 r1394 - r1523 is available (revertible) The updater checks out 1523, but the scree reads as such after the update... 3) Chimera v1.5.4 r1394 (revertible) Subsequent update checks still show Chimera 1523 as available ("1 update available). --------------- On an unrelated note, if anyone attempts to use 6.0.6 after trying 6.5, they'll need to either avoid using the bootloader installer, or replace the com.apple.boot.plist file in /Extra. Since 6.5 deletes the legacy file, 6.0.6 will silently toss the contents of /Extra and create a new folder. Cheers.
  13. I keep forgetting to mention this in regards to editing the boot.plist file without the benefit of MAJ's Hackinstaller script. I assume most of you know about the Chameleon.prefPane. But, just in case you don't... I'm sure it's posted somewhere for easy download, but I get mine from the Chameleon sources HERE. Once you've downloaded and compiled, the pref pane is located in this path: ~/chameleon/trunk/package/Configuration/PrefPanel/ Chameleon.prefPane let's you define the location/name of your boot.plist (Boot Setup:Boot Config Path). Once defined, you can do most of the edits within the lovely GUI. Cheers, Lyle
  14. If you do run a current bootloader and HackInstaller 6.06, be careful installing a new bootloader with the script. If you've removed the com.apple.Boot.plist file to avoid the deprecation warnings during boot, the script will create a new Extra folder - possibly missing some things you really need to boot! When I'm working with the script, I do a: sudo mv /Extra/org.chameleon.Boot.plist /Extra/com.apple.Boot.plist to change the name of the file and make the script happy. When I'm done with the script, I do: sudo mv /Extra/com.apple.Boot.plist /Extra/org.chameleon.Boot.plist to make Chameleon happy on the next boot. Cheers.
  15. My pleasure. To all, Has digital_dreamer's script made your hackintosh experience better? Has it saved you gobs of time? Consider a DONATION!
×