33 replies to this topic

[rockinron_1]

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.

[p.H]

turn off vt-d in your bios or uefi.

[rockinron_1]

No setting for it, only for virtualizartion which I've already tried to disable

[rockinron_1]

Solved by rolling back AppleAPCIPlatform although I'm not sure why ATM.

[dukzcry]

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 virtualization hackers there to get something useful from 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] [2].

[eep357]

A shot of penicillin should clear that up for ya

[bcc9]

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   140.23K   39 downloads  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   1.59K   10 downloads

[bcc9]

dukzcry, on 15 November 2012 - 01:47 PM, said:

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.

[dukzcry]

It causes problems even on "genuine mac" :-) Proofs: [1] [2].
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.

[bcc9]

dukzcry, on 15 November 2012 - 04:35 PM, said:

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.

[bcc9]

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>

[dukzcry]

bcc9, on 15 November 2012 - 06:22 PM, said:

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.

[bcc9]

dukzcry, on 17 November 2012 - 03:29 PM, said:

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.

[dukzcry]

bcc9, on 17 November 2012 - 05:17 PM, said:

My system has been running fine with the simple dart=0 workaround.

Indeed, it works for me too.

Quote

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. I didn't check dmar.h structures for correctness, since this header looks like taken from Linux code, so maybe, this is the first thing to do.
Would be worth to get:
1) Dump of DMAR table from Retina MBP;
2) Kernel log from same machine with IOPCIFamily recompiled for debugging output of vtd.c routines.

[dukzcry]

dukzcry, on 15 November 2012 - 04:35 PM, said:

It causes problems even on "genuine mac" :-) Proofs: [1] [2].

Seems that they did a quick "fix" (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);
}
}

[BonBon6]

bcc9, on 12 November 2012 - 07:01 AM, said:

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

[bcc9]

BonBon6, on 23 April 2013 - 02:35 PM, said:

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.insanelym...p/#entry1867000  made going any further with this unnecessary.  Here's what the diffs were for me, btw:  diffs.txt   3.59K   10 downloads

dukzcry, on 22 April 2013 - 01:31 PM, said:

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

[dukzcry]

bcc9, on 24 April 2013 - 12:46 AM, said:

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.

[bcc9]

dukzcry, on 24 April 2013 - 03:59 AM, said:

Still occurs.

Dunno why you said they did a fix that masks the problem then.

[dukzcry]

To set that i was right at this point:

dukzcry said:

It causes problems even on "genuine mac" :-) Proofs: [1] [2].

dukzcry said:

bcc9, on 15 November 2012 - 06:22 PM, said:

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.