Jump to content
Welcome to InsanelyMac Forum

Register now to gain access to all of our features. Once registered and logged in, you will be able to contribute to this site by submitting your own content or replying to existing content. You'll be able to customize your profile, receive reputation points as a reward for submitting content, while also communicating with other members via your own private inbox, plus much more! This message will be removed once you have signed in.


  • Content count

  • Joined

  • Last visited

About pharillion

  • Rank
    InsanelyMac Protégé
  1. Thanks for the clarification on the Internal speakers / lineout reversal. Lineout back (green, as IntSpeaker) YES HP front (black, SwitchMode, if plugged in) YES Internal speaker (as lineout) YES Mic back (pink) YES - as Upper Internal Microphone in Sound Prefs Input Mic front (black) YES - as Lower Internal Microphone in Sound Prefs Input LineIn back (blue) YES In short everything works exactly as it should, for which many thanks once again.
  2. Hmm, as I suspected the skeletal device names shown in System Profiler were entirely my fault! I'd grabbed the latest 10.13.2 AppleHDA.kext from my archive in too much of a hurry and it must have been a partial file from the 10.13.2 delta update and thus incomplete. Once I checked the size and then replaced it with the full 10.13.2 AppleHDA.kext from another machine all the device names returned to normal. This was simply my own incompetence and nothing to do with MacPeet's excellent trial AppleALC.
  3. Thank you very much MacPeet. With this new trial version sound certainly works well with HS 10.13.2 and its original AppleHDA.kext. In my earlier post I had forgotten to say that I was using your earlier test version with Codec Commander, and I'm using it still with this latest version. I do seem to have one issue in that System Profiler is now displaying the audio device names incorrectly. I don't remember this happening with the earlier test version. The last entry is my ESI Juli@ sound card. Perhaps I've done something wrong here as I note bilbo reported the same Internal Speakers / Line out reversal as with the earlier patched AppleHDA.kext I'd like to encourage more volunteers to help test this useful addition so that it may be properly validated and I hope added to the official AppleALC release. Thanks again,
  4. That would be terrific, thank you very much indeed. I'd be more than happy to test a new trial version for High Sierra and I'm sure many of us here would appreciate it. Thanks again,
  5. Forgive me for coming late to this discussion but for a short while I was successfully using a test version of AppleALC version 1.1.2 with modifications for the HP z400/600/800 ALC262 codec by MacPeet and generously provided by him as Archiv.zip in post #1042 of this thread. This was on my z400 running High Sierra 10.13.1 so I needed the -alcbeta boot flag. Initially it was paired with Lilu 1.1.5 and so -lilubeta was required, but later I used Lilu 1.1.7 which didn’t need the beta flag. Layout ID 28 in dsdt is also necessary. On reaching the betas of 10.13.2 and 10.13.2 itself then older versions of Lilu would no longer load while the new Lilu 1.2.1 is no longer compatible with AppleALC versions as old as 1.1.2. At this point I had to revert to a patched AppleHDA.kext like the one Rockey12 has kindly posted above, since MacPeet’s excellent changes to AppleALC for our ALC262 were I think inteded for testing only and so were never incorporated into vit9696’s official AppleALC sources. Can I first of all thank MacPeet for his work and also suggest that if he approves his code might be submitted to vit9696 for inclusion into the official AppleALC distribution? That way it should conitnue to work with future High Sierra releases on all our HP z400/600/800 workstations.
  6. 10.9 GM Released.

    Yes, I know that unsigned kexts will load from /S/L/E, however I'm drawing a distinction between unsigned kexts and kexts signed with an identified Developer Id which is not Apples. I do not believe that these will load from /S/L/E, I think that for them to load they must be in /Library/Extensions. I would say that this is a distinct possibility for the long term. However I imagine that Apple will encourage developers to sign their kexts and have them loaded from /Library/Extensions.
  7. 10.9 GM Released.

    If I look at the list of Extensions from System Profiler I see that a couple of "Not Signed" kexts including Andy's AnyAppleUSBMouse.kext are listed as being "not loaded" although in fact they are being loaded. Other "Not Signed" kexts such as FakeSMC.kext are listed as being loaded. The same version of Andy's AnyAppleUSBMouse.kext is listed in the Info.plist of AppleKextExcludeList.kext, as too is FakeSMC.kext but of course I edited the Info.plist of AnyAppleUSBMouse.kext when I added my own Mouse IDs. Looking at /S/L/caches/com.apple.kext.caches/Startup I see some interesting .plist files: excludedkextalert.plist loadedkextmt.plist invalidsignedkextalert.plist All of these start with "Alerts sent" and contain more or less what would be expected. The latest version of Little Snitch 3 for Mavericks has its signed .kext in /Library/Extensions and not /S/L/E Am I right in thinking that Mavericks will load unsigned .kexts in /S/L/E with a warning but that non-apple signed .kexts will only be loaded from /Library/Extensions? Without wishing to be too alarmist I'm guessing that eventually, perhaps by 10.10 Syrah, /S/L/E will be read-only and third-party .kexts will need to be signed with a developer ID and loaded from /Library/Extensions. It will be interesting to see how this progresses.
  8. No Hard Drives

    It should do, at least if my experience is anything to go by. Good Luck
  9. No Hard Drives

    Shouldn't the Generic AHCI entry match on class code here? System Profiler detail is often largely cosmetic, although there are SATA injector .kexts for specific chipsets. In this same Dell Precision 690 I have a Marvell eSATA card which is normally picked up as GenericAHCI but I've injected correct details into a legacy .kext residing in /S/L/E: <key>Marvell 88SE9123</key> <dict> <key>CFBundleIdentifier</key> <string>com.apple.driver.AppleAHCIPort</string> <key>Chipset Name</key> <string>88SE9123</string> <key>IOClass</key> <string>AppleAHCI</string> <key>IOPCIClassMatch</key> <string>0x01060100&0xffffff00</string> <key>IOPCIPrimaryMatch</key> <string>0x91231b4b</string> <key>IOProbeScore</key> <integer>15000</integer> <key>IOProviderClass</key> <string>IOPCIDevice</string> <key>Vendor Name</key> <string>Marvell</string> </dict> I think I'm right in saying that the Info.plist in DP3 AppleAHCIPort.kext and that for DP2 and earlier are identical, however my suspicion is that the binaries may not be - unless the difference is somewhere else in the AHCI disk chain. I no longer have DP2 or DP1 installed to diff and check.
  10. No Hard Drives

    Hi, I had the problem of missing SATA hard drives with 10.9 on a Dell Precision 690 which uses an ESB2 SATA controller. This runs ML very well but on my initial installation attempt with 10.9 DP1 Disk Utility would see no SATA hard drives. I did manage a successful installation of 10.9 DP1 onto a USB HDD and also using the onboard LSI SATA/SAS chipset after modifying AppleLSIFusionMPT.kext. Looking with IORegistryExplorer, AppleAHCIPort.kext would attach to the ESB2 SATA but never show any disks. Upgrading to DP2 made no difference, and I spent a while adding "compatible" and "name" flags to the ESB2 SATA entry in my DSDT but to no effect. Rolling back to the 10.8.4 AppleAHCIPort.kext also didn't help. Upon upgrading to DP3 suddenly the ESB2 HDDs became visible exactly as in ML. Thus I think that this is probably the consequence of a bug in DP1 and DP2 which Apple have fixed in DP3. I would suggest that anyone with this problem installs on USB and upgrades to DP3 or beyond. Their SATA drives should then appear and it should be possible to clone the 10.9 installation across. Good Luck,
  11. Hello, I have just got hold of a Dell Precision 690 workstation (BIOS A08) with Intel 5000x chipset and two Xeon 2GHz dual-core 5130 CPUs which in hardware terms is pretty close to a MacPro1,1 although x64_86 capable. I obtained the DSDT under Linux and patched IRQs as recommended here so that the 631xESB SATA became visible, while adding pci1000,54 to AppleLSIFusionMPT.kext gets the onboard SAS controller recognised. Unfortunately the DSDT linked http://www.insanelym...e=post&id=62571 seems no longer accessible, so I'd be very pleased to hear from other Precision 690 users especially if they are prepared to share their DSDT which is bound to be better optimised than mine. Thanks in advance to anyone prepared to help me here. originaldsdt.zip dsdtpatched.zip ioreg_dump.zip I've installed Snow Leopard and Lion on different disks with some success, getting the Nvidia Quadro FX 4600 recognised with an appropriate efi string. There's Broadcom BCM5752 gigabit ethernet onboard but I've almost given up on this with anything after Leopard given that I'd prefer to use SL or Lion in x64 mode. I've added in a PCI-E Marvell 88E8053 card which provides ethernet, again via an efi string. There are still a number of problems however, an annoying one being that versions of chameleon plus an appropriate smbios.plist seem unable to set suitable MacPro1,1 information. On booting I get a string of messages indicating that the DMI table entries list is full and cannot be added to. Under SL I can sometimes get Chameleon SMBIOS defaults loaded without any smbios.plist but under Lion the Dell dmi information comes through unchanged. Would using an older smbiosenabler solution help? Even with the latest Chameleon r1718 (r1701 and later have additional support for Xeon processors) then adding GeneratePStates and GenerateCStates to org.chameleon.Boot.plist provokes a reboot as soon as the file is read, so in the absence of any speedstep support in DSDT I'm required to use a disabler for AppleIntelCPUPowerManagement.kext. AppleLPC.kext does load. Another perplexing problem is wireless. I've tried three hack-compatible wireless cards, one PCI-E Atheros AR5008 (168c,024) and two Broadcom 43xx PCI cards. Each of them works OTB in my other self-built hack. On the 690 they are all seen in IOREG but none work - no Airport card is seen. The appropriate .kext for each can be loaded by hand but this doesn't help, nor can I change anything by editing /Library/Preferences/SystemConfiguration/NetworkInterfaces.plist. Could this be related to the Dell information not being overridden by the ignored smbios.plist? Yet another problem is that the USB2 ports are listed as Expansion Card rather than built-in. This leads to the classic "AppleUSBEHCI CheckSleepCapability - controller will be unloaded across sleep" message. I thought I knew how to patch this with "AAPL clock-id" but the original DSDT is so unlike anything I've seen before that I can't even reliably identify the USB2 ports! The DSDT is also full of non-Mac entries for parallel port, PS/2 keyboard and mouse, floppy and so on. I'm sure ditching some of these would probably help but I'd be very grateful for specific advice from some of the DSDT experts here. Phew, quite a marathon post. Thanks to those with the patience to read thus far and especial thanks to anyone kind enough to offer help. As ever I'm grateful to the community here.
  12. Thank you ApexDE. I wish I had enough skill to do this properly. Unfortunately all my attempts to cut down my JMB0 and JMB1 device entries or even just to match my JMB0 device with the example given by THe KiNG just seem to produce lots of compilation errors and therefore no working dsdt.aml. Of course I'll keep trying, and continue my reading on ACPI and dsdt syntax, but really I think I'm rather out of my depth. Removing almost anything from my existing and over-long Device (JMB0) entry seems to result in an error! Thanks again.
  13. Thanks, yes, I should have explained better. The only JMicron kext I have loaded is a cosmetic "legacy" one which simply changes "Unknown AHCI Controller" as reported by the standard AppleAHCIPort.kext to "JMicron JMB36x AHCI Controller". Without this loaded the same problems exist. I'm using a pure eSATA case with no USB - the external eSATA connection goes straight to the drive backplane connector. This wasn't particularly expensive but I've had it working on Intel ICH10 and SiI 3132 without problems under Leopard. Thanks again for your help. Thanks THe KiNG (and ApexDE too), that's very helpful. I will try adding something following your dsdt code example and report back. Something I have noticed is that with drive(s) mounted on the JMicron controller, either in AHCI/eSATA or IDE mode, NCQ is reported as "No" or unsupported. I wasn't expecting this in AHCI mode.
  14. from console.log 29/10/2009 23:39:01 kernel hfs_swap_HFSPlusBTInternalNode: unrecognized catalog record type (0x000A; record #6) 29/10/2009 23:39:01 kernel hfs: node=15502 fileID=4 volume=eSATA device=/dev/disk2s2 29/10/2009 23:39:01 kernel hfs: Runtime corruption detected on eSATA, fsck will be forced on next mount. 29/10/2009 23:39:01 kernel hfs: FindNextLeafNode: Error from hfs_swap_BTNode (node 15502) 29/10/2009 23:39:08 mdworker[316] (Error) SyncInfo: searchfs error (Result too large) -- falling back to fsw search /Volumes/eSATA I've had unexplained hangs and slowness on two different disks connected to the JMicron controller in AHCI mode, but both disks work correctly when in IDE mode without the DSDT patch. Turning on the eSATA/AHCI disk after boot and allowing it to automount seems to work better. I restored a bootable SuperDuper! disk image to an external disk connected to the JMicron controller in IDE mode and booted successfully from this. The same disk connected to the JMicron controller in AHCI mode would not boot and eventually hung with many disk I/O errors. I'm glad your controller is working in AHCI mode without problems.
  15. Hmm, unfortunately it seems I may have spoken too soon. Any disk connected to the JMicron controller ports in AHCI/eSATA mode seems fine to begin with but gradually accumulates errors which fsck and other utilities cannot repair. If I revert to IDE non-removable mode with the same disk(s) and cabling after removing the dsdt patch and replacing LegacyJmicronAHCI.kext with JMicronATA.kext, such errors no longer accumulate. I suspect I may have to go back to IDE mode for stability. I hope my problem is an isolated one and therefore doesn't cause problems for other users adopting this innovative dsdt patch. Best regards,