Jump to content

vtd[0] fault after 10.8.2 - google hasn't heard of it, any help?

rockinron_1

By rockinron_1,
in OSx86 10.8 (Mountain Lion)

 Share
35 posts in this topic

Recommended Posts

rockinron_1
rockinron_1
Posted
Posted

So after 10.8.2 update I get this error during verbose boot:

 

IMG_0128_zps23627df2.jpg

 

 

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
  • 1 month later...
dukzcry
dukzcry
Posted
Posted

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].

  • Like 1
Link to comment
Share on other sites
  • 3 weeks later...
bcc9
bcc9
Posted
Posted

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

  • Like 3
Link to comment
Share on other sites
bcc9
bcc9
Posted
Posted

 

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
bcc9
bcc9
Posted
Posted

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
bcc9
bcc9
Posted
Posted

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>

  • Like 2
Link to comment
Share on other sites
dukzcry
dukzcry
Posted
Posted

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
bcc9
bcc9
Posted
Posted

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
dukzcry
dukzcry
Posted
Posted
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
  • 5 months later...
dukzcry
dukzcry
Posted
Posted
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
StoneTemplePilots
StoneTemplePilots
Posted
Posted 

<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
bcc9
bcc9
Posted
Posted

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).
  • Like 1
Link to comment
Share on other sites
dukzcry
dukzcry
Posted
Posted

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
  • 3 weeks later...
tepaks
tepaks
Posted
Posted

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
bcc9
bcc9
Posted
Posted

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
Frank Nitty
Frank Nitty
Posted
Posted

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
tepaks
tepaks
Posted
Posted

 

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
 Share
Go to topic listing
×
×
  • Create New...