Jump to content

Editing Custom connector info for Intel HD 3000 Graphics (sandy bridge, OSX Lion)

bcc9

By bcc9,
in Intel

 Share
221 posts in this topic

Recommended Posts

bcc9
bcc9
Posted
Posted

The problem:

 

On a hackintosh, the sandy bridge graphics driver exhibits a constant event ring stall until the stall is cleared via either hotplugging the display connector (and leaving it removed for ~5 seconds to clear the stall), or by using more than 1 display connectors simultaneously. This stalling can be seen as very slow graphics display updates (~5 second delays between mouse clicks and responses) and or by looking at the kernel log, /var/log/kernel, which shows errors such as:

May 25 23:20:45 xs-MacBook-Pro-2 kernel[0]: WaitForStamp: Overflowed waiting for stamp 0x2f3 on Main ring: called from
May 25 23:20:45 xs-MacBook-Pro-2 kernel[0]: timestamp = 0x02cc
May 25 23:20:45 xs-MacBook-Pro-2 kernel[0]: ****  Debug info for apparent hang in Main graphics engine  ****
May 25 23:20:45 xs-MacBook-Pro-2 kernel[0]: ring head	= 0x00600eb4, wrap count = 0x 3
May 25 23:20:45 xs-MacBook-Pro-2 kernel[0]: ring tail	= 0x00000110 ring control = 0x00003801   enabled, auto report disabled,  waiting, semaphore not waiting, length = 0x004 4KB pages
May 25 23:20:45 xs-MacBook-Pro-2 kernel[0]: timestamps = 0x02cc
May 25 23:20:45 xs-MacBook-Pro-2 kernel[0]: Semaphore register values:
May 25 23:20:45 xs-MacBook-Pro-2 kernel[0]: VRSYNC: (0x12044) = 0x2cc
May 25 23:20:45 xs-MacBook-Pro-2 kernel[0]: BRSYNC: (0x22040) = 0x0
May 25 23:20:45 xs-MacBook-Pro-2 kernel[0]: RVSYNC: (0x 2040) = 0x0
May 25 23:20:45 xs-MacBook-Pro-2 kernel[0]: BVSYNC: (0x22044) = 0x0
May 25 23:20:45 xs-MacBook-Pro-2 kernel[0]: RBSYNC: (0x 2044) = 0x0
May 25 23:20:45 xs-MacBook-Pro-2 kernel[0]: VBSYNC: (0x12040) = 0x0
May 25 23:20:45 xs-MacBook-Pro-2 kernel[0]: Looks like Main ring is stuck waiting on an event
May 25 23:20:45 xs-MacBook-Pro-2 kernel[0]: After attempt to clear wait condition = 0x00003001 no longer waiting
May 25 23:20:45 xs-MacBook-Pro-2 kernel[0]: kIPEHR: 0x7a000003
May 25 23:20:45 xs-MacBook-Pro-2 kernel[0]: kINSTDONE: 0xfffb
May 25 23:20:45 xs-MacBook-Pro-2 kernel[0]: kINSTDONE_1: 0x230003f

For the driver fix, some prerequisites:

  • osx 10.7 and intel sandy bridge graphics hardware (intel h67/z68 chipset)
  • Installation of OSX Developer tools (if you need to lookup a PlatformInformationList that has not already been done by someone else). The OSX developer tools are found within Apple's xcode distribution, here: http://developer.apple.com/xcode/, also most commonly available via apple's app store.
  • Understanding of hex editing
  • Ability to troubleshoot by looking at ioregistry

As of the 10.7 developer preview code, the intel driver uses Smboardproduct (aka board-id in the ioregistry) to determine the display connectors that are available via the Intel HD 3000 graphics hardware. Actually there's also AAPL,snb-platform-id in the ioregistry that achieves the same result, but I'm going to ignore that for now.

 

Older code (10.6 including the 2011 MBP sandy bridge update) seems to strictly rely upon the os-info ioregistry entry for this information. I have not, and probably won't, look into editing os-info to change connector information.

 

With a 10.7 based version of AppleIntelSNBGraphicsFB.kext, the code uses the board-id as an index into the PlatformInformationList[] table. This table is pretty handy, and looks like:

/* 12 byte connectorinfo */
typedef struct {
   char byte0;
   char byte1; /* i2cid? */
   char unused[2];
   uint32	   connectortype;	/* The connector type, see below */
   char byte[4];
} connectorinfo_t;

/* 60 byte total */
typedef struct {
char byte0; /* Presence? */
char byte1; /* For display pipe max connector index? */
char byte2; /* Usable Connector count */
char byte3; /* Appears unused */
char byte[8];
connectorinfo_t connectors[4];
} PlatformInformationList_type;

PlatformInformationList_type PlatformInformationList[8];

where integers are represented in intel little-endian byte order, and bit 0 is the LSB.

In English, there are 8 tables in the list, each 60 bytes long. Each 60 byte table entry starts with a 12 byte header, followed by 4 connector information blocks. The connector information blocks are each 12 bytes long.

 

The connectorytype field appears to use the same codes as the ATI driver, where the only used values used by the driver thus far are:

 

#define CONNECTORTYPE_LVDS 0x00000002 /* Ie internal Low Voltage display, such as laptop */

#define CONNECTORTYPE_DP 0x00000400 /* Displayport */

#define CONNECTORTYPE_HDMI 0x00000800

 

If you don't set your board-id to a recognized value, a default connector table is instead taken from the address PlatformInformationDefault. THe default table only has 1 usable connector so this is likely to give you reduced functionality.

 

Setting SMboardproduct to various sandy bridge board-ids defines the index into PlatformInformationList[]. Interestingly only indexes 0 thru 5 are currently allowed (even though there are two more table entries...) In any case, for the purpose of this note, we'll use index 0 by setting the board-id to the MacBookPro8,1 value. In smbios.plist:

		<key>SMboardproduct</key>
	<string>Mac-94245B3640C91C81</string>

 

Unfortunately all 8 table entries use an LVDS connector for the first value, and the driver seems to malfunction if you have nothing plugged into this port. In my case I would see the kernel log fill up with errors about a stuck ring:

kernel[0]: WaitForStamp: Overflowed waiting for stamp 0x2f3 on Main ring: called from
...
kernel[0]: Looks like Main ring is stuck waiting on an event
kernel[0]: After attempt to clear wait condition = 0x00003001 no longer waiting

And it would get re-stuck every 5 seconds or so. More importantly this would make the graphics unusably slow unless I unplugged the display for > 5 seconds first. At that point the stuck ring problem would "heal"... Using a dual-head setup also seems to avoid this problem.

 

However, rather than hot-plugging the graphics display upon every boot, one can instead modify the above table to avoid this problem.

 

First we find the PlatformInformationList table. In the example below I'm using DP4:

% cd /System/Library/Extensions/AppleIntelSNBGraphicsFB.kext/Contents/MacOS
% nm -arch x86_64 AppleIntelSNBGraphicsFB | grep 'D _PlatformInformationList'
00000000000295f0 D _PlatformInformationList
% lipo -detailed_info AppleIntelSNBGraphicsFB
Fat header in: AppleIntelSNBGraphicsFB
fat_magic 0xcafebabe
nfat_arch 2
architecture x86_64
cputype CPU_TYPE_X86_64
cpusubtype CPU_SUBTYPE_X86_64_ALL
offset 4096
size 283008
align 2^12 (4096)
architecture i386
cputype CPU_TYPE_I386
cpusubtype CPU_SUBTYPE_I386_ALL
offset 290816
size 293092
align 2^12 (4096)
%

So now we know the disk address for this table is:

0x295f0+4096=173552

Since there are 8 tables of 60 bytes, we could dump 8*60=480 bytes to see all 8 tables. Since I've chosen to work on the first entry, I'll dump just 60 bytes.

ALso since each connector is 12 bytes, I dump 12 bytes per line for our viewing pleasure.

% dd if=AppleIntelSNBGraphicsFB of=/tmp/table bs=1 skip=173552 count=60
60+0 records in
60+0 records out
60 bytes transferred in 0.000142 secs (422955 bytes/sec)
% cd /tmp
% xxd -c 12 < table > hex
% cat hex
0000000: 0102 0400 1007 0000 1007 0000  ............
000000c: 0503 0000 0200 0000 3000 0000  ........0...
0000018: 0205 0000 0004 0000 0700 0000  ............
0000024: 0304 0000 0004 0000 0900 0000  ............
0000030: 0406 0000 0004 0000 0900 0000  ............
%

In the above table you can see that 4 connectors are marked usable, 1 LVDS and 3 DP. On my h67 motherboard, I have 4 connectors: VGA, DVI, DP and HDMI. The DVI, DP and HDMI connectors all work with the DP connectortype shown in this table (the intel driver doesn't seem to use the connectortype for much).

 

I believe I can tell which of the above entries match my hardware by checking which entry has av-signal-type set, (or when AAPL,DisplayPipe != 0xffff?). I certainly can by exhausting testing of the combinations...

 

Now, to remove the problematic LVDS entry, I edit the hex file, producing:

0000000: 0102 0300 1007 0000 1007 0000  ............
000000c: 0304 0000 0004 0000 0900 0000  ............
0000018: 0205 0000 0004 0000 0700 0000  ............
0000024: 0406 0000 0004 0000 0900 0000  ............
0000030: 0000 0000 0000 0000 0000 0000  ............

In the above I moved the hex from the 3rd connector (row 4) to the first (row 2), zeroed the hex in row 5, and subtracted 1 from the connector count in row 0.

 

Now I write back the result:

xxd -c 12 -r hex >! table
% dd if=table of=/System/Library/Extensions/AppleIntelSNBGraphicsFB.kext/Contents/MacOS/AppleIntelSNBGraphicsFB bs=1 seek=173552 conv=notrunc
% touch /System/Library/Extensions

Viola, 3 working connectors and no driver hangs, instead of 1 broken connector & 3 working connectors with driver hangs.

  • Like 8
nmano
nmano
Posted
Posted

my sony laptop intel hd graphics

i5 460m .so can I know this model support this tutorial

bcc9
bcc9
Posted
  • Author
Posted
As you described, I still need to connect two ports or to unplug and plug if connecting only one port.

 

If you have any idea and want me to test, please tell me.

That's the behavior you get until you make your preferred port be the first entry in the connector table. If your preferred port is DVI, you need to move a different row to the first entry (my example was for the displayport port; at least with the layout on the gigabyte h67 motherboard).

 

my sony laptop intel hd graphics

i5 460m .so can I know this model support this tutorial

This thread is for the hardware that apple is supporting with the new AppleIntelSNBGraphicsFB kext. In other words, the new on-cpu die sandy bridge intel graphics (HD Graphics 2000, HD Graphics 3000).

VCH888
VCH888
Posted
Posted
That's the behavior you get until you make your preferred port be the first entry in the connector table. If your preferred port is DVI, you need to move a different row to the first entry (my example was for the displayport port; at least with the layout on the gigabyte h67 motherboard).

 

 

Thank you for your tip. Now I can boot DP4 initially via DVI port.

bcc9
bcc9
Posted
  • Author
Posted
Thank you for your tip. Now I can boot DP4 initially via DVI port.

Great, glad you got it. From my notes, for the gigabyte h67 motherboard, for the 4 connects listed in the table, in order, we have:

port-number	 actual connector   row number in connector table
0					 VGA					   1
5					 DVI						 2
6					 DP						  3
7					 HDMI					 4

where port-number is as reported in the ioregistry.

bcc9
bcc9
Posted
  • Author
Posted
@bcc9

This is awesome. You are some kind of master. I will be using this as soon as gm of 10.7 is released.

hoping its early july not the last day of.

Ha, thanks. It takes a lot of time to figure this stuff out let alone document it. Hopefully the fix will be the same once 10.7 is out (or the fix could become unnecessary).

genzai
genzai
Posted
Posted
(or the fix could become unnecessary).

 

That would be ideal but probably wishful thinking :)

 

The 10.6.8 update that came out yesterday seems to have a number of Lion like drivers, such as HD audio, iopcifam, etc.

 

Do we happen to know if the hd3000 fix would work on the new 10.6.8 release as well? if so i could move ahead now instead of waiting possibly another month for Lion.

 

Thanks,

[g]

  • 2 weeks later...
Signal64
Signal64
Posted
Posted

@bcc9, nice job.

 

A couple of questions for you:

 

1. How do you determine the index of the table used based on mac model?

 

2. To confirm, it's only by trial and error to map out the port connector to row in the table?

bcc9
bcc9
Posted
  • Author
Posted
@bcc9, nice job.

 

A couple of questions for you:

 

1. How do you determine the index of the table used based on mac model?

Thanks.

You read the code to see the index assignments. The string matching&index assignment code is pretty straightforward.

Since I already mapped out one for you, whose board-id gives you 4 usable connectors, I don't think you actually need to do this.

2. To confirm, it's only by trial and error to map out the port connector to row in the table?

From the ioregistry, you can see from the aapl,displaypipe, av-signal-type values what entry/entries are being used.

If you don't like that, you could probably dump the i2cid information for the graphics hardware (like I did for the ATI case), and match those ids up with byte1 (or is it byte 0?) of the connectorinfo. I did not need to go that far.

iLeopod
iLeopod
Posted
Posted

from:

% nm -arch x86_64 AppleIntelSNBGraphicsFB | grep 'D _PlatformInformationList'
00000000000295f0 D _PlatformInformationList

at my system the number was different so i must change the terminal commands but the hex stuff was exactly the same.

bcc9
bcc9
Posted
  • Author
Posted
from:

% nm -arch x86_64 AppleIntelSNBGraphicsFB | grep 'D _PlatformInformationList'
00000000000295f0 D _PlatformInformationList

at my system the number was different so i must change the terminal commands but the hex stuff was exactly the same.

Yes, thanks. This number will change from release to release, thus the command to lookup the value that is applicable to one's particular driver build.

IGP3000
IGP3000
Posted
Posted
Yes, thanks. This number will change from release to release, thus the command to lookup the value that is applicable to one's particular driver build.

 

How can I find the number for 10.6.8 ??

Everything works now except the the edit of the connector info.

iLeopod
iLeopod
Posted
Posted

Are the terminal commands not working?

first 

cd /System/Library/Extensions/AppleIntelSNBGraphicsFB.kext/Contents/MacOS

then

nm -arch x86_64 AppleIntelSNBGraphicsFB | grep 'D _PlatformInformationList'

 

U may need sudo if u get sty with "no permission" .

IGP3000
IGP3000
Posted
Posted
Are the terminal commands not working?

first 

cd /System/Library/Extensions/AppleIntelSNBGraphicsFB.kext/Contents/MacOS

then

nm -arch x86_64 AppleIntelSNBGraphicsFB | grep 'D _PlatformInformationList'

 

U may need sudo if u get sty with "no permission" .

 

Hmmm.... There is no output from the command:

 

nm -arch x86_64 AppleIntelSNBGraphicsFB | grep 'D _PlatformInformationList'

 

I just get the command prompt back...

IGP3000
IGP3000
Posted
Posted
Do u use board id in SMBIOS.plist? 
  <key>SMboardproduct</key>
	<string>Mac-94245B3640C91C81</string>

 

Yes - use 

  <key>SMboardproduct</key>
	<string>Mac-942459F8199B171B</string>

 

But how do I get output of the nm command ??

 Share
Go to topic listing
×
×
  • Create New...