10.6.5 legacy kernel for INTEL/AMD 32+64bit ready to download by qoopz/nawcom/AnV/BlackKnight/mucha - a few new features

[Andy Vandijck]

bump! i dont know either probably fakesmc.. shed some light pls..

It is not fakesmc.

It has to do with AppleACPIPlatform, it just indicates that AppleIntelCPUPowerManagement won't work on this cpu (but we allready knew this, right?)

The second point: That it fails decryption untill dsmos arrives is normal (standard kernel just isn't that verbose on it).

It just waits on DSMOS arrival and then decrypts + executes the binaries.

[CoolFX]

I was using 10.6.4 qoopz legacy kernel. When i updated my macosx to 10.6.5 my usb stop working. No keyboard and no mouse. I revert the situation with time machine.

Now that i installed 10.6.5 legacy kernel, can i install the 10.6.5 update without any usb issues??

 

Thankx

[Andy Vandijck]

I was using 10.6.4 qoopz legacy kernel. When i updated my macosx to 10.6.5 my usb stop working. No keyboard and no mouse. I revert the situation with time machine.

Now that i installed 10.6.5 legacy kernel, can i install the 10.6.5 update without any usb issues??

 

Thankx

Yes, the new kernel works with the new USB drivers.

[LeXa2]

First of all, big thanks for doing this great job!

I've got several questions to make the big picture clear:

 

1. There are several messages through this thread with the links to the archives with kernel and to the automated kernel package installer by nawcom. Which one should be used by the end-user? Is it "V2" archive which is pointed by the link in the first message of the thread? Or is it mach_kernel.zip Andy had posted on the 26th of November?

 

2. Is the kernel inside the updated automated installer package by nawcoms the same as the kernel that was posted by Andy on the Nov 26th?

 

3. What is the current status of AMD processors support. I had used to a fact that to get Mac OS X 10.6.4 to run correctly on my AMD Phenom II system i need to:

a) Install 10.4.0 legacy_kernel patched not to panic on CPUs with wrong CPUID.

Patch the rest of the system apps using Maxxuss patcher and cpuids lists provided by nawcom on his site to avoid synthetic crashes on the systems with "wrong" CPUID.

 

What is the "right way" to do it this days? As I see Andy had mentioned a new app named "amd_insn_patcher" that has something to do with AMD CPUs interoperability. So what is this app for? Who should use it, when and why? Is it a substitute for Maxxuss CPUID patcher? Or should I use both? And, last but not least, what patchers are included into and got run by nawcom's automated installer package?

 

Thanks in advance for explanations and clarifications.

[Andy Vandijck]

First of all, big thanks for doing this great job!

I've got several questions to make the big picture clear:

 

1. There are several messages through this thread with the links to the archives with kernel and to the automated kernel package installer by nawcom. Which one should be used by the end-user? Is it "V2" archive which is pointed by the link in the first message of the thread? Or is it mach_kernel.zip Andy had posted on the 26th of November?

 

2. Is the kernel inside the updated automated installer package by nawcoms the same as the kernel that was posted by Andy on the Nov 26th?

 

3. What is the current status of AMD processors support. I had used to a fact that to get Mac OS X 10.6.4 to run correctly on my AMD Phenom II system i need to:

a) Install 10.4.0 legacy_kernel patched not to panic on CPUs with wrong CPUID.

Patch the rest of the system apps using Maxxuss patcher and cpuids lists provided by nawcom on his site to avoid synthetic crashes on the systems with "wrong" CPUID.

 

What is the "right way" to do it this days? As I see Andy had mentioned a new app named "amd_insn_patcher" that has something to do with AMD CPUs interoperability. So what is this app for? Who should use it, when and why? Is it a substitute for Maxxuss CPUID patcher? Or should I use both? And, last but not least, what patchers are included into and got run by nawcom's automated installer package?

 

Thanks in advance for explanations and clarifications.

1. You can use the installer package (the easy way).

2. It should be the same as Nawcoms

3. Phenom II should be supported but you do still need to patch cpuid's of libraries/frameworks/plugins (apps get auto-patched by the kernel, but only apps).

4. AMD instruction patcher is a patcher that can remove cpuid's and sysenter instructions from libraries/frameworks/plugins/apps, even on 64bit apps it works automatically. It is included in the auto-install package to patch libSystem.B.dylib

[dickhouse]

Andy could you repost the latest of your legacy_kernel.. Rapidshare blocked by my {censored} ISP. So with your kernel i could use arch=x86_64, i have tried nawcom pkg but kp when using arch x86_64

[Andy Vandijck]

Andy could you repost the latest of your legacy_kernel.. Rapidshare blocked by my {censored} ISP. So with your kernel i could use arch=x86_64, i have tried nawcom pkg but kp when using arch x86_64

This forum, this thread, see above... (mach_kernel.zip under legacy....zip)

[mac_carol]

Thanks a lot Andy (and also Nawcom) for this new update

 

when I use the "arch=i386 -force64" everything works like a charm, both 32 & 64 bits apps

 

but when I use the "arch=x86_64" (with or without -force64),

I get stuck with this KP related to AppleACPIPlatform

 

FYI, I'm running the SL (retail) updated to 10.6.5 on my AMD P-II x4 & my ATI SB790 mobo (using your AppleATIATA-7 kext)

 

[defix]

I can second mac_carol. Asus SB700 based board with a Phenom 2 955, Retail SL with fakesms, appleatiata-7, nullcpupowermanagement kexts in e/e and appleazaliaaudio in s/l/e. Chameleon RC3 (RC4 does not make a difference though).

 

i386 with -force64 -notscverify works perfectly, arch=x86_64 I get pretty much the exact same KP he does.

 

Thanks for your great work nawcom and anv, without you guys we amd folks would be pretty screwed .

 

Edit: Screenshot attached.

[LeXa2]

3. Phenom II should be supported but you do still need to patch cpuid's of libraries/frameworks/plugins (apps get auto-patched by the kernel, but only apps).

4. AMD instruction patcher is a patcher that can remove cpuid's and sysenter instructions from libraries/frameworks/plugins/apps, even on 64bit apps it works automatically. It is included in the auto-install package to patch libSystem.B.dylib

Thanks for bringing more light on this topic. Unfortunately I still hadn't got the full picture. Let me describe what I seem to be understanding and correct me if/where I'm wrong.

 

Running Mac OS X on the AMD CPU is a difficult thing due to:

 

1. Artificial kernel panics and applications hangs introduced by Apple to prevent people from using non-original hardware. This artificial hangs works by issuing CPUID and checking the result to belong to supported CPU. This checks are being done in: kernel (avoided by using patched xnu kernel), system libraries (needs manual patching) and usermode applications (patched xnu kernel takes care to automatically scan and remove - or fix it in another way - CPUID checks upon execv system call).

 

2. Differences in the original AMD's implementation of x86-64 arch and Intel's cloned EM64T. Most notable problem is that Mac OS X convention to make a system call from usermode is to issue SYSENTER instruction, which is prohibited in both x86-64 "long" and "compartible" modes on AMD CPUs while works fine on Intel EM64T CPUs. As Mac OS X is supposed to be run only on Intel CPUs Apple hadn't took care to reimplement system call conventions for x86-64 usermode apps resulting in "Invalid Instruction" exception when trying to run them on AMD CPU. To overcome this problem user needs:

a) Patched xnu kernel which supports another way of accepting system calls from user mode (i.e. a kernel that don't use SYSEXIT, or a kernel with a special exception handler for SIGILL that "auto-magically" handles SYSENTER in the usermode code and "does the things the right way"). The example of such kernel is the one Andy had compiled and published here.

In case kernel hadn't been patched to auto-handle SYSENTER in usermode apps - user needs to patch all the libraries and applications (i.e. - all the code that runs in user mode) to use another way to do system calls instead of SYSENTER (probably by substituting it with AMD specific opcode SYSCALL). It seems to me - and that is just the guess - that the patched xnu kernel by Andy and all other respective community members acts in a way that it can auto-patch applications (i.e., it can auto-patch binary blobs executed by means of execv), but it cannot auto-patch dynamically linked libraries that got mapped to the process address space by Mac OS X dynamic lib loader (i.e. mmap is used instead and not the execv). If this guess is right then the end-user may leave the apps alone but should patch libs not to use SYSENTER. And - this is the guess again - one may use amd_insn_patcher for this purpose. Another possible way to accomplish the task (and it might be a way that the community developers may follow) is to patch Mac OS X dynamic loader in a way to do auto-patching of the dlopened/mmaped libs.

 

3. Lack of support of some SIMD instruction subsets by AMD APUs. Most notable example is SSSE3 instruction subset that is available on Intel CPUs and unavailable on AMD ones. Fixing this requires patching of the apps that use this instruction sets as I can barely see a way to "auto-heal" this on the fly except of using something like virtual machine supervisor at the kernel level, trapping the execution on each of the unsupported instructions and emulating them using available CPU resources (i.e. SSE3, SSE2, SSE5, e.t.c.). The task of patching xnu kernel to include such "SSSE3 virtualizer" is very hard but yet possible. For now the fact is that only a small subset of Mac OS X apps uses the SSSE3, and it looks like that it ends up being used only in case app is running in 64-bit mode. Thus it is possible for end-user to avoid crash by simply sticking to the 32-bit version of app in case 64-bit version SIGILLs on SSSE3 instruction.

 

Now, having typed in all above, back to the real-world implementations.

It had been said that nawcom's package installs kernel and patches one lib - notably libSystem.B.dylib - to be CPUID and SYSENTER-free. I had taken a moment to look into cpuids files nawcom hosted on his site and there are a lot of refferences to the dylib in there. Looks like I still need to use Maxxuss patcher after installing patched 10.5.0 xnu kernel, or - another and better way - I need to patch all the libs mentioned in MacOSXUpd10.6.5.cpuid.txt and iTunes10.1.cpuid.txt files with the amd_inst_patcher and then rebuild the dylib cache. In future I should try to patch libs by amd_inst_patcher that any new application will SIGILL and hope that this will fix the issue. Am I right?

 

P.S. I had run into problems trying to boot patched xnu 10.5.0 kernel by standard boot.efi in case the kernel is in file named anything other than "mach_kernel". Is it a bug in Apple's EFI bootloader?

[PsyD@f`Ke]

Can anyone tell me how to install the kernel and update to 10.6.5...????

 

Had some serious USB problems after updating via combo updater 10.6.5

 

There is an USBFix kext available for that.

10.6.4_USB.zip

[Andy Vandijck]

Thanks for bringing more light on this topic. Unfortunately I still hadn't got the full picture. Let me describe what I seem to be understanding and correct me if/where I'm wrong.

 

Running Mac OS X on the AMD CPU is a difficult thing due to:

 

1. Artificial kernel panics and applications hangs introduced by Apple to prevent people from using non-original hardware. This artificial hangs works by issuing CPUID and checking the result to belong to supported CPU. This checks are being done in: kernel (avoided by using patched xnu kernel), system libraries (needs manual patching) and usermode applications (patched xnu kernel takes care to automatically scan and remove - or fix it in another way - CPUID checks upon execv system call).

 

2. Differences in the original AMD's implementation of x86-64 arch and Intel's cloned EM64T. Most notable problem is that Mac OS X convention to make a system call from usermode is to issue SYSENTER instruction, which is prohibited in both x86-64 "long" and "compartible" modes on AMD CPUs while works fine on Intel EM64T CPUs. As Mac OS X is supposed to be run only on Intel CPUs Apple hadn't took care to reimplement system call conventions for x86-64 usermode apps resulting in "Invalid Instruction" exception when trying to run them on AMD CPU. To overcome this problem user needs:

a) Patched xnu kernel which supports another way of accepting system calls from user mode (i.e. a kernel that don't use SYSEXIT, or a kernel with a special exception handler for SIGILL that "auto-magically" handles SYSENTER in the usermode code and "does the things the right way"). The example of such kernel is the one Andy had compiled and published here.

In case kernel hadn't been patched to auto-handle SYSENTER in usermode apps - user needs to patch all the libraries and applications (i.e. - all the code that runs in user mode) to use another way to do system calls instead of SYSENTER (probably by substituting it with AMD specific opcode SYSCALL). It seems to me - and that is just the guess - that the patched xnu kernel by Andy and all other respective community members acts in a way that it can auto-patch applications (i.e., it can auto-patch binary blobs executed by means of execv), but it cannot auto-patch dynamically linked libraries that got mapped to the process address space by Mac OS X dynamic lib loader (i.e. mmap is used instead and not the execv). If this guess is right then the end-user may leave the apps alone but should patch libs not to use SYSENTER. And - this is the guess again - one may use amd_insn_patcher for this purpose. Another possible way to accomplish the task (and it might be a way that the community developers may follow) is to patch Mac OS X dynamic loader in a way to do auto-patching of the dlopened/mmaped libs.

 

3. Lack of support of some SIMD instruction subsets by AMD APUs. Most notable example is SSSE3 instruction subset that is available on Intel CPUs and unavailable on AMD ones. Fixing this requires patching of the apps that use this instruction sets as I can barely see a way to "auto-heal" this on the fly except of using something like virtual machine supervisor at the kernel level, trapping the execution on each of the unsupported instructions and emulating them using available CPU resources (i.e. SSE3, SSE2, SSE5, e.t.c.). The task of patching xnu kernel to include such "SSSE3 virtualizer" is very hard but yet possible. For now the fact is that only a small subset of Mac OS X apps uses the SSSE3, and it looks like that it ends up being used only in case app is running in 64-bit mode. Thus it is possible for end-user to avoid crash by simply sticking to the 32-bit version of app in case 64-bit version SIGILLs on SSSE3 instruction.

 

Now, having typed in all above, back to the real-world implementations.

It had been said that nawcom's package installs kernel and patches one lib - notably libSystem.B.dylib - to be CPUID and SYSENTER-free. I had taken a moment to look into cpuids files nawcom hosted on his site and there are a lot of refferences to the dylib in there. Looks like I still need to use Maxxuss patcher after installing patched 10.5.0 xnu kernel, or - another and better way - I need to patch all the libs mentioned in MacOSXUpd10.6.5.cpuid.txt and iTunes10.1.cpuid.txt files with the amd_inst_patcher and then rebuild the dylib cache. In future I should try to patch libs by amd_inst_patcher that any new application will SIGILL and hope that this will fix the issue. Am I right?

 

P.S. I had run into problems trying to boot patched xnu 10.5.0 kernel by standard boot.efi in case the kernel is in file named anything other than "mach_kernel". Is it a bug in Apple's EFI bootloader?

Yes, you should use amd_insn_patcher instead of regular patch as it can patch both 32+64bit parts of the app automatically.

Don't know about Apple's EFI bootloader (boot.efi) though, I haven't tested it on a hack.

[nawcom]

Now, having typed in all above, back to the real-world implementations.

It had been said that nawcom's package installs kernel and patches one lib - notably libSystem.B.dylib - to be CPUID and SYSENTER-free. I had taken a moment to look into cpuids files nawcom hosted on his site and there are a lot of refferences to the dylib in there. Looks like I still need to use Maxxuss patcher after installing patched 10.5.0 xnu kernel, or - another and better way - I need to patch all the libs mentioned in MacOSXUpd10.6.5.cpuid.txt and iTunes10.1.cpuid.txt files with the amd_inst_patcher and then rebuild the dylib cache. In future I should try to patch libs by amd_inst_patcher that any new application will SIGILL and hope that this will fix the issue. Am I right?

 

The only things patched via the pkg (with amd_insn_patcher) is libSystem.B.dylib, QuickTimeComponents, and QuickTimeH264Scalar. The 2 quicktime binaries are due to the libSystem.B not covering it. None of the stuff from the cpuid.txt files are needed to be patched anymore, so amd users can forget about those as of now.

[LeXa2]

Andy, nawcom, thanks a lot for quick answers. Great to hear that there's no need in patching binaries from cpuid.txt files anymore.

 

P.S. BTW, nawcom, there are big problems with downloading nawcom's MOD CD 0.3 from your webspace as the download link is broken. I had managed to get it from other source, but that hadn't been the easiest task ever. It'd be cool if you find a minute to upload this file to another hosting and to fix the links. Another question is on the future of MOD CD - are there any plans to update it with latest patched xnu kernel? In the current state it is impossible to use this CD to boot into 10.6.5 system without having USB-kexts workaround in place making it harder for end-user to recover from "USB not working after update" situation.

P.P.S. Sorry for offtop :-).

[nawcom]

Andy, nawcom, thanks a lot for quick answers. Great to hear that there's no need in patching binaries from cpuid.txt files anymore.

 

P.S. BTW, nawcom, there are big problems with downloading nawcom's MOD CD 0.3 from your webspace as the download link is broken. I had managed to get it from other source, but that hadn't been the easiest task ever. It'd be cool if you find a minute to upload this file to another hosting and to fix the links. Another question is on the future of MOD CD - are there any plans to update it with latest patched xnu kernel? In the current state it is impossible to use this CD to boot into 10.6.5 system without having USB-kexts workaround in place making it harder for end-user to recover from "USB not working after update" situation.

P.P.S. Sorry for offtop :-).

 

I actually have applied these new fixes to the 10.6/10.6.2/10.6.3/10.6.4 kernels already

 

http://nawcom.com/osx86/files/10.6/Kernels.../legacy_kernel/

http://nawcom.com/osx86/files/10.6/Kernels.../legacy_kernel/

http://nawcom.com/osx86/files/10.6/Kernels.../legacy_kernel/

http://nawcom.com/osx86/files/10.6/Kernels.../legacy_kernel/

(notice the updated modification date Nov 27 and the (compressed) kernel being twice as large than usual (was around 2 meg before))

 

I have uploaded them to my server, and i do plan on using them on the CD. I haven't worked on that in a while; I've been pretty busy. I know someone stuck my mod cd onto kexts.com, dunno why. Hehe.

[akiNikki]

The only things patched via the pkg (with amd_insn_patcher) is libSystem.B.dylib, QuickTimeComponents, and QuickTimeH264Scalar. The 2 quicktime binaries are due to the libSystem.B not covering it. None of the stuff from the cpuid.txt files are needed to be patched anymore, so amd users can forget about those as of now.

 

So you mean there's no need to use AMD Ins Patcher after using the 10.6.5 Legacy kernel installer?

[akiNikki]

Oh {censored}. I'm having an instant KP whenever I plugged in any USB device storage. No problem with USB mouse and keyboard. Anyone got info?

[Andy Vandijck]

So you mean there's no need to use AMD Ins Patcher after using the 10.6.5 Legacy kernel installer?

You need to use the AMD instruction patcher for patching plugins, libraries, frameworks, etc...

But not applications.

They get auto-patched by the kernel.

The only reason why it can't yet patch everything on the fly is because I'm not able to create a stable custom dyld

[razzoCV]

You need to use the AMD instruction patcher for patching plugins, libraries, frameworks, etc...

But not applications.

They get auto-patched by the kernel.

The only reason why it can't yet patch everything on the fly is because I'm not able to create a stable custom dyld

How i Can patch plugins, libraries, frameworks, etc...?

Thanks for the work.

[Andy Vandijck]

How i Can patch plugins, libraries, frameworks, etc...?

Thanks for the work.

amd_insn_patcher <infile> <outfile>

From within Terminal

[akiNikki]

Oh {censored}. I'm having an instant KP whenever I plugged in any USB device storage. No problem with USB mouse and keyboard. Anyone got info?

 

how bout this?

[mac_carol]

Sadly on my AMD Phenom II x4,

it panics randomly even in 32-bits mode (booting with arch=i386 ; either with/without -force64)

 

Warning: invalid kernel IP, wont attempt to handle trap

 

[akiNikki]

I got that too time to time. What's wrong actually? I can't understand the problem really.

[mindlessmissy]

Sadly on my AMD Phenom II x4,

it panics randomly even in 32-bits mode (booting with arch=i386 ; either with/without -force64)

 

Warning: invalid kernel IP, wont attempt to handle trap

 

 

 

Yep ... getting that too. Even when idle ... Has caused my drive to be corrupted once already ...

[Snerler]

For me it still says "64 bit kernel and extensions = No" even when using the force 64 bit option on my AMD processor. Is that because I lack 64 bit drivers for something?

 

Also Flash stutters in Google Chrome but works fine in Firefox. Is anyone else experiencing that?