Jump to content

[AMD] OS X El Capitan (10.11) FX Kernel Task Force


spakk
 Share

1,227 posts in this topic

Recommended Posts

Hey bro the same problems.Green icons laggish OS

lathos, thanks for your quick reporting, have you tested all kernels? If not then check the others kernels,plz.

Link to comment
Share on other sites

lathos, thanks for your quick reporting, have you tested all kernels? If not then check the others kernels,plz.

I have already check all of them.With the last one V5a it seems a little bit faster and the OS starts in safe mode by itself.

  • Like 1
Link to comment
Share on other sites

I have already check all of them.With the last one V5a it seems a little bit faster and the OS starts in safe mode by itself.

it is very annoying

  • Like 1
Link to comment
Share on other sites

it is very annoying

I know nothing about coding but I am semi-exprerienced in problems,sometimes they are not where you think they are.Thanks for all your efforts to keep amd hackintosh alive.

Link to comment
Share on other sites

we hope that we go now to the heart of the problem and can fix the issue, please check this kernel.

 

Edit:

I've found that the first kernel has crashes a few apps on my system (Phenom II X6), but first secondary.

... and here are two other kernels with small adjustments for FX CPUs

 

Edit:

Last Kernel without sseplus

 

Three kernel, three results!

V4 and V5a no "machdep.cpu.xsave.extended_state1"

post-1166679-0-68534700-1456334751_thumb.png

post-1166679-0-17772600-1456334774_thumb.png

post-1166679-0-61321000-1456334798_thumb.png

  • Like 1
Link to comment
Share on other sites

Three kernel, three results!

V4 and V5a no "machdep.cpu.xsave.extended_state1"

 

very interesting.... oops, there's something went wrong in V4 and V5a   :)

  • Like 1
Link to comment
Share on other sites

I know nothing about coding but I am semi-exprerienced in problems,sometimes they are not where you think they are.Thanks for all your efforts to keep amd hackintosh alive.

That's what i'm thinking but this issue is cpu related (fx) so it probably has to do with the kernel.

  • Like 1
Link to comment
Share on other sites

That's what i'm thinking but this issue is cpu related (fx) so it probably has to do with the kernel.

Because I wanted to go a different way, and have forgotten ....to insert the reference., my mistake

Link to comment
Share on other sites

Hey guys. It just dawns on me that the whole opcode emulation thing is not the only way to go.
You could have the Kernel detect any dynamic loading of libSystem and redirect the offending SSE-optimized string functions (memset/memmove et ali) to either safe functions in the comm-page or another newly mapped area in the process' memory. Well, there could be a few ways to go about this, but the general idea is the same.
This would be a metric bajillion times faster than going thru the kernel call on every single offending instruction.

hmmmmm I'm kinda sorta curious about it now.

 

------------

 

Hell, we even have the source code to the system dynamic loader, so we could stuff the $amd symboled versioning in there and do all the re-routing even in ring3 space there. This is the less barbaric way but that would require lots of reversing and coffee.

Plus the names won't change much, this is all POSIX stuff.. AFAIK

Similarly the kernel also has a dynamic loader, for Kext purposes, and the crypto stuff that uses SSE primitives could be forcefully re-routed on a case-by-case basis to safer versions somewhere. That's the easier of the two, i believe. Apart from the long debugging hours, that is!


Edit #499305: As I recall one of the problems I had with this approach before writing the opemu is that the dynamic linker itself used a private version of these optimized libc functions. So it was a circular problem. We could EITHER bootstrap this at first using the fallback in-kernel opemu or throw the towel in and try to build a custom dynamic linkers ourselves from the sources, which might cause us to lose some OS X features, not entirely sure on that. It should be legal though to distribute the binary?


Edit #499306: AFAIK the graphical frameworks like Aqua inline their memcopy/memmove operations to make sure image blitting is as fast as possible, that's a big problem- and possibly the source of graphical corruption here. Who knows, it's been a while now.

  • Like 5
Link to comment
Share on other sites

@Sinitek, many thank for your present, and your immeasurable support to fix this darn trouble, ...the coffee goes on the AMD community :-)))

  • Like 1
Link to comment
Share on other sites

please test and post : sysctl machdep.cpu.xsave.extended_state machdep.cpu.xsave.extended_state1

Edit:

please test only on a second partition.

10.11.2-AMD_6_xsave.zip

10.11.2_SSEPlus_V4-Test_a.zip

10.11.2_SSEPlus_V5a.zip

  • Like 1
Link to comment
Share on other sites

hmmm, AMD_6_xsave boots on my system, the others too..

kern.osrevision: 199506
kern.version: Darwin Kernel Version 15.2.0: Do 25 Feb 2016 18:25:10 CET; mein:10.11.2-AMD_6_xsave/BUILD/obj/RELEASE_X86_64
kern.maxvnodes: 132057
kern.maxproc: 1064
kern.maxfiles: 12288
kern.argmax: 262144
kern.securelevel: 0
kern.hostname: spakks-mac-pro
kern.hostid: 0


now i'll test the kernel on my APU system and report.

Edit:

I can also confirm, opcode error on my APU system with AMD_6_xsave

I will revise the value and build a new

Edited by spakk
Link to comment
Share on other sites

  • 2 weeks later...

any news?

Unfortunately No!, all kernel programmers have either no time or no desire to help, or do not have Macintosh/hackintosh-system* to help us.... or do not reply to our request ......

Shaneee, Duran and I have tried everything possible to help, unfortunately, has not been able to realize a perfect kernel. B)

 

(*but many thanks for your quick answer Tora Chi Yo)

Link to comment
Share on other sites

Unfortunately No!, all kernel programmers have either no time or no desire to help, or do not have Macintosh/hackintosh-system* to help us.... or do not reply to our request ......

Shaneee, Duran and I have tried everything possible to help, unfortunately, has not been able to realize a perfect kernel. B)

 

(*but many thanks for your quick answer Tora Chi Yo)

 

Hey, did you try what sinetek was talking about? 

Link to comment
Share on other sites

Hey, did you try what sinetek was talking about? 

not easy for me  ^_^ ... too much time, high power consumption, and nerves invested for nothing ...I will do this in the future less or do nothing more ....

  • Like 2
Link to comment
Share on other sites

If you need someone to test your kernels, let me know. I have a lot of time and as you can see on my signature I have an AMD-FX 8350. I want to help as much as possible to solve these problems so annoying.

Link to comment
Share on other sites

If you need someone to test your kernels, let me know. I have a lot of time and as you can see on my signature I have an AMD-FX 8350. I want to help as much as possible to solve these problems so annoying.

he meant, that he has not a FX CPU, to analyze the causes of the problems on a running system in order to fix the cause into kernel source.

Link to comment
Share on other sites

he meant, that he has not a FX CPU, to analyze the causes of the problems on a running system in order to fix the cause into kernel source.

 

I know, but my reply wasn't for him. I meant that if the people who is working in order to build a kernel without graphics problems needs someone with a FX CPU to test it, then I can help because I have an AMD-FX 8350.

 

\/

 

Unfortunately No!, all kernel programmers have either no time or no desire to help, or do not have Macintosh/hackintosh-system* to help us.... or do not reply to our request ......

Shaneee, Duran and I have tried everything possible to help, unfortunately, has not been able to realize a perfect kernel. B)

 

(*but many thanks for your quick answer Tora Chi Yo)

 

I'm not programmer but I can help testing your kernels. I don't know if you understand me :P

Link to comment
Share on other sites

 Share

×
×
  • Create New...