AppleIntelFramebufferAzul.kext

A couple of days ago I blogged about the discovery of fBacklightFrequency and fBacklightMax. Today I like to add four more. This time; fStolenMemorySize, fFramebufferMemorySize, fCursorBytes and the amount of VRAM:

00 00 16 0A 00 03 03 03 00 00 00 04 00 00 00 01
00 00 F0 00 00 00 00 40 D9 0A 00 00 D9 0A 00 00
00 00 00 00 00 00 00 00 00 00 10 00 02 00 00 00
30 00 00 00 01 05 12 00 04 00 00 00 04 00 00 00
02 04 12 00 00 08 00 00 82 00 00 00 FF 00 01 00
01 00 00 00 40 00 00 00 04 00 00 00 00 00 07 00
04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00

Note: The last 24 bytes are the same for all data sets.

fStolenMemorySize: 00 00 00 04 = 0x4000000 = 64 MB
fFramebufferMemorySize: 00 00 00 01 = 0x1000000 = 16 MB
fCursorBytes: 00 00 F0 00 = 0xF00000 = 15728640 / 10 = 1572864
VRAM: 00 00 00 40 = 1024 MB
connector-type: There are five different connector types, being:

02 00 00 00 – LVDS
04 00 00 00 – DVI
00 04 00 00 – DP
00 08 00 00 – HDMI
00 0C 00 00 – Thunderbolt?

Note: Lowering fStolenMemorySize triggered the following error:

Assertion failed: minStolenSize <= fStolenMemorySize

Here is a handy table to convert values without the calculator:

00 00 00 01 = 0x01000000 = 16 MB
00 00 00 02 = 0x02000000 = 32 MB
00 00 00 04 = 0x04000000 = 64 MB
00 00 00 06 = 0x06000000 = 96 MB
00 00 00 08 = 0x08000000 = 128 MB
00 00 00 10 = 0x10000000 = 256 MB
00 00 00 18 = 0x18000000 = 384 MB
00 00 00 20 = 0x20000000 = 512 MB
00 00 00 30 = 0x30000000 = 768 MB
00 00 00 40 = 0x40000000 = 1024 MB
00 00 00 60 = 0x60000000 = 1536 MB
00 00 00 80 = 0x80000000 = 2048 MB

This information should come in handy for people who want to experiment with frame buffer data 😉

Update: connector-type data values added.

Advertisement

OS X 10.9 Mavericks DP2 (Build 13A497d)

Here is a quick update on OS X 10.9 Mavericks DP2 (Build 13A497d). A simple update from the Apple App Store. Let’s start with a screenshot of my About This Mac dialog. The only change here is the build id.

Now a first CineBench 11.5 test score with the HD 4600 – misidentified as intel Iris Pro.

I call that a stunning improvement over the previous generations of Intel HD graphics. Now over to the stock Geekbench results of my i4-4670K.

Well folks. This is all I can share right now.

Update by Jeroen:

We already knew that iGPU power management was working, but let me show you the results after running NovaBench:

AICPUPMI: CPU P-States [ 8 (34) 35 36 37 ] iGPU P-States [ 4 (14) 24 ]
AICPUPMI: CPU P-States [ 8 (34) 35 36 37 ] iGPU P-States [ 4 (5) 14 24 ]
AICPUPMI: CPU P-States [ (8) 34 35 36 37 ] iGPU P-States [ 4 5 (6) 14 24 ]
AICPUPMI: CPU P-States [ (8) 34 35 36 37 ] iGPU P-States [ 4 5 6 (7) 14 24 ]
AICPUPMI: CPU P-States [ (8) 34 35 36 37 ] iGPU P-States [ 4 5 6 7 (12) 14 24 ]
AICPUPMI: CPU P-States [ (8) 34 35 36 37 ] iGPU P-States [ 4 5 6 7 12 14 (17) 24 ]
AICPUPMI: CPU P-States [ 8 34 35 (36) 37 ] iGPU P-States [ 4 5 6 7 (8) 12 14 17 24 ]
AICPUPMI: CPU P-States [ (8) 34 35 36 37 ] iGPU P-States [ 4 5 6 7 8 (9) 12 14 17 24 ]

BTW: The test results of our NovaBench test run can be found here.

Note: We might reach a higher score when Pike is freed from all wedding/honeymoon planning’s and no. CPU power management is still not fully operational here.

Haswell CPU/iGPU power management with a GA-Z87M-D3H

I have configured RevoBoot to match a 2013 MacBook Air model and noticed a couple of oddities after the first boot. Let me start by adding a first screenshot.

One with the MacBook Air serial number removed, of course. And when everything is configured correctly, then you shouldn’t see this error:

[AGPM Controller] unknownPlatform

Usually the result of using unknown/unsupported board-id’s. No problem here. I also have my AppleIntelCPUPowerManagementInfo.kext installed and thus I looked for the relevant processor data in /var/log/system.log:

AICPUPMI: Low Frequency Mode : 800 MHz
AICPUPMI: Clock Speed : 3400 MHz
AICPUPMI: Max Turbo Frequency: 3800 MHz

The lowest supported processor frequency for desktop processors is now also 800 MHz so we should get a lot lower P-States. Not here. Not now at least. The clock speed and maximum turbo frequency are ok. This tells me that the UEFI BIOS bug I see here – discussed later on – is a cosmetic only one (I think). Next up. iGPU data:

AICPUPMI: IGPU Current Freq..: 200 MHz
AICPUPMI: IGPU Max Frequency.: 350 MHz
AICPUPMI: IGPU Max Turbo Freq: 1200 MHz

This is also fine. How do I know this you ask? Well. You may not be aware of it – not so strange since there isn’t a single Google search result for it – but we actually have a debug boot flag for it. Try this:

debug=0x100 igdebug=0xff

Reboot and look for the following output (example):

IG:: updateTableEntry:NN entry = 5
IG:: updateTableEntry:NN frequency = 950
IG:: updateTableEntry:NN upTimer = 31250
IG:: updateTableEntry:NN upThresholdlimit = 25000
IG:: updateTableEntry:NN upStep = 1
IG:: updateTableEntry:NN downTimer = 31250
IG:: updateTableEntry:NN downThresholdlimit = 18750
IG:: updateTableEntry:NN downStep = 1

You should see one of these blocks for every supported frequency. I checked mine and they are all there. Oh and it supports Ivy Bridge as well.

Time to take a closer look at the P-State and iGPU P-State results:

AICPUPMI: CPU P-States [ (8) ] GPU P-States [ (4) ]
AICPUPMI: CPU P-States [ 8 (34) ] GPU P-States [ (4) ]
AICPUPMI: CPU P-States [ 8 34 (36) ] GPU P-States [ (4) ]
AICPUPMI: CPU P-States [ 8 34 (35) 36 ] GPU P-States [ (4) ]
AICPUPMI: CPU P-States [ 8 34 35 36 (37) ] GPU P-States [ (4) ]

Not exactly what I hoped for, but it is a start. The first thing that you’ll notice is that CPU power management isn’t working. Apparently that is, since every P-State between 9 and 33 is missing. CPU power management however is correctly registered, and that in the correct (XCPM) mode, since I found these two in system.log:

XCPM: registered
IOPPF: XCPM mode

Please note that the (4) means 4 x 50 MHz aka 200 MHz. Which happens to be the lowest possible frequency for the iGPU. A deep sleep/wake cycle gave me this:

AICPUPMI: CPU P-States [ 8 34 35 36 (37) 38 ] GPU P-States [ 4 (9) 22 23 24 ]

Seems to be working, but I do seem to miss the top multiplier (38) for a single-core process at boot time – only showed up after a deep sleep/wake cycle. Weird. Possible due to this UEFI BIOS error:

Here the multipliers are dead wrong. Some of them are for the i7-4770K but the top multiplier is a duplication of the one below it. And even when I set the correct values manually, even then it doesn’t solve this problem. Not that I really care about it – seems to be a cosmetic only problem – since I see this in system.log:

MSR_TURBO_RATIO_LIMIT……(0x1AD) : 0x23242526

In layman terms: The MSR is initialised correctly, with the correct value, but you may want to check it when you use the default settings. Anyway. I also found this:

MSR_IA32_PERF_STATUS…….(0x198) : 0x17D300000800
MSR_IA32_PERF_CONTROL……(0x199) : 0x800

Meaning that my system boots in 800 MHz mode, this instead of using the top multiplier. I believe this to be another UEFI BIOS error because normally it would have been something like this:

MSR_IA32_PERF_STATUS…….(0x198) : 0x17D300002600
MSR_IA32_PERF_CONTROL……(0x199) : 0x2600

Maybe Gigabyte fixed this in the UEFI BIOS updates they have avilable for download on their website, but since I don’t have MS Windows… I cannot update mine. Still using F4 here.

Now. I have used/checked several different values for AAPL,ig-platform-id but here is the one that I am using right now (unmodified):

00 00 16 0A 00 03 03 03 00 00 00 04 00 00 00 01
00 00 F0 00 00 00 00 40 D9 0A 00 00 D9 0A 00 00
00 00 00 00 00 00 00 00 00 00 10 00 02 00 00 00
30 00 00 00 01 05 12 00 04 00 00 00 04 00 00 00
02 04 12 00 00 08 00 00 82 00 00 00 FF 00 01 00
01 00 00 00 40 00 00 00 04 00 00 00 00 00 07 00
04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00

The reason I highlighted the two values above is simply because I figured out what they are. Note the values of fBacklightFrequency and fBacklightMax in the output (example) below:

IG:: getPlatformID: 1455 AAPL,ig-platform-id = 0x0a160000
IG:: getOSInformation: NNNN [NFB] ————————————————————————
IG:: getOSInformation: NNNN [NFB] PlatformInformation
IG:: getOSInformation: NNNN [NFB] fPipeCount : 3
IG:: getOSInformation: NNNN [NFB] fPortCount : 3
IG:: getOSInformation: NNNN [NFB] fNumFramebuffer : 3
IG:: getOSInformation: NNNN [NFB] fStolenMemorySize : 64 MB
IG:: getOSInformation: NNNN [NFB] fFramebufferMemorySize : 16 MB
IG:: getOSInformation: NNNN [NFB] fFBMemoryCount : 3
IG:: getOSInformation: NNNN [NFB] fCursorBytes : 1572864
IG:: getOSInformation: NNNN [NFB] fBacklightFrequency : 2777
IG:: getOSInformation: NNNN [NFB] fBacklightEnable : 1
IG:: getOSInformation: NNNN [NFB] fBacklightMax : 2777
IG:: getOSInformation: NNNN [NFB] Port[0]: 00000000 / 00000000 / 00000002 / 00000048
IG:: getOSInformation: NNNN [NFB] Port[1]: 00000001 / 00000005 / 00000004 / 00000004
IG:: getOSInformation: NNNN [NFB] Port[2]: 00000002 / 00000004 / 00002048 / 00000130
IG:: getOSInformation: NNNN [NFB] Port[3]: 00000255 / 00000000 / 00000001 / 00000064

Then we convert the decimal value (2777) into a hexadecimal value. Resulting in: 0xAD9. Yes. This shows you how much fun debugging boot flags can be. Oh and let’s go back to CPU power management again.

Native PM without a ssdtPRGen generated SSDT results in:

ACPI_SMC_PlatformPlugin::start – waitForService(resourceMatching(AppleIntelCPUPowerManagement) timed out
WARNING: IOPlatformPluginUtil : getCPUIDInfo: this is an unknown CPU model 0x3c
— power management may be incomplete or unsupported

Using Ivy Bridge like P-States (with one extra P-State) results in:

XCPM: P-state table mismatch (error:0x4)
X86PlatformShim::sendPStates – pmCPUControl (XCPMIO_SETPSTATETABLE) returned 0x4
X86PlatformShim::start – Failed to send PStates

Setting Name (APLN, NN) greater than Zero results in:

XCPM: P-state table mismatch (error:0x8)
X86PlatformShim::sendPStates – pmCPUControl (XCPMIO_SETPSTATETABLE) returned 0x8
X86PlatformShim::start – Failed to send PStates

p.s. I have a few more items that I like to discuss here, but I was running out of time. Maybe later. Maybe tomorrow. Don’t forget. I am getting married and we need to do a lot of shopping – need to fill the sailboat with food for our honeymoon trip 🙂

Update:

Ok. Let’s start with the changed PBlockAddress providing the system I/O address for the processors register block. Each processor can supply a different address, but from now on I’ll be using 0x1810:

Processor (CPUn, 0x01, 0x00001810, 0x06) {}

Here is the one that we have been using with previous generation motherboards:

Processor (CPUn, 0x01, 0x00000410, 0x06) {}

As a reminder. Then I looked at some of the other values I get from my AppleIntelCPUPowerManagementInfo.kext

MSR_PMG_CST_CONFIG_CONTROL.(0xE2) : 0x1E000005

Not the value I expected and thus I looked in the Intel datasheet. Just to be sure. Nope. Bit-10 (0x400) isn’t set. The lowest three bits are also set to a reserved value (0x05) but it should have been 0x04 to signal C7 package C-State limit. But it isn’t. Which is strange because if you look at this:

MSR_PMG_IO_CAPTURE_BASE….(0xE4) : 0x21814

Here we not only see the new LVL_2 Base Address (0x1814) but also that bit-17 (0x20000) is set. This specifies the encoding value of the maximum C-State code (C7) name to be included when IO read to MWAIT redirection is enabled by bit-10 of MSR_PMG_CST_CONFIG_CONTROL.

The question is why this value isn’t matching up with the other MSR’s but I guess that this is something that we need to figure out later on.

p.s. I have updated ssdtPRGen already, but since it is getting late already… I haven’t pushed it out to the Git repository. Want to verify a couple of things before I do. Not going to happen today. Need my sleep or bad things may happen during our trip…

MacPro6,1 Geekbench results

Vroom…. Here is the new Apple MacPro6,1 Geekbench score
http://browser.primatelabs.com/geekbench2/2064275

Dude! That is not an Apple model identifier you say. Correct. AAPLJ90,1 is not the usual suspect, but this is the new Mac Pro! Trust me – Apple isn’t ready to share it at this time.

Oh and more goodies are coming. Soonish 😉

Edit: I like to add a few notes on what I think may impact the result in a bad way. First. This score is done with an unreleased Intel Xeon E5-2697 (2.70 GHz) and engineering sample of the EFI BIOS:

AAPLJ901.88Z.ENGR.B00.1306121724

And we hack folks know what a few little SMBIOS changes can do with a Geekbench score. BOOM. Also. It runs a beta version (Build 13A2054) of OS X 10.9 Mavericks and probably the most important thing to note here is that power management isn’t working properly. Not yet! Which I assure you is very important.

And lastly. Geekbench – with all due respect – isn’t the best tool to give people an idea of what a Mac Pro does/can do. Not testing the new ultra fast Apple SSD and it also does nothing with the new AMD twin graphics boards, so in short we get:

Lower clock rate.
Single versus double CPU configuration.
Less energy consumption.
New form factor (a lot smaller).
Stunning look (first Mac Pro to get a place on my desk)
Thunderbolt 2 (twice the speed)

Do I need to say more?

Oh wait! Look here:

Two 2.40GHz 6-Core Intel Xeon processors (12 cores) – default
Two 2.66GHz 6-Core Intel Xeon processor (12 cores) – optional
Two 3.06GHz 6-Core Intel Xeon (12 cores) – optional

Yup. That are in fact the processors used in the current Mac Pro, and thus the Geekbench score we have here might as well be that of an entry-level build, and with optional faster processors – when Intel plans to make any – come higher scores!

Maybe some people need to relax a little, sit back and wait for an updated score. Let’s all go blame Intel for not releasing new processors earlier. Nah. Just kidding… I’m far more concerned about the price of this shiny beauty. Don’t you?

MacBookPro11,1 (13-inch) Geekbench results

Well hello there http://browser.primatelabs.com/geekbench2/2060983

Test run with a new Mavericks Build (13A2050 versus 13A467u).

Intel HD4600 with full resolution

Both AppleIntelHD5000Graphics.kext (IntelAccelerator) and AppleIntelFramebufferAzul.kext are loaded and I have full resolution (1920 x 1200) with the HD 4600 (device-id 0x0412) with AAPL,ig-platform-id set to 0x0c260000. Here’s a first screenshot.

It is identified as Intel Iris Pro (GT3) and thus we have to patch AppleIntelFramebufferAzul.kext to make it recognise the HD 4600 natively. This is of course a good start but I need food first 😉

Note: Core Image (CI) works – Chess and the screensaver examples are ok – but Quartz Extreme not since the menu bar is not transparent. The checkbox for the “Translucent menu bar” is thus also missing from the: Desktop & Screen Save / Desktop preference panel.

Update by Jeroen: QE/CI is working with OS X 10.9 Mavericks DP2. All we need for RevoBoot is this XML snippet:

<!--?xml version="1.0" encoding="UTF-8"?-->
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>PciRoot(0x0)/Pci(0x2,0x0)</key>
	<dict>
		<key>device-id</key>
		<data>
		Fgo=
		</data>
		<key>AAPL,ig-platform-id</key>
		<data>
		AAAWCg==
		</data>
	</dict>
</dict>
</plist>

Which we convert with help of gfxutil (part of EFIStudio) like so:

./gfxutil -i xml -o bin /Extra/EFI/MacBookAir62.xml /Extra/EFI/MacBookAir62.bin

Now check: RevoBoot/i386/config/SETTINGS/MacBookAir62.h

#define INJECT_EFI_DEVICE_PROPERTIES 1
#define LOAD_MODEL_SPECIFIC_EFI_DATA 1

Make sure you have configured the settings correctly. After this you re-compile RevoBoot and copy the boot loader to the root directory (/) of your boot drive and then you reboot.

Or, as an alternative, you add a _DSM method in the scope of Device (IGPU) in your DSDT/SSDT like so:

Method (_DSM, 4, NotSerialized)
{
    If (LEqual (Arg2, Zero))
    {
        Return (Buffer (One) { 0x03 })
    }

    Return (Package (0x04)
    {
        "device-id",
         Buffer (0x04) { 0x00, 0x00, 0x16, 0x0a },
        "AAPL,ig-platform-id",
         Buffer (0x04) { 0x00, 0x00, 0x16, 0x0a }
    })
}

Small, clean and no DTGP method required. Please note that there can only be one _DSM method per device and thus if your DSDT or any of the SSDT tables has a _DSM method under Device IGPU then you must modify that one accordantly.

TIP: If QE/CI isn’t working for you, then make sure to check the core count in the UEFI BIOS settings, or use my AppleIntelInfo.kext to be certain that MSR 0x35 reports the correct value. This MSR is important, because here the value of four (4) was reset to three (3) due to a UEFI BIOS bug (fixed in the next UEFI BIOS updates) and then the check in the AppleIntelHD5000Graphics.kext binary (for 4 or 2 cores) simply disables QE/CI!

Note: gfxutil is a command line utility, part of EFIStudio, and download links can be found with Google.

Haswell i5-4670K OC With Stock/Boxed Cooler

Many people complain about the Haswell OC results, but I don’t see any reason why I would complain. In fact. I am fairly happy with mine. And to give you an example. I took a 110 Euro mainstream board from Gigabyte (Z87M-D3H) and after five minutes of fiddling with a few UEFI BIOS settings… here’s the Geekbench result (64-bit).

Again guys. This is almost 4.9GHz with the stock Intel cooler. And here is a picture of the UEFI BIOS.

And to show you that it wasn’t a lucky shot. Here is another one. This time at 4.8GHz. Well almost.

Sure. The processor is getting a little hot, but what do you expect from a stock cooler. I do have a Scythe Mugen Rev. B here that I will use for further testing. Let’s see how far we can get it 😉

Note: This was with OS X 10.9 Mavericks!

Edit: Geekbench screenshot updated – had the memory modules installed in the wrong slots. Duh!

Edit 2: Geekbench screenshot updated. Now over 16K with Turbo Ratios set to: 48/49/49/49

Edit 2: The used model identifier during my Geekbench run was not incorrect. Should have been: Mac-031B6874CF7F642A

New MacPro model/board-ids

Here is a quick update:

model-id: MacPro6,1
board-id: Mac-F60DEB81FF30ACF6

Just so that you know what to use 😉

Edit: More new board-id’s…

Mac-35C1E88140C3E6CF – MacBookAir6,1
Mac-7DF21CB3ED6977E5 – MacBookAir6,2
Mac-031B6874CF7F642A – IGPU (Macmini7,N)
Mac-189A3D4F975D5FFC – IGPU (MacBookPro11,N)
Mac-3CBD00234E554E41 – IGPU (MacBookPro11,N)
Mac-27ADBB7B4CEE8E61 – IGPU + NVIDIA (iMac14,N)

Edit 2: I found two more in ApplePlatformEnabler.kext

Mac-4BFAC7A2B9455938
Mac-6F01109E16C71B86 – IGPU

Edit 3: The Mac model identifiers in red are what I believe the next model identifiers. This based on the (absence) of the PublishBatteryFactors property and the power management data where the iMac traditionally has little to no PM feature support.

AppleIntelHD5000Graphics.kext

I checked AppleIntelHD5000Graphics.kext and found the following device-id’s:

0x0090 8086 ?
0x0091 8086 ?
0x0092 8086 ?
0x0c26 8086 Intel Haswell SDV Mobile (GT3)
0x0c16 8086 Intel Haswell SDV Mobile (GT2)
0x0c06 8086 Intel Haswell SDV Mobile (GT1)
0x0c22 8086 Intel Haswell SDV Desktop (GT3)
0x0d26 8086 Intel Haswell CRW Mobile (GT3)
0x0a26 8086 Intel Haswell ULT Mobile (GT3) (MacBook Air Mid 2013)
0x0a16 8086 Intel Haswell ULT Mobile (GT2)
0x0426 8086 Intel Haswell Mobile (GT3)
0x0416 8086 Intel Haswell Mobile (GT2)
0x0406 8086 Intel Haswell Mobile (GT1)
0x0d22 8086 Intel Haswell CRW Desktop (GT3)
0x0412 8086 Intel Haswell Desktop (GT2)
0x0a2e 8086 Intel Haswell ULT Mobile (GT3)

Which I matched with help of intel_driver.h Seems like Desktop GT2 is supported. Interesting isn’t it.

Edit: Link to intel_driver.h added

Kext Requirements for OS X 10.9 Mavericks

The following information is a developer must read – bad news for hackintosh users – and good news for (future) Mac users. Keeping the bad guys out… to help protect you and your hardware. The side effect is that it might stop people, eventually, from using the latest and greatest aka OS X 10.9 Mavericks on a hack (didn’t happen in the 10.9 GM but it may still happen in 10.10). Well. Until someone comes up with another great hack of course.

Protecting the kernel

• OS X 10.9 code signing verification for kexts
  • OS X 10.9 all kexts signatures are verified
  • OS X 10.9 unsigned or invalid signatures are non fatal (with one* exception)
  • OS X 10.9 Signed kexts will not load on releases prior to OS X 10.8
  • Valid  code signatures will eventually be mandatory for all kexts
  • Use kextutil -tn to verify your kext

Kext loading

• OS X 10.9 auto-load, on-demand load by CFBundleIdentifier, and kernel cache build
  • Searches in /System/Library/Extensions and /Library/Extensions
  • Must code sign* kexts in /Library/Extensions

Where we want your kexts installed

• Auto-load kexts required for rooting, or auto-searching ofkexts
  • OS X 10.9, /Library/Extensions MUST be signed!
  • OS X 10.9, /Systems/Library/Extensions (for compatibility)
  • OS X 10.9 and earlier, install unsigned kexts in /System/Library/Extensions

• All other kexts
  • Signed kexts CAN go into: /Library/Extensions
  • Do not install anywhere in /System (locked in the near future).
  • Other common locations still OK

Kext signing

• New with OS X 10.9, certificate for signing applications and kexts

In OS X 10.9

• Kexts in /Library/Extensions will NOT load if they are unsigned or have a signature verification error
• Users will see the “no load” alert dialog (need to OK it)
• Kexts outside /Library/Extensions will load if they are unsigned or have a signature verification error
• But users will see this – rather annoying – dialog
  
• Code signature verification warnings and error messages
• Most common code signature verification error codes
  • -67030: something in kext bundle was modified
  • -67062: kext is not signed
  • Code signing error codes are in Security.framework:
    • #include <Security/CSCommon.h>

Example after modified Info.plist:

com.apple.kextd[40]: WARNING – Invalid signature -67030 for kext URL = “file:///Users/local/AppleSamplePCI.kext/”, ID – “com.example.apple-samplecode.driver.SamplePCI”

Conclusions:
All kernel extensions in: /Library/Extensions must be signed and unsigned or otherwise invalid kexts in: /System/Library/Extensions will trigger an annoying dialog.

Apple also said that the /System directory will be locked in the future, but didn’t mention when or in which version of OS X that would be done. We just have to wait and see when it happens, but if this is introduced (in whatever OS version that may be) then we are locked out and that means that editing plists and/or patching bin (executable) files of signed kexts will be impossible, and since there are plenty kexts that need a binary and/or plist patch… you soon get the picture.

Source: Apple WWDC session video (707) and PDF.

Edit: Example of “Kernel extensions are not from identified developers” added.

Edit 2: Source added. Part about the locking of the /System directory reworded, this because it is unclear in which version of OS X it will be locked down.

Edit 3: Reworded a sentence that stated that people would be unable to use OS X 10.9 Mavericks on their hack. Sorry folks. I had no idea that this was still there. Should have been changed a long time ago, but I forgot about it.

Thanks to joe75 for the heads up!