Jump to content

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


  • Please log in to reply
34 replies to this topic

#1
rockinron_1

rockinron_1

    InsanelyMac Sage

  • FAQ Team
  • 394 posts
  • Gender:Male
  • Location:UK
So after 10.8.2 update I get this error during verbose boot:

Posted Image


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.

#2
p.H

p.H

    InsanelyMac Legend

  • FAQ Team
  • 738 posts
  • Gender:Male
  • Interests:Hackintosh & NBA & COD4 promod
turn off vt-d in your bios or uefi.

#3
rockinron_1

rockinron_1

    InsanelyMac Sage

  • FAQ Team
  • 394 posts
  • Gender:Male
  • Location:UK
No setting for it, only for virtualizartion which I've already tried to disable

#4
rockinron_1

rockinron_1

    InsanelyMac Sage

  • FAQ Team
  • 394 posts
  • Gender:Male
  • Location:UK
Solved by rolling back AppleAPCIPlatform although I'm not sure why ATM.

#5
dukzcry

dukzcry

    InsanelyMac Geek

  • Members
  • PipPipPip
  • 108 posts
  • Gender:Male

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



#6
eep357

eep357

    Triple Platinum

  • Supervisors
  • 2,527 posts
  • Gender:Male
  • Location:Dark Side of The Wall
  • Interests:things and stuff
A shot of penicillin should clear that up for ya :)

#7
bcc9

bcc9

    InsanelyMac Legend

  • Coders
  • 1,277 posts
  • Gender:Male
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: Attached File  boot.2117.dmar.zip   140.23KB   62 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:Attached File  diffs.txt   1.59KB   19 downloads

#8
bcc9

bcc9

    InsanelyMac Legend

  • Coders
  • 1,277 posts
  • Gender:Male

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.


#9
dukzcry

dukzcry

    InsanelyMac Geek

  • Members
  • PipPipPip
  • 108 posts
  • Gender:Male

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



#10
bcc9

bcc9

    InsanelyMac Legend

  • Coders
  • 1,277 posts
  • Gender:Male

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.

#11
bcc9

bcc9

    InsanelyMac Legend

  • Coders
  • 1,277 posts
  • Gender:Male
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>


#12
dukzcry

dukzcry

    InsanelyMac Geek

  • Members
  • PipPipPip
  • 108 posts
  • Gender:Male

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.

#13
bcc9

bcc9

    InsanelyMac Legend

  • Coders
  • 1,277 posts
  • Gender:Male

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.

#14
dukzcry

dukzcry

    InsanelyMac Geek

  • Members
  • PipPipPip
  • 108 posts
  • Gender:Male
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.



#15
dukzcry

dukzcry

    InsanelyMac Geek

  • Members
  • PipPipPip
  • 108 posts
  • Gender:Male
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);
}
}


#16
LightServer

LightServer

    InsanelyMac Sage

  • Members
  • PipPipPipPipPip
  • 307 posts
  • Gender:Male
  • Location:Mödling, Austria

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


#17
bcc9

bcc9

    InsanelyMac Legend

  • Coders
  • 1,277 posts
  • Gender:Male

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: Attached File  diffs.txt   3.59KB   18 downloads

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

#18
dukzcry

dukzcry

    InsanelyMac Geek

  • Members
  • PipPipPip
  • 108 posts
  • Gender:Male

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.

#19
bcc9

bcc9

    InsanelyMac Legend

  • Coders
  • 1,277 posts
  • Gender:Male

Still occurs.

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

#20
dukzcry

dukzcry

    InsanelyMac Geek

  • Members
  • PipPipPip
  • 108 posts
  • Gender:Male

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.







0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users

© 2014 InsanelyMac  |   News  |   Forum  |   Downloads  |   OSx86 Wiki  |   Mac Netbook  |   PHP hosting by CatN  |   Designed by Ed Gain  |   Logo by irfan  |   Privacy Policy