Hello!

new kernel + amd_insn_patcher = all problems solved for me ^_^

Thank you R:A:W:X86 (Y)

http://i.imgur.com/dcUpf.png


I'm using VoodooPower, you too?
--> Here are switching stages very well, but the turbo core I do not think it works right?

--> Is there any way to switch the fancy name that appears on the processor? only to not get the same aesthetic as "unknown." it is possible to change this?

---> The kext that is with the patch, ("IOHIDFamily_nointervalcheck.kext.zip") is always necessary to use, or only in some particular case?

Again: No working 64-Bit Kernel.
In OS X no 64-Bit Kernel - but SSSE3 instruction set capable CPU (Lion) - is needed for running 64-Bit applications.

I had to remove some old routines from the Kernel patch that had been causing problems during boot. Missing these may cause tsc sync problems, while stepping with that kext - those routines are way old and may no longer be needed in latest VoodoPower provided by AnV - I am not sure though... use with care.

You could use
Macintosh used CPU names only of course, i.e. 1281 will report an Quad-Core Xeon...

That kext is unrelated to the amd_insn_patcher.
It fixes some check that causes boot hang at No interval found for . Using 8000000 - otherwise not needed.

One issue remains... font rendering is wrong in some apps.

Can you describe with more details, what the problem is?

http://img833.imageshack.us/img833/3...0722173427.png

this happens only to third-party apps, as i can see... all native apps look as they should.

ps not all third-party apps, opera e.g. looks good.

Be sure to patch dyld & libsystem_kernel.dylib only - do not touch any other files in /usr/lib with amd_insn_patcher

:)

@ R:A:W:X86


hello,

I went further in my tests, everything works perfectly in 32 bit, I no longer applicable QuickTime bug (video capture) works as well as everything else, I installed my HD 4850 1GB (HDMI / VGA / DVI) I only have DVI, it is already well 1280x1024x32 @ 75 hz Halleluya!

I encounter the problem of the network, regardless of the network card used, can not establish the connection (dlink 528 tx / rtl 8139 on the motherboard)

With kernel Dimitrk, but it works fine with your last kernel 11.4, impossible to make them work.

http://img15.hostingpics.net/thumbs/...10142407AM.png


http://img15.hostingpics.net/pics/96...10142054AM.png


http://img15.hostingpics.net/pics/72...10142512AM.png


http://img15.hostingpics.net/pics/94...10142204AM.png

Thanks, i forgot to unpatch libSystem.B.dylib... now unpatched and the problem has gone. :)

Just to compare staff performance with the latest kernel.

Share your friends! ;)

http://i.imgur.com/783Bb.png

//Update

With a fresh 10.7.4 install and only the two dyld´s patched manually the new kernel runs quite perfect! Yesterday I tested the kernel for about 2 hours without any issues. Copying, authorization, Appstore etc. pp. works fine!!

Thanks alot R:A:W:X86 ;)

http://img100.imageshack.us/img100/7793/ohnetitelp.png

misterfrista,think that the performance of our Bulldozer's is the standard? :)

icloud works well?

i got almost 6 in os x and same in windows 7 x64 (fx-8150)

i want to know how to compile the kernel(how to patch)? how to use the .diff files?:)thank you!

I have no problem using the same kind of onboard device on both setups...
Maybe try to delete the device from Network.prefpane then readd it?

How-To patch:
https://developer.apple.com/library/...1/patch.1.html

How-To compile:
http://objc.id.au/post/10101528120/c...-x-10-7-kernel

@felipeunix: I´ll test icloud when i am home ;)

Anyone tried xcode yet?
Maybe i´ll give it a try today.. :)

Unless anyone has PURE 64-bit running on the machine, with the FX Kernels etc. Xcode Will NOT Work.
It's Pure 64-Bit for the Core Program

Hmmm..... I Found More Info On How XPCHelper Works Here:
https://developer.apple.com/library/...echnology.html

Interesting It Tells What Is Involved in XPCHelper
and Maybe We Can Look Into it To Try and Patch Stuff?

With this latest kernel as it was for folks who do not have bulldozer?

have to apply the patch not to freeze applications on 32bit mode?

In case you are talking about 64-Bit KERNEL:

Please get correct information, before spreading your wrong assumption as a fact!

http://support.apple.com/kb/HT4287

Thanks!

Not to mention, that I used to explain this, just two pages back in this thread...

WTF are you talking about? this makes no sense what-so-ever I've tried, Xcode for Lion is a 64-Bit App. and I Tried Running it through 32-bit and the Unsupported message occurs,
so idk wtf you are talking about I never mentioned a thing regarding what you posted in the link. In fact that link is irrelevant to what I was saying,
k?
thanks.

I´ve tried the latest Xcode yesterday just for fun.
At least I am able to install it successfully with the latest kernel.
I´m also able to install the Commandline utils etc.
Compiling things with xcodebuild runs fine, but building the kernel is a no-go as cxxfilt gives errors with make command!

Its not important for me, just wanted to see it myself ;)

Seems like at least the commandline utils work as I am able to compile and use Macports without any problem!

woah.

i'm not going to say too much here

but thanks to r a w and this thread, i've got lion running in VM, FINALLY running all the osx apps full throttle without crashing

i've learned a lot along the way about osx86

big kudos to r a w for this kernel and the insn patch.

i only wish it natively supported my dual 7770s ;)

but, i can live. thanks

and also, completely disregarding the forum's double post rules.....

http://i660.photobucket.com/albums/u...kane20clap.gif

THANK YOU

;) (Y)

"@@ -292,6 +292,10 @@
panicstr = str;
paniccpu = cpu_number();
panicwait = 1;
+
+ kdb_printf("In case you read this there has been a kernel panic.\n"
+ "There is no ----ing support for running Lion on AMD.\n"
+ "You have to try fixing this yourself.\n\n");

PANIC_UNLOCK();""

Taking a look at your code, RAW, i couldn't let this piece go without any comments: you're an artist! Reading this message at my first kernel panic with your kernel made me laugh out loud even being mad about my system crashing. It was sort of relieving in the face of utter frustration. Congrats!

Seriously, one question: your kernel is i386, as you said before, since it's based on anterior patched kernels (AndyVand, Bronzovka) that are all i386. But the original vanilla kernel - correct me if i'm wrong, please, here i'm way beyond my field of knowledge - is x64_86, right?, and those i386 patched kernels are all based in this single x64_86, is that correct?

So why is not possible to build a AMD_64 kernel based on x64_86? Why the patched ones seemingly have to be 32-bit? Or did Apple release a dumbed-down kernel as open source? Thank you in advance.

Another one: is there any public knowledge base provided by AMD, where one can look for especifications of, say, Bulldozer CPUs and how low-level and higher-level programming should be projected for them?

That long set of hex numbers, are them assembly code? If yes, are they the original assembly code of vanilla (therefore, intel assembly)?

thank you!:)

Nope.
The Vanilla Kernel in 10.6 & 10.7 is a fat binary that contains an i386 and a x86_64 Kernel.

On a real Mac it i.a. depends on wether the Firmware is 32 or 64-Bit what can Kernel is / can be loaded.

The i386 Kernel still allows running 64-Bit applications, in case of a compatible CPU.
Support for non-64-Bit CPUs has been dropped in 10.7 (even from the 32-Bit Kernel), though it is reimplemented in the patched Kernel, as this "compatibilty / legacy mode" is currently the only way to boot 10.7 using non-SSSE3 CPUs (all old AMD).

In 10.8 the Kernel is 64-Bit only, so even Intel Macs with 64-Bit compatible CPU, but 32-Bit Firmware are dropped from support.

As for 10.7 it is rather unimportant wether you are booting i386 or x86_64 Kernel (speaking for owners of fully compatible / SSSE3 capable CPUs) - it does not have influence on the applications you are running - most likely it will only matter for you in case you have some 3rd party Kernel Extensions, i.e. printer drivers that are either i386 or x86_64 only.

Well it is possible to build the x86_64 Kernel from the patched source code.
But for some reason it does instant reboot on AMD setups, while it works on my Vanilla capable machines.

The latest 10.6.8 Kernel are the same - most AMD people encounter either instant reboot or AppleACPIPlatform.kext Panic when attempting to boot the x86_64 Kernel.

If someone is curious to try it himself, here is an universal build of the latest Kernel patch - use arch= flag to advice the Kernel you want to boot.

Well the AMD Developer Central contains some documentation, but it ain't that up-to-date as desireable...

Those are copyspace for binary injection of an autpatching dyld and a SSE3 emulator.
I don't see a reason to look into the rebasement of dyld (the released source code is incomplete), as 32-Bit Apps are working just fine by binary patching of sysenter traps - there is not any software left that peforms CPUID checks in -legacy mode either.
Injection of a SSE3 emulator is also pretty unimportant (for obvious reasons I think :D), but the methods of Kernel integration could be modified, in case someone could write an SSSE3 emualtor that works the same style as the old SSE3 one...

Thank you, RAW!

Well, Mountain Lion is here. For we AMD users, three options: change to Intel, stuck with Lion i386 64-bit suporting on FX line (or Snow Leo with full functionality for all other AMDs) or hope, crossing fingers, that someone wise enough to patch a working arch x64_86 kernel pops out of the blue.

RAW, i tried the 64-bit kernel. Instant reboot, as you told me. But, remember, i have a plain Athlon II x2. No ssse. So the question is - assuming the problem affects Bulldozers as well - why does this happen? Any clue?

I tried the kernel on x86_64 on my amd Athlon X2 7550 and it booted to the point where launchd would start up. no further, just like booting without -legacy
it says verbosely "Kernel is LP64" meaning 64-bit i've tried all the possible boot combination but it's a no-go.
SSSE3 emulator, how can it be so hard? (theoretically speaking) because there's only 16 new instructions that SSSE3 introduced.. hmm...

But why it doesn't boot, Justin? That's the question!

Indeed, it doesn't boot even with ssse3-enabled AMD FX series, as RAW x86 said before, so it isn't just a sss3-related issue, tha could be solved with an emulator.

Now don't let me be misunderstood: the emulator is important, as it would grant a full working Lion for almost every AMD user. We're in Mountain Lion era, though; without a working patched x86_64 kernel, in addition to a sss3 emulator for non-Buldozer users, the AMD hackintoshes will slowly fall into obsolescence.

Do not think the fight is over. Mountain Lion is here!!:D

The fight isn't over, but for the fight to be won, it's not enought for Mountain Lion to be here if it does not roar in AMD Hackintoshes, lol.

Interesting.
The patched x86_64 Kernel works on my Intel machines as well.
I have some suspicions what could be the problem for the majority of us AMD users here...

Would be cool if some other people with old / "pre-Phenom" AMD CPUs could try.

The src has been released as well.

For some reason xnu-2050.7.9 does not build for me wo errors... (unpatched of course)

I am not sure what I am missing - Xcode 4.5 probably?!
The problem may also be, that I am still kinda little drunken due to yesterday. :p
Someone else has tried to compile the Kernel yet?

i do have ML running just looking into the programms next too xcode we need wich prob be

cxxfilt-11

dtrace-96

kext_tools-268.7

but i cant figure out wich version of bootstrap_cmds it is

maybe someone else can ? meanwhile i dl new xcode .....i might get it up and running by tonite and give it a shot ..but my timeframe is limited so will se if i get it goin

is your ML run on amd or intel?

on a Commodore C16 +4

na on a MacBookPro :)

What would them be?

I tried to compile the kernel to no avail...

Differences between AMD64 and EM64T
There are a small number of differences between each instruction set. Compilers generally produce binaries that target both AMD64 and EM64T, making the differences mainly of interest to compiler developers and operating system developers.


Currently
EM64T’s BSF and BSR instructions act differently when the source is 0 and the operand size is 32 bits. The processor sets the
zero flag and leaves the upper 32 bits of the destination undefined.

AMD64 supports 3DNow! instructions. This includes prefetch with the opcode 0x0F 0x0D and PREFETCHW, which are useful for hiding memory latency.

EM64T lacks the ability to save and restore a reduced (and thus faster) version of the floating-point state (involving the FXSAVE and FXRSTOR instructions).

EM64T lacks some model-specific registers that are considered architectural to AMD64. These include SYSCFG, TOP_MEM, and TOP_MEM2.

EM64T supports microcode update as in 32-bit mode, whereas AMD64 processors use a different microcode update format and control MSRs.

EM64T’s CPUID instruction is very vendor-specific, as is normal for x86-style processors.

EM64T supports the MONITOR and MWAIT instructions, used by operating systems to better deal with Hyper-threading.

AMD64 systems allow the use of the AGP aperture as an IO-MMU. Operating systems can take advantage of this to let normal PCI devices DMA to memory above 4 GiB. EM64T systems require the use of bounce buffers, which are slower.

SYSCALL and SYSRET are also only supported in IA-32e mode (not in compatibility mode) on EM64T. SYSENTER and SYSEXIT are supported in both modes.

Near branches with the 0×66 (operand size) prefix behave differently. One type of CPU clears only the top 32 bits,
while the other type clears the top 48 bits.

may smth. of this be the clue?

As for me, i expect it not to be the clue. If we have to emulate more instructions yet than ssse3, then i think AMD hackintoshing is really at the verge of obsolescence.

I compiled a 10.7.4 kernel with a mix of patches with R:A:W 's patches and the anv's legacy kernel 0.5.1 for on the fly patching, it boots up for x86_64 and i386 without instant reboot. but gives a kernel panic near where launchd would start up...
I'll upload it soon for you to test.. I doubt you'll get any further than the KP tho, interesting that I am the only one who made a kernel that didn't instantly reboot....
http://www.mediafire.com/download.php?u3kbvqy9it4sjda

Great job, Justin! Cool that someone takes the torch from RAW and keeps it running for AMD machines. If a 64-bit kernel is really built, we can even make it to Mountain Lion someday!

Did you ran your kernel on a FX series CPU, or on an older series (therefore, lacking the need of ssse3 support)? Can you upload a screen of your KP, for us to help identify the causes?

Thanks in advance!

Yes, I Will do that, I'm trying to compile the kernel again making some patches to see if it changed anything, but I tested it on a normal NON ssse3 amd cpu,
AMD Athlon X2 7550

the KP is NOT related to ACPI like in the previous kernels for Snow Leopard. It's to do with the patcher I think, Let me upload a screenie soon ^_^
In the meantime, Please try it yourself and let me know your results

I'll do just that, but i'm afraid i'll get similar results, since i have a similar dual core, one generation newer, an Athlon II X2 250. Two questions:

1) The KP you got was when booting arch X64_86? Or both archs?

2) Assuming it's possible to boot arch=i386, did it give you 64-bit apps support on your 32-bit non ssse3 capable system? It would be an important thing to know, because it would be a step further even without a true 64-bit kernel with 64-bit extensions (the latest RAW kernel give 64-bit support for i386 kernels, but only on ssse3 capable CPUs).

Thank you, and keep up the good work!

Any boot flag gives that KP, it has something to do with the integration of the on the fly patcher...

good work Justin , i'd really love to test ur kernel as soon i get a new HDD keep the hard work guys

Good work! :D

Maybe with std_dyld=Yes could work

With FX and useflags: -v busratio=155 npci=0x2000 arch=x86_64 I get instant reboot!

Well your KP most likely has to do with the binary opcode parsing, that's why the code changes in mach_loader.c are excluded from my patch.

Like I wrote previously, there is not any more need for CPUID parsing in Lion (there is not any application that needs it) + 32-Bit Apps are working for the 64-Bit capable users just fine by binary patching.
That's why I haven't made any attempt to fix this...

Ehm mate - no offense, but I think you are missing something:

I think it has something to do with the CPU identification routines, why the 64-Bit Kernel boots for you, while it reboots for many others.

The fact that I can boot the x86_64 Pcj XNU on Snow Leopard on my FX machine kinda proves this hypothesis.
Sadly that guy has not ever released any source code (like many other people in the scene). -.-

I will start looking further into this during the next weeks...
...I am currently busy trying some Mountain Lion stuff. :p

It is the same for me - both Kernel don't work at all not x86_64 nor i386 - just instant reboot.