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 mikeraffone

  • Rank
    InsanelyMac Protégé
  1. The HDA patcher doesn't work for me, after an update to 10.7.5 Upon running, it gets to the "Registering updated components" stage, and then fails. It says: Unexpected codec range match count: 0, 4 expected Aborting with AppleHDA NOT patched I'm trying to patch AppleHDA.kext version 2.2.5 Any ideas? Mike P.S. Thanks for your amazing work on disabling the co-processor. My G210m is now disabled.
  2. Hi all, After updating to 10.7.3 (from 10.7.2) my graphics through the HDMI out flickers and judders. It's pretty unusable. I see that the following files have been updated in the new version: System.kext IOPCIFamily.kext IONDRVSupport.kext IOGraphicsFamily.kext I'm going to try downgrading those kexts (except System.kext) to 10.7.2 versions and let you know how I go. But, bcc9 (or anyone else) would you have a more elegant solution than just using old versions of kexts? Is this a problem you're having as well? Cheers, Mikeraffone EDIT: I should say I'm running the XPS1340 version with g210m and onboard 9400m. The g210m isn't functioning or recognised. Instead of using graphicsenabler=yes (which couldn't handle two cards at once and kernel panicked) I have taken the DSDT injection from bcc9's 10.6 solution and implemented them in my 10.7 DSDT. So as it is, the 9400m was working perfectly under 10.7.2 - but now it's like there is a problem with the frame buffer or something. EDIT: GROAN! After a little too-ing and fro-ing I realised what it was. Nothing to do with the system kexts at all. The Display Settings had defaulted to 1080i for some reason, instead of 1080p - which my monitor needs. It was as simple as changing settings in System Preferences. Please ignore me.
  3. So I managed to set it onto hibernatemode (was using secure virtual memory) but found that it didn't work. It wouldn't resume from hibernate, saying something about "not enough disc space" which is nonsense. bcc9: are you using secure virtual memory when you hibernate successfully (pmset mode 5) or just the usual (pmset mode 1)?
  4. Hmmm, no, my xps doesn't seem to be hibernating then, its only in suspend. I have the latest chameleon rc5 from your previous post. hibernatemode is set to 1. any thoughts?
  5. the voodoosdhc 64bit kext doesn't work, system hangs on card insertion ... but I don't know that this driver has been updated in a while. Where do you see the newer kexts and I'll test some out? My firewire works after resume from hibernate. Although, is there anyway to verify that it IS actually hibernating and not just sleeping? My pmset hibernatemode is set to 1 - anyone heard of macs set to hibernate but only sleeping instead?
  6. Actually, that's not true. The problem has occurred again. Is anyone else having issues with e-SATA drives disconnecting after a period of inactivity?
  7. bcc9: have you experienced any problems with your bluetooth HCI device occasionally freaking out the system? This may be a tenuous link - but I installed your bluetooth HCI driver on a new xps system with the device installed - and I have experienced a problem with the external SATA now ... where after 5-10 mins of usage, the device fails to read, stalls, and forces a dismount. Here is the console log: Jul 27 08:49:20 Michael-Clays-Mac kernel[0]: disk1s2: media is not present. Jul 27 08:49:24: --- last message repeated 1 time --- Jul 27 08:49:20 Michael-Clays-Mac kernel[0]: jnl: disk1s2: do_jnl_io: strategy err 0x6 Jul 27 08:49:20 Michael-Clays-Mac kernel[0]: jnl: disk1s2: write_journal_header: error writing the journal header! Jul 27 08:49:20 Michael-Clays-Mac kernel[0]: disk1s2: media is not present. Jul 27 08:49:20 Michael-Clays-Mac kernel[0]: jnl: disk1s2: do_jnl_io: strategy err 0x6 Jul 27 08:49:20 Michael-Clays-Mac kernel[0]: jnl: disk1s2: end_transaction: only wrote 0 of 40960 bytes to the journal! Jul 27 08:49:20 Michael-Clays-Mac kernel[0]: disk1s2: media is not present. Jul 27 08:49:52 Michael-Clays-Mac kernel[0]: Failed to issue COM RESET successfully after 3 attempts. Failing... Jul 27 08:50:23 Michael-Clays-Mac kernel[0]: Failed to issue COM RESET successfully after 3 attempts. Failing... Jul 27 08:50:23 Michael-Clays-Mac kernel[0]: IOBlockStorageDriver[IOBlockStorageDriver]; executeRequest: request failed to start! Jul 27 08:50:23 Michael-Clays-Mac kernel[0]: disk1s2: resource shortage. Jul 27 08:50:23 Michael-Clays-Mac kernel[0]: disk1s2: media is not present. Jul 27 08:50:23 Michael-Clays-Mac kernel[0]: jnl: disk1s2: close: journal 0xffffff8011feed20, is invalid. aborting outstanding transactions I have just uninstalled the HCI driver and the problem appears to have disappeared (it also never occurred prior to installing the HCI driver). What do you think the cause might be?
  8. I assume he means aserebln 1.9 - see here: http://wiki.github.com/aserebln/Chameleon/
  9. Here is the oireg entry for XVR4 | | | +-o Z01N@0 <class IOPCIDevice, id 0x1000001be, registered, matched, active, busy 0 (16632 ms), retain 9> | | | { | | | "assigned-addresses" = <1000068200000000000040f00000000000400000> | | | "IOInterruptSpecifiers" = (<1700000007000000>,<0000000000000100>) | | | "class-code" = <00800200> | | | "IODeviceMemory" = (({"address"=0xfffffffff0400000,"length"=0x4000})) | | | "IOPowerManagement" = {"CurrentPowerState"=0x2} | | | "subsystem-vendor-id" = <28100000> | | | "built-in" = <00> | | | "acpi-device" = "IOACPIPlatformDevice is not serializable" | | | "IOInterruptControllers" = ("io-apic-0","IOPCIMessagedInterruptController") | | | "name" = "pci14e4,4353" | | | "IOChildIndex" = 0x1 | | | "device-id" = <53430000> | | | "vendor-id" = <e4140000> | | | "IOPCIExpressASPMDefault" = 0x3 | | | "acpi-pmcap-offset" = 0x40 | | | "compatible" = <706369313032382c6500706369313465342c3433353300706369636c6173732c30323830303000> | | | "IOPCIResourced" = Yes | | | "IOPCIExpressLinkCapabilities" = 0x176c11 | | | "acpi-path" = "IOACPIPlane:/_SB/PCI0@0/XVR4@160000/Z01N@0" | | | "subsystem-id" = <0e000000> | | | "revision-id" = <01000000> | | | "IOPCIExpressLinkStatus" = 0x3011 | | | "IOName" = "pci14e4,4353" | | | "acpi-wake-type" = 0x2 | | | "reg" = <00000600000000000000000000000000000000001000060200000000000000000000000000400000> | | | } The driver lists as being loaded ... or at least, the kextload command works successfully, and the driver reports itself in kextstat. What do you think? There isn't a child entry for the card itself, below that. Even though the kext has loaded. Strange.
  10. lspci finds the device as Broadcom unknown device (14a4:4353) PCI\VEN_14E4&DEV_4353&SUBSYS_000E1028&REV_01 And 4353 should be recognised in the AppleAirportBrcm43224 kext - it exists in the plist without needing to be added. There is some sort of problem where the computer does not recognise the device - even a dummy kext does not work. What do you think we dell wiresless 1520 people can do about this, short of buying another card?
  11. bcc9, you're probably going to hate this question, but where in your fixed.dsl file can i put a wireless injection? I have an injection script for dell wireless 1520, which runs on broadcom 4353, but its too new to be picked up by os x automatically (device unknown). Everywhere I try to put the inject code, a get a syntax compiler error... This is the code I'm looking to insert: Device (ARPT) { Method (_DSM, 4, NotSerialized) { Store (Package (0x12) { "AAPL,slot-name", Buffer (0x08) { "AirPort" }, "device-id", Buffer (0x04) { 0x53, 0x43, 0x00, 0x00 }, "vendor-id", Buffer (0x04) { 0xE4, 0x14, 0x00, 0x00 }, "subsystem-id", Buffer (0x04) { 0x87, 0x00, 0x00, 0x00 }, "subsytem-vendor-id", Buffer (0x04) { 0x6B, 0x10, 0x00, 0x00 }, "name", Buffer (0x0D) { "pci14e4,4353" }, "model", Buffer (0x13) { "Dell Wireless 1520" }, "device_type", Buffer (0x08) { "Airport" }, "built-in", Buffer (One) { 0x00 } }, Local0) DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0)) Return (Local0) } }
  12. Do you think the kernel panic is because our standard installs of os x do not include the needed kexts to deal with switching between the onboard and the extra GPU? Perhaps if we could work out a way to implement the parts of the Macbook Pro Software Update 1.3 - released 13 April 2010 (http://support.apple.com/kb/DL1026) that deal with the "automatic graphic switching" between the onboard 9400m and the GT330m on the late model macbook pros, then it wouldn't kernel panic? Surely if it supports both devices natively, the problem is that they're clashing, even though perhaps they don't have to?
  13. Thanks, starting to get my head around this now. The computer has both the onboard 9400m and the added g210m. Apparently the g210m is supported via chameleon flagging graphicsenabler=yes (I'll confirm this later today, doing a clean reboot to test). If it does work with graphicsenabler, running off the native support in osx for the device - do you think I'd be able to install the 9400m via the dsdt injector, and the g210m via the chameleon injector, at the same time - or would they clash?
  14. That's what I hoped, but bcc9's dsdt doesn't have an obvious place for that change, there is no "VRAM,totalsize" string to modify. I have found this DSDT modification for the 210m, which I believe may work, I'm trying to bring them together, but having difficulty (i'm not awesome at this): Device (PEGP) [indent] { Name (_ADR, 0x00010000) Device (GFX0) { Name (_ADR, Zero) Name (_SUN, One) Method (_DSM, 4, NotSerialized) { Store (Package (0x18) { "@0,compatible", Buffer (0x0B) { "NVDA,NVMac" }, "@0,device_type", Buffer (0x08) { "display" }, "@0,name", Buffer (0x0F) { "NVDA,Display-A" }, "@0,AAPL,boot-display", Buffer (0x04) { 0x01, 0x00, 0x00, 0x00 }, "@1,compatible", Buffer (0x0B) { "NVDA,NVMac" }, "@1,device_type", Buffer (0x08) { "display" }, "@1,name", Buffer (0x0F) { "NVDA,Display-B" }, "NVCAP", Buffer (0x18) { /* 0000 */ 0x04, 0x00, 0x00, 0x00, 0x00, 0x00, 0x09, 0x00, /* 0008 */ 0x06, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x07, /* 0010 */ 0x00, 0x00, 0x00, 0x00 }, "VRAM,totalsize", Buffer (0x04) { 0x00, 0x00, 0x00, 0x20 }, "device_type", Buffer (0x0D) { "NVDA,GeForce" }, "model", Buffer (0x13) { "NVIDIA GeForce 210" }, "rom-revision", Buffer (0x0F) { "70.18.2D.00.A3" } }, Local0) DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0)) Return (Local0) } } [/indent]
  15. Hi, I've been running an SL vanilla on my XPS 1340 for quite some time now, thanks largely to the efforts of those people on this forum (bcc9 and pmcnano and others) - so cheers! I have a question: I'm migrating my system over to another XPS 1340, the only difference is instead of the nvidia geforce 9400m, i have the NVIDIA GeForce 210M 512MB do you know if your DSDT will get QE/CI working on this graphics card, and if not, how do I go about modifying it, so it will? _Mike