Jump to content

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


  • Please log in to reply
142 replies to this topic

#41
mindlessmissy

mindlessmissy

    InsanelyMac Geek

  • Members
  • PipPipPip
  • 100 posts
  • Gender:Male

If I install the 10.6.5 legacy kernel, can I remove 10.6.4 kexts and the original 10.6.5 kexts should work?


With this kernel, I did NOT need the 10.6.4 kexts ...

#42
Headspin

Headspin

    InsanelyMac Protégé

  • Members
  • Pip
  • 35 posts
Not working at its best...

How do I check the /verbose logs so i can copy paste the errors here?

I get some ACPI_Platform_powermanagement CPUID problem or something like that... saying that powermanagement may not work properly...

I get another thing saying something like patch_obj and decryption (will retry) and it just keeps repeating that till dmos is arrived or somethin..

Another thing is that even in arch=i386 , arch=i386 -force 64, any 32 bit mode, 64 bit mode, safari still fails after I did that patch thing showed in the previous posts... It crashes constantly so right now Im using firefox to write this.

One more thing how do I get battery to show up in the top right corner? cuz enabling that in system pref didnt work.. Im fairly new to hackintosh btw but Im not completely noob I can run commands and install kexts and stuff.

Im using AMD athlon II x64, HP G61.

If u tell me where to find these kernel logs, I can post it but other than that I'd have to find my camera to take a pic or write down everysingle one but the screen moves so fast its hard to remember all

#43
nawcom

nawcom

    InsanelyMac Protégé

  • Retired Developers
  • 69 posts
  • Gender:Male
  • Location:localhost
  • Interests:Mind {censored}. Telephony.

- i'm getting my old friend "NOT_IMPLEMENTED bora/vmx/main/vmmonPosix.c:312" when starting a vm and VMWare installer saying i need an Intel cpu, "only" with the legacy kernel; i remember this from long time ago, but can't remember the reason and google is not helping much.. any thoughts?


In kern_mib.c it looks like some code that is supposed to be in case HW_MODEL was put in case HW_MACHINE, so instead of i386 or x86_64 being in hw.machine, it's your model name. I just moved the needed code to the right place and recompiled.

kernel by itself: http://nawcom.com/os...gacy_kernel.bz2
updated the pkg too: http://nawcom.com/os...-10.5.0.pkg.zip

#44
Andy Vandijck

Andy Vandijck

    InsanelyMac Deity

  • Coders
  • 1,642 posts
  • Gender:Male
  • Location:Tienen
  • Interests:Programming stuff for Mac OS X...
    Hacking...
    Hard rock (also really big Metallica...

In kern_mib.c it looks like some code that is supposed to be in case HW_MODEL was put in case HW_MACHINE, so instead of i386 or x86_64 being in hw.machine, it's your model name. I just moved the needed code to the right place and recompiled.

kernel by itself: http://nawcom.com/os...gacy_kernel.bz2
updated the pkg too: http://nawcom.com/os...-10.5.0.pkg.zip

Thanks for pointing this out Nawcom.
I've changed the code in the diff as well.
Latest diff attached below ;)
I also did one more change: I put an #ifdef that removes the bad (causing reset) routines from the x86_64 kernel (but not i386 ofcourse).
Kernel attached below.

Attached Files



#45
Dellmantt

Dellmantt

    STILL LEARNING

  • Members
  • PipPipPipPipPipPipPipPip
  • 1,122 posts
  • Gender:Male
  • Location:AUSTRALIA

Also vmware fusion does not work, this has been a issue since some revision of ANV's 10.6.4 kernel, prior to that it worked flawlessly.



In kern_mib.c it looks like some code that is supposed to be in case HW_MODEL was put in case HW_MACHINE, so instead of i386 or x86_64 being in hw.machine, it's your model name. I just moved the needed code to the right place and recompiled.

kernel by itself: http://nawcom.com/os...gacy_kernel.bz2
updated the pkg too: http://nawcom.com/os...-10.5.0.pkg.zip


Thank you nawcom. The revisions fixed the "vmware fusion" problems. You DO have to rename the kernel to "mach_kernel" as i found you had to with the 10.6.4 Legacy Kernel, and of course change the com.applle.boot.plist accordingly.

#46
nawcom

nawcom

    InsanelyMac Protégé

  • Retired Developers
  • 69 posts
  • Gender:Male
  • Location:localhost
  • Interests:Mind {censored}. Telephony.

Thank you nawcom. The revisions fixed the "vmware fusion" problems. You DO have to rename the kernel to "mach_kernel" as i found you had to with the 10.6.4 Legacy Kernel, and of course change the com.applle.boot.plist accordingly.


What I do is sudo mv mach_kernel mach_kernel.old; sudo ln -s legacy_kernel mach_kernel

That way you don't have to deal with losing it during the next update. There's no need to change the name of the kernel you boot, mach_kernel simply needs to link to the kernel you are using. That's my personal preference. That way there is no need to deal with kernel names when updating.

#47
Dellmantt

Dellmantt

    STILL LEARNING

  • Members
  • PipPipPipPipPipPipPipPip
  • 1,122 posts
  • Gender:Male
  • Location:AUSTRALIA

What I do is sudo mv mach_kernel mach_kernel.old; sudo ln -s legacy_kernel mach_kernel

That way you don't have to deal with losing it during the next update. There's no need to change the name of the kernel you boot, mach_kernel simply needs to link to the kernel you are using. That's my personal preference. That way there is no need to deal with kernel names when updating.

Thanks

#48
rvtk

rvtk

    InsanelyMac Protégé

  • Just Joined
  • Pip
  • 2 posts

With this kernel, I did NOT need the 10.6.4 kexts ...

Sweet, it works! Now all my hardware (HD5770, wifi and audio) also works like a charm with minimal kexting/changing the os.

#49
RayFlower

RayFlower

    InsanelyMac Protégé

  • Members
  • Pip
  • 18 posts

Thanks for pointing this out Nawcom.
I've changed the code in the diff as well.
Latest diff attached below ;)
I also did one more change: I put an #ifdef that removes the bad (causing reset) routines from the x86_64 kernel (but not i386 ofcourse).
Kernel attached below.


I'm afraid this gave me a instant reboot even with arch=i386 -force64 -v on my phenom ii x4, however the nawcom kernel works fine with i386 -force 64, using anvalv.

#50
dickhouse

dickhouse

    InsanelyMac Protégé

  • Members
  • PipPip
  • 71 posts
  • Gender:Male
  • Location:The Gunners HomeTown

I get some ACPI_Platform_powermanagement CPUID problem or something like that... saying that powermanagement may not work properly...

I get another thing saying something like patch_obj and decryption (will retry) and it just keeps repeating that till dmos is arrived or somethin..
.....
.....
.....



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

#51
Andy Vandijck

Andy Vandijck

    InsanelyMac Deity

  • Coders
  • 1,642 posts
  • Gender:Male
  • Location:Tienen
  • Interests:Programming stuff for Mac OS X...
    Hacking...
    Hard rock (also really big Metallica...

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.

#52
CoolFX

CoolFX

    InsanelyMac Protégé

  • Members
  • Pip
  • 21 posts
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

#53
Andy Vandijck

Andy Vandijck

    InsanelyMac Deity

  • Coders
  • 1,642 posts
  • Gender:Male
  • Location:Tienen
  • Interests:Programming stuff for Mac OS X...
    Hacking...
    Hard rock (also really big Metallica...

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.

#54
LeXa2

LeXa2

    InsanelyMac Protégé

  • Members
  • PipPip
  • 85 posts
  • Gender:Male
  • Location:Moscow, Russian Federation
  • Interests:IT, *nix, SciFi
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.
:P 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.

#55
Andy Vandijck

Andy Vandijck

    InsanelyMac Deity

  • Coders
  • 1,642 posts
  • Gender:Male
  • Location:Tienen
  • Interests:Programming stuff for Mac OS X...
    Hacking...
    Hard rock (also really big Metallica...

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

#56
dickhouse

dickhouse

    InsanelyMac Protégé

  • Members
  • PipPip
  • 71 posts
  • Gender:Male
  • Location:The Gunners HomeTown
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

#57
Andy Vandijck

Andy Vandijck

    InsanelyMac Deity

  • Coders
  • 1,642 posts
  • Gender:Male
  • Location:Tienen
  • Interests:Programming stuff for Mac OS X...
    Hacking...
    Hard rock (also really big Metallica...

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)

#58
mac_carol

mac_carol

    InsanelyMac Geek

  • Members
  • PipPipPip
  • 148 posts
  • Gender:Not Telling
Thanks a lot Andy (and also Nawcom) for this new update Posted Image

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)

Posted Image

#59
defix

defix

    InsanelyMac Protégé

  • Members
  • Pip
  • 6 posts
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.

Attached Files



#60
LeXa2

LeXa2

    InsanelyMac Protégé

  • Members
  • PipPip
  • 85 posts
  • Gender:Male
  • Location:Moscow, Russian Federation
  • Interests:IT, *nix, SciFi

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





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