rockinron_1 Posted September 21, 2012 Share Posted September 21, 2012 So after 10.8.2 update I get this error during verbose boot: If i boot -x everything works as expected but I have no idea what this vtd fault is. Things I have tried: Latest version of chameleon Roll back the 4 kexts that got updated during the update Fix permissions Reinstall the update from combo Removed all devices possible I may be on the wrong lines completely but the only reference I have found to vtd is Intel's virtualization technology so I disabled that in the BIOS as well. Clean install on a different drive. But I get the same vtd error every time, I managed to get rid of the AGPM unknownplatform at one point but that was after I took the screnshots. Only thing I haven't tried is having a look at core graphics framework which I believe got updated but I've never paid much attention to the updates until now. Only extra kext is FakeSMC and I'm using DSDT+SSDT with a vary basic org.chameleon.boot.plist and iMac 12.2 smbios. I've had my extra folder the same way since Lion and never had any problems. System is desktop 1 in my sig, any help much appreciated. Link to comment Share on other sites More sharing options...
p.H Posted September 21, 2012 Share Posted September 21, 2012 turn off vt-d in your bios or uefi. Link to comment Share on other sites More sharing options...
rockinron_1 Posted September 21, 2012 Author Share Posted September 21, 2012 No setting for it, only for virtualizartion which I've already tried to disable Link to comment Share on other sites More sharing options...
rockinron_1 Posted September 21, 2012 Author Share Posted September 21, 2012 Solved by rolling back AppleAPCIPlatform although I'm not sure why ATM. Link to comment Share on other sites More sharing options...
dukzcry Posted October 26, 2012 Share Posted October 26, 2012 2 rockinron_1:Apple is working on VT-d, they added some code to IOPCIFamily which plays more or less nicely on real Macs, but deal shortly with hackintoshes. If you can't disable VT-d option in BIOS, you're forced to use rollbacked AppleACPIPlatform (until this solution works, this will stop eventually with some update) since that.Any IOMMU hackers there to fix their code? I got some progress doing modifications (https://raw.github.c.../patch-AppleVTD) to the code, but didn't get much success. To play with that code, you'll need install IOKit private headers. See: [1]. 1 Link to comment Share on other sites More sharing options...
eep357 Posted October 26, 2012 Share Posted October 26, 2012 A shot of penicillin should clear that up for ya 1 Link to comment Share on other sites More sharing options...
bcc9 Posted November 12, 2012 Share Posted November 12, 2012 I ran into this same problem with vt-d when I upgraded to 10.8.2. That is, the system never brings up the login window, instead filling /var/log/system.log with errors such as: Nov 11 22:44:46 xs-MacBook-Pro.local ReportCrash[74]: failed looking up LS service ( scCreateSystemService returned MACH_PORT_NULL, called from SetupCoreApplicationServicesCommunicationPort, so using client-side NULL calls. Nov 11 22:44:46 xs-MacBook-Pro.local ReportCrash[74]: LaunchServices/5123589: Unable to lookup coreservices session port for session 0x186a0 uid=0 euid=0 Nov 11 22:44:46 xs-MacBook-Pro com.apple.launchd[1] (com.apple.loginwindow[124]): Job appears to have crashed: Bus error: 10 Nov 11 22:44:46 xs-MacBook-Pro com.apple.launchd[1] (com.apple.loginwindow): Throttling respawn: Will start in 10 seconds Nov 11 22:44:46 xs-MacBook-Pro.local ReportCrash[74]: Saved crash report for loginwindow[124] version 8.2 (8.2) to /Library/Logs/DiagnosticReports/loginwindow_2012-11-11-224446_xs-MacBook-Pro.crash unless one boots without a kernel cache. In my asus uefi bios, there is 'Intel Virtualization Technology' which can be enabled or disabled, but the problem remains when I boot using a kernel cache. I still use chameleon, and DropDMAR is in the andyvand branch but not the trunk. I merged DropDMAR support into the trunk and built a new /boot image, here: boot.2117.dmar.zip Unzip, and replace /boot with this new version. Also add <key>DropDMAR</key> <string>Yes</string> to your /Extra/org.chameleon.Boot.plist. This solves the immediate boot problem. I assume this breaks direct hardware DMA support in virtual machines under osx, so perhaps the next step would be to figure out what the difference is between a genuine mac's DMAR table and hackintoshes. Also, my source code diffs for chameleon are:diffs.txt 3 Link to comment Share on other sites More sharing options...
bcc9 Posted November 15, 2012 Share Posted November 15, 2012 Or by doing very simple modification to IOPCIFamily, like one i suggested. There is no need for one to cure that new Apple's VT-d kernel code, unless you're interested in protection from DMA unlocking attacks. I wouldn't want to have to maintain such a patch across every OSX update that changes IOPCIFamily (most of them), so I think addressing the DMAR table is preferable.I think the goal should be to have one's hardware work like a genuine mac, so figuring out what the underlying difference here is worthwhile. Link to comment Share on other sites More sharing options...
dukzcry Posted November 15, 2012 Share Posted November 15, 2012 It causes problems even on "genuine mac" :-) Proofs: [1] [2].If you're about spoofing actual DMAR table (by using DMAR.aml) - that's a bad idea, if you wish to keep PCI passthrough working in VM solutions or have I/O going through the IOMMU (DMA and MSI remapping). Link to comment Share on other sites More sharing options...
bcc9 Posted November 15, 2012 Share Posted November 15, 2012 It causes problems even on "genuine mac" :-) Proof: https://discussions....tart=0&tstart=0 . If you're about spoofing actual DMAR table (by using DMAR.aml, will be added to Clover loader soon) - that's a bad idea, if you wish to keep PCI passthrough working in VM solutions. In that other thread, I don't see anyone figuring out what's really going on. I think the presumption is that a disk drive is timing out leading to the DMA timing out. Not the same problem as we're having. I was not alluding to spoofing a DMAR table. Dynamically fixing whatever issue OSX is having with the table is what I had in mind, but that's just an initial guess at what the fix might be. Depends upon what the difference is. Link to comment Share on other sites More sharing options...
bcc9 Posted November 15, 2012 Share Posted November 15, 2012 I took a look at the source (IOPCIFamily & the kernel), and rather than using DropDMAR, one can simply configure the kernel boot argument: dart=0 to avoid the DMAR processing. Ie, in org.chameleon.Boot.plist: <key>Kernel Flags</key> <string>-v dart=0</string> 2 Link to comment Share on other sites More sharing options...
dukzcry Posted November 17, 2012 Share Posted November 17, 2012 I think the presumption is that a disk drive is timing out leading to the DMA timing out. Not the same problem as we're having. But errors are coming from AppleVTD, not from disk controller driver, so you can't definitely say that mentioned vtd code is correct. Link to comment Share on other sites More sharing options...
bcc9 Posted November 17, 2012 Share Posted November 17, 2012 But errors are coming from AppleVTD, not from disk controller driver, so you can't definitely say that mentioned vtd code is correct. Sure, I don't think anyone would want to claim that an osx kext is bug free. Pretty clear it's doing a pretty bad job at providing diagnostic information for time machine users. My system has been running fine with the simple dart=0 workaround. Perhaps it'll catch on like my npci=0x2000 workaround did Still would be worth figuring out what is actually going on with the vtd code on hackintoshes. Link to comment Share on other sites More sharing options...
dukzcry Posted November 18, 2012 Share Posted November 18, 2012 Still would be worth figuring out what is actually going on with the vtd code on hackintoshes. My assumption that the first problem in their code is that it relies on "queued invalidation" VT-d function, which isn't available on all VT-d device revisions (which are different from motherboard to motherboard on hackintoshes). That's why i've added checking of presence of this feature in my useless patch. With this feature disabled (since it misses on my board) i've got booting of OS X a bit futher on my system. You or someone else may use my stupid patch as starting point for futher research. Link to comment Share on other sites More sharing options...
dukzcry Posted April 22, 2013 Share Posted April 22, 2013 It causes problems even on "genuine mac" :-) Proofs: [1] [2]. Seems that they did a quick "fix" for macs (that does nothing but masks the problem) for this in 162.8 revision of IOPCIFamily: --- vtd.c.orig 2012-08-30 02:26:51.000000000 +0400 +++ vtd.c 2012-10-12 01:13:32.000000000 +0400 @@ -1073,13 +1073,13 @@ AppleVTD::space_alloc(vtd_space_t * bf, IOLockLock(bf->rlock); addr = vtd_rballoc(bf, size, align, fMaxRoundSize, mapOptions, pageList); STAT_ADD(bf, allocs[list], 1); - if (addr) STAT_ADD(bf, rused, size); - IOLockUnlock(bf->rlock); if (addr) { + STAT_ADD(bf, rused, size); vtd_space_fault(bf, addr, size); - if (pageList) vtd_space_set(bf, addr, size, mapOptions, pageList); } + IOLockUnlock(bf->rlock); + if (addr && pageList) vtd_space_set(bf, addr, size, mapOptions, pageList); } else { @@ -1094,7 +1094,7 @@ AppleVTD::space_alloc(vtd_space_t * bf, bf->waiting_space = true; IOLockSleep(bf->rlock, &bf->waiting_space, THREAD_UNINT); IOLockUnlock(bf->rlock); - IOLog("AppleVTD: waiting space (%d)\n", size); +// IOLog("AppleVTD: waiting space (%d)\n", size); VTLOG("AppleVTD: waiting space (%d)\n", size); } while (true); @@ -1127,7 +1127,7 @@ AppleVTD::space_free(vtd_space_t * bf, v { IOLockLock(bf->rlock); bf->waiting_space = false; - IOLockWakeup(bf->rlock, &bf->waiting_space, true); + IOLockWakeup(bf->rlock, &bf->waiting_space, false); IOLockUnlock(bf->rlock); } } Link to comment Share on other sites More sharing options...
StoneTemplePilots Posted April 23, 2013 Share Posted April 23, 2013 <key>DropDMAR</key> <string>Yes</string> to your /Extra/org.chameleon.Boot.plist. This solves the immediate boot problem. I assume this breaks direct hardware DMA support in virtual machines under osx, so perhaps the next step would be to figure out what the difference is between a genuine mac's DMAR table and hackintoshes. thanks a lot, works with chameleon 2189 : ) oob. Can someone dump a DMAR.dsl from an iMac to verify the differences in the DMAR Table? Mine shows: /* * Intel ACPI Component Architecture * AML Disassembler version 20120320-32 [sep 3 2012] * Copyright (c) 2000 - 2012 Intel Corporation * * Disassembly of /Applications/DarwinDumperReports/000_2013-04-23_16-28-11_iMac13,2/DarwinDumper_2.7.0_Chameleon_2.2_ML/ACPIDump/AML/DMAR.aml, Tue Apr 23 16:28:13 2013 * * ACPI Data Table [DMAR] * * Format: [HexOffset DecimalOffset ByteLength] FieldName : FieldValue */ [000h 0000 4] Signature : "DMAR" [DMA Remapping table] [004h 0004 4] Table Length : 00000080 [008h 0008 1] Revision : 01 [009h 0009 1] Checksum : F8 [00Ah 0010 6] Oem ID : "INTEL " [010h 0016 8] Oem Table ID : "SNB " [018h 0024 4] Oem Revision : 00000001 [01Ch 0028 4] Asl Compiler ID : "INTL" [020h 0032 4] Asl Compiler Revision : 00000001 [024h 0036 1] Host Address Width : 23 [025h 0037 1] Flags : 01 [030h 0048 2] Subtable Type : 0000 [Hardware Unit Definition] [032h 0050 2] Length : 0020 [034h 0052 1] Flags : 01 [035h 0053 1] Reserved : 00 [036h 0054 2] PCI Segment Number : 0000 [038h 0056 8] Register Base Address : 00000000FED90000 [040h 0064 1] Device Scope Entry Type : 03 [041h 0065 1] Entry Length : 08 [042h 0066 2] Reserved : 0000 [044h 0068 1] Enumeration ID : 02 [045h 0069 1] PCI Bus Number : F0 [046h 0070 2] PCI Path : 1F,00 [048h 0072 1] Device Scope Entry Type : 04 [049h 0073 1] Entry Length : 08 [04Ah 0074 2] Reserved : 0000 [04Ch 0076 1] Enumeration ID : 00 [04Dh 0077 1] PCI Bus Number : F0 [04Eh 0078 2] PCI Path : 0F,00 [050h 0080 2] Subtable Type : 0001 [Reserved Memory Region] [052h 0082 2] Length : 0030 [054h 0084 2] Reserved : 0000 [056h 0086 2] PCI Segment Number : 0000 [058h 0088 8] Base Address : 00000000DDF3A000 [060h 0096 8] End Address (limit) : 00000000DDF66FFF [068h 0104 1] Device Scope Entry Type : 01 [069h 0105 1] Entry Length : 08 [06Ah 0106 2] Reserved : 0000 [06Ch 0108 1] Enumeration ID : 00 [06Dh 0109 1] PCI Bus Number : 00 [06Eh 0110 2] PCI Path : 1D,00 [070h 0112 1] Device Scope Entry Type : 01 [071h 0113 1] Entry Length : 08 [072h 0114 2] Reserved : 0000 [074h 0116 1] Enumeration ID : 00 [075h 0117 1] PCI Bus Number : 00 [076h 0118 2] PCI Path : 1A,00 [078h 0120 1] Device Scope Entry Type : 01 [079h 0121 1] Entry Length : 08 [07Ah 0122 2] Reserved : 0000 [07Ch 0124 1] Enumeration ID : 00 [07Dh 0125 1] PCI Bus Number : 00 [07Eh 0126 2] PCI Path : 14,00 Raw Table Data: Length 128 (0x80) 0000: 44 4D 41 52 80 00 00 00 01 F8 49 4E 54 45 4C 20 DMAR......INTEL 0010: 53 4E 42 20 00 00 00 00 01 00 00 00 49 4E 54 4C SNB ........INTL 0020: 01 00 00 00 23 01 00 00 00 00 00 00 00 00 00 00 ....#........... 0030: 00 00 20 00 01 00 00 00 00 00 D9 FE 00 00 00 00 .. ............. 0040: 03 08 00 00 02 F0 1F 00 04 08 00 00 00 F0 0F 00 ................ 0050: 01 00 30 00 00 00 00 00 00 A0 F3 DD 00 00 00 00 ..0............. 0060: FF 6F F6 DD 00 00 00 00 01 08 00 00 00 00 1D 00 .o.............. 0070: 01 08 00 00 00 00 1A 00 01 08 00 00 00 00 14 00 ................ Link to comment Share on other sites More sharing options...
bcc9 Posted April 24, 2013 Share Posted April 24, 2013 Can someone dump a DMAR.dsl from an iMac to verify the differences in the DMAR Table? Mine shows: I diffed the dmar vs a genuine mac way back when, and the diffs were rather minimal and unenlightening. My simple dart=0 workaround, here: http://www.insanelymac.com/forum/topic/282989-vtd0-fault-after-1082-google-hasnt-heard-of-it-any-help/?do=findComment&comment=1867000 made going any further with this unnecessary. Here's what the diffs were for me, btw: diffs.txt Seems that they did a quick "fix" for this in 162.8 revision of IOPCIFamily: So as of 10.8.3, this problem no longer occurs on hackintoshes? (I haven't tried it myself yet). 1 Link to comment Share on other sites More sharing options...
dukzcry Posted April 24, 2013 Share Posted April 24, 2013 So as of 10.8.3, this problem no longer occurs on hackintoshes? (I haven't tried it myself yet). Still occurs. And it doesn't fix that problem with "waiting space" on real macs, just masks it. Link to comment Share on other sites More sharing options...
bcc9 Posted April 24, 2013 Share Posted April 24, 2013 Still occurs. Dunno why you said they did a fix that masks the problem then. Link to comment Share on other sites More sharing options...
dukzcry Posted April 24, 2013 Share Posted April 24, 2013 To set that i was right at this point: It causes problems even on "genuine mac" :-) Proofs: [1] [2]. I think the presumption is that a disk drive is timing out leading to the DMA timing out. Not the same problem as we're having. But errors are coming from AppleVTD, not from disk controller driver, so you can't definitely say that mentioned vtd code is correct. Corrections are good on forums. This will help potential devs who will wish to work on fixing this DMA & MSI remapping driver not to be mislead by your statement. Link to comment Share on other sites More sharing options...
bcc9 Posted April 24, 2013 Share Posted April 24, 2013 To set that i was right at this point: Who cares? I thought this thread was about the hackintosh issue. Waste of time to bump the thread with no news on that. Link to comment Share on other sites More sharing options...
tepaks Posted May 15, 2013 Share Posted May 15, 2013 Who cares? I thought this thread was about the hackintosh issue. Waste of time to bump the thread with no news on that. I care, reading this thread wasn't waste of time and it helped me solve KP after 10.8.2 combo on my new iHack. TNX all who joined and contributed they knowledge to this discussion. If I was only lucky enough to bump to this thread sooner, instead of spending so manny hours goggling for the right solution. Link to comment Share on other sites More sharing options...
bcc9 Posted May 15, 2013 Share Posted May 15, 2013 I care, reading this thread wasn't waste of time and it helped me solve KP after 10.8.2 combo on my new iHack. TNX all who joined and contributed they knowledge to this discussion. If I was only lucky enough to bump to this thread sooner, instead of spending so manny hours goggling for the right solution. I was being harsh, but the point was a post that is labeled "fix" but isn't applicable to hackintosh; and required followup questions to even understand the point, did little more than add confusion. I certainly felt like it wasted my time which is why I got frustrated. But yes, I agree the workarounds I provide in this thread are quite useful and this information should probably be stickied (perhaps rewritten as a solution instead of an investigation). Anyways, back on topic... I don't think disabling vt-d in bios is a good workaround as then you can't run a virtual machine (fails for me with virtualbox). Has anyone tested virtual machine guests under osx with the dart=0 solution or dropdmar solutions? I would think they'd work with the former but not the later. Link to comment Share on other sites More sharing options...
Frank Nitty Posted May 15, 2013 Share Posted May 15, 2013 Finally, I think I have found what I have been looking for to solve the problem I've been having which was preventing my GTX680 from working in Lion (10.7.4)... I will try this out when I get home. To follow the papertrail detailing what troubleshooting have already performed visit here. Link to comment Share on other sites More sharing options...
tepaks Posted May 16, 2013 Share Posted May 16, 2013 Anyways, back on topic... I don't think disabling vt-d in bios is a good workaround as then you can't run a virtual machine (fails for me with virtualbox). Has anyone tested virtual machine guests under osx with the dart=0 solution or dropdmar solutions? I would think they'd work with the former but not the later. Disabling vt-d in bios didn't work on my iHack. Only after adding dart=0 I was able to boot in to 10.8.3. just to find out that it rendered VMWare Fusion useless. So for those who want to use virtual machines this isn't a good fix but to all others it may be a good temporary solution instead of rolling back AppleACPIPlatform.kext to 10.8.1 Link to comment Share on other sites More sharing options...
Recommended Posts