Jump to content

adhir

Members
  • Content count

    15
  • Joined

  • Last visited

About adhir

  • Rank
    InsanelyMac Protégé
  1. Slow Hard Drive Performance ICH10

    I can confirm this worked on my P6T in Leopard. Bravo!
  2. Slow Hard Drive Performance ICH10

    I am seeing the same slow behavior on secondary sata ports behavior on my P6T, and can confirm that "IOPCIMSIMode" is indeed True on my board -- this is on Leopard. Haven't moved to Snow yet. I had messed with this several weeks back quite a bit, and had also come to the conclusion that it was a PCI/Interrupt related problem, likely due to the way the BIOS was initializing the SATA ports. Your findings support that theory. Eventually I worked around it by connecting my secondary drive to the JMicron controller. On another machine with the same motherboard and OS version, which is booted into a state where secondary drives are working fine, I can confirm that the IOPCIMSIMode is NOT "True". Both machines are Asus P6T, Core i7 920, running 10.5.8. The second machine has 1333 speed RAM in it, which, when run at 1083Mhz (180 BCLK, 3.6Ghz CPU), tends not to have the slow sata problem. However, if I boot that machine with the RAM at 14xx mhz, same BCLK, the problem tends to occur. When I noticed this, I did not know about this ioreg business. I will try messing with that machine a bit to see if I can reliably cause the problem to occur and whether it displays this IOPCIMSIMode characteristic. Thanks for your research. I'll respond with additional findings later. That was as far as I had gotten
  3. I have the same issue with my 500G + 1TB drive set. To get around it, I disabled the 1T drive in the BIOS, so it's not "visible" to the bootloader during boot process. After OSX boots, the partitions on the 1T drive show up fine. This is obviously less than optimal, since I can't boot OS's installed on the 1T drive...
  4. This is solved by installing Chameleon V2 bootloader (confirmed by a handful of people including myself).
  5. I believe I've solved this by disabling Intel VT-d in the BIOS. Please test and report back.
  6. I can confirm the same issue with the standard P6T, non deluxe, on 2nd HD plugged into SATA2 and Optical drive in SATA3. Looks like IRQ issues, but I haven't been able to find/resolve yet. You?
  7. 9.6.3 Kernel for Core i7

    SOLVED. I installed Chameleon V2 RC1 and the clock issue is gone. Thanks all!
  8. 9.6.3 Kernel for Core i7

    I have the same issue - Asus P6T, i7 920. Running pc_efi_v9, not Chameleon v2 RC1. 3 sticks of 1066 crucial RAM in triple channel. I've tried removing overclock, changing fsb value in boot flags, turning various BIOS options on/off, changing kernel from 9.7 to 9.63, all with exact same result. Would people who do not have the fast clock issue please post their configurations? 1) are you using chameleon 2? 2) what is your ram speed - 1333 or 1066? how many sticks? 3) any smbios injector/alternative installed? 4) anything else which sounds like it could be related? Thanks
  9. Clock running too fast

    Did you ever resolve this? I'm seeing the same thing on a P6T with an i7 920. On this system, the clock is fast even with no overclock. This occurs with both kernel versions 9.6.3 and 9.7.0.
  10. I installed from a copy of iatkos 5i I have sitting around, which uses pc_efi_v9, with the Extra folder. I am not using the EFI partition stuff.
  11. FWIW - I also have the fast clock problem on my P6T (non deluxe) w the 920 chip. This is with the 9.7.0 9j56 kernel and associated System.kext. I've tried with and without various levels of overclocking with no change. I also get these messages repeatedly in the system.log: Apr 29 16:13:28 dante kernel[0]: WARNING: AppleUSBAudio has detected that clock_get_uptime () value changed radically from previous values My suspicion is that that's related to the clock timing being off. I have tried booting with a correct value of fsb= in the kernel flags. I've also verified that the machines is correctly detecting the proper value by looking at the output of "sysctl hw.busfrequency" - take what you get from that and divide by 4,000,000 (4 million), and you'll get what you have your BCLK set to in your BIOS. Let me know if you get anywhere with this.
  12. This really isn't a kext -- it just adds entries to the Main AppleAHCIPort Info.plist -- there is no binary code whatsoever. Adding those entries allows the stock AppleAHCIPort to be used with the controllers/models listed in the Info.plist file.
  13. This is a modified version of the LegacyAppleAHCIPort.kext at netkas.org with all the missing ICH* entries that I'm aware of. This allows the use of a stock AppleAHCIPort.kext. Tested on a Dell Vostro 400 in AHCI mode which is otherwise very picky. This can solve "still waiting for root device" for many people. LegacyAppleAHCIPort.kext.zip
  14. Leopard benchmark results

    wow! how'd you get the q6600 to 3.6 -- what kind of cooling/etc?
  15. P5k3 Leopard Install Guide

    Good stuff -- didn't need to use it, but glad to see others are having success with it. I have a P5K-E Wifi/AP -- very similar board to the one this patch was made for. Few remaining issues I'm trying to figure out - wondering if you're having them as well: 1) My onboard USB ports don't work -- back ones on the mobo work fine. But since the ports on the motherboard are what are connected to my front usb ports on my case, it would be nice to have them work... In Tiger 10.4.10 they worked most of the time -- some reboots they wouldn't work, I'd just reboot again, and they'd be fine again. I know there were others having this issue on these boards so I'm sure it's not a hardware issue (ports work fine in Vista). 2) I have an occasional Finder freeze - it's very strange. All apps continue to work fine, but Finder won't start any new programs, it shows as 'stopped responding', and I can't force quit it. When this happens, I have to hit the reset button as even the reboot/shutdown commands fail to work. Has anyone else seen this? 3) _CFGetHostUUIDString: unable to determine UUID for host. Error: 35 -- happens very frequently in system.log or in terminal during various operations. Very common, but very annoying. You seen this? Thanks
×