Jump to content

Mavericks kernel testing on AMD (formerly Mountain Lion kernel testing on AMD)

theconnactic

By theconnactic,
in OS X 10.9 (Mavericks)

 Share
6,414 posts in this topic

Recommended Posts

JorgeMax
JorgeMax
Posted
Posted

Andy, I have to put this boot flag "machdep.cpu.processor_flag: 1" in the selection screen boot system? it must input this? my processor is a Phenom II X4 if I do not enter, it will not work? and I have to rename it to "mach_kernel"?

Link to comment
Share on other sites
Andy Vandijck
Andy Vandijck
Posted
Posted

Andy, I have to put this boot flag "machdep.cpu.processor_flag: 1" in the selection screen boot system? it must input this? my processor is a Phenom II X4 if I do not enter, it will not work? and I have to rename it to "mach_kernel"?

No it is a sysctl argument set by the kernel.

It will work just fine with default boot arguments.

Link to comment
Share on other sites
Andy Vandijck
Andy Vandijck
Posted
Posted

does this latest kernel suffers from "32/64 bit opemu wrong instruction" bug existing in 10.7 series kernels?

thanks in advance

ps: the only ways i know to reproduce this bug is executing (or compiling) Maxima software (http://en.wikipedia.org/wiki/Maxima_%28software%29)

This version of the kernel will except that show the instruction in hex it is trying to emulate.

This way we know which instructions to add to the opemu.

  • Like 1
Link to comment
Share on other sites
Andy Vandijck
Andy Vandijck
Posted
Posted

Andy, do you mean the kernel will print error messages in the Console?

 

What kind of messages should i be looking for?

 

All the best!

Opemu invalid kernel instruction (instruction here)

Andy I have this in the console. Is it related?

 

error.png

No its part of IOHIDFamily.kext
Link to comment
Share on other sites
Shaneee
Shaneee
Posted
Posted

Opemu invalid kernel instruction (instruction here)

No its part of IOHIDFamily.kext

 

Ahh ok was just it said kernel. Nothing related to opemu in the console so far. Glitches are still present but not as bad as they used to be.

 

Edit: Forgot to mention I'm running 10.8.4

Link to comment
Share on other sites
Bronya
Bronya
Posted
Posted

I made a 10.8.3 kernel.

I also modified the opemu sources so that if it encounters an invalid opcode it will print 8B of the instruction buffer.

This way we can trace this in both kernel space and user space.

Invalid opcode in kernel opemu will also no longer call panic trap but just show the above and return.

I hope this will make VMWare / VirtualBox work with the opemu.

I also modified the code for the processor flag.

On Intel CPU it will use the MSR and on AMD CPU it will always set it to 1.

It is the value in sysctl -a like this:

machdep.cpu.processor_flag: 1

So I put this for AMD also on 1.

Sources are included.

Could you guys please test and report back?

Thx. 

Hello ! :)

I copy your's opemu from SinetekBronzovkAnVoodoo_RC5.diff .

And compile my kernel and tested :

1) with your opemu and my kHasSSE4_2:

post-31928-0-12068900-1371669435_thumb.jpg

2) with my modified opemu and kHasSSE4_2: but only your mach_kernel is normal graphics.

post-31928-0-20671500-1371669445_thumb.jpg

 

3) your kernel wrong show cache_size  :

post-31928-0-31275500-1371669470_thumb.png

4) my kernel normal show cache_size :  

post-31928-0-81374600-1371669460_thumb.png

 

With your opemu i getting panic by parallel desktop .V

Vmware normal working.

 

I tested on my old athlon x64 dual core !

 

Please see In my attachment my modified opemu :) ! My opemu don't working parallel desktop , i no fix . 

opemu_work.zip

  • Like 3
Link to comment
Share on other sites
Andy Vandijck
Andy Vandijck
Posted
Posted

Hello ! :)

I copy your's opemu from SinetekBronzovkAnVoodoo_RC5.diff .

And compile my kernel and tested :

1) with your opemu and my kHasSSE4_2:

19062013145.jpg

2) with my modified opemu and kHasSSE4_2: but only your mach_kernel is normal graphics.

19062013146.jpg

 

3) your kernel show don't right cache_size :

Снимок экрана 2010-01-01 в 3.06.01.png

4) my kernel normal show's cache_size :

Снимок экрана 2010-01-01 в 3.04.31.png

 

Please see In my attachment my modified opemu :) !

opemu_work.zip

Cool! Thanks bronzovka.

EDIT: I've rewritten the cache info parts like with your diff.

I also did some more work on the CPU microcode parts.

I've implemented your fixed opemu too.

Post when done (RC6) ;)

  • Like 1
Link to comment
Share on other sites
Andy Vandijck
Andy Vandijck
Posted
Posted

I've fixed the cache size thanks to your diff...

EDIT: Bronzovka tested it, cache size is indeed fine. (tested on AMD Athlon64 x2)

We still need FX tests on it to check...

Yep... I fixed it in cpuid.c

Other testers please?

Thanks. :D

Source included.

EDIT2: Could somebody please do the following 2 command on AMD and post the results?

sysctl -a | grep microcode

sysctl -a | grep processor_flag

EDIT3: Bronzovka tested it and microcode version and processor flag are properly 21 and 1 :)

amd_kernel.zip

SinetekBronzovkAnVoodoo_RC6.diff.zip

  • Like 6
Link to comment
Share on other sites
kulfon77
kulfon77
Posted
Posted

I have a question about pmulhrsw in opemu:

 

void pmulhrsw128(XMM *src, XMM *dst, XMM *res)
{
    int i;
    for(i = 0; i < 8; ++i)
        res->a16[i] = (((dst->a16[i] * src->a16[i] >> 14) + 1) >> 1);
}

After multiplicating two 16bit numbers we get 32bit, shifting 14bit right leaves 18bit, so to make it 16bit again we need to shift it 2 bits right, right?

 

        res->a16[i] = (((dst->a16[i] * src->a16[i] >> 14) + 1) >> 2);

Or am I missing something? :D

Link to comment
Share on other sites
Andy Vandijck
Andy Vandijck
Posted
Posted

I have a question about pmulhrsw in opemu:

 

 

void pmulhrsw128(XMM *src, XMM *dst, XMM *res)
{
    int i;
    for(i = 0; i < 8; ++i)
        res->a16[i] = (((dst->a16[i] * src->a16[i] >> 14) + 1) >> 1);
}

After multiplicating two 16bit numbers we get 32bit, shifting 14bit right leaves 18bit, so to make it 16bit again we need to shift it 2 bits right, right?

 

 

        res->a16[i] = (((dst->a16[i] * src->a16[i] >> 14) + 1) >> 2);

Or am I missing something? :D

Gcc's testsuite defines it like this:

 

/* Routine to manually compute the results */
static void
compute_correct_result (int *i1, int *i2, int *r)
{
  short *s1 = (short *) i1;
  short *s2 = (short *) i2;
  short *sout = (short *) r;
  int t0;
  int i;

  for (i = 0; i < 8; i++)
    {
      t0 = (((int) s1[i] * (int) s2[i]) >> 14) + 1;
      sout[i] = (short) (t0 >> 1);
    }
}

Where r = i1 operation i2

EDIT: So it is correct... :D (the way it is)

Link to comment
Share on other sites
Andy Vandijck
Andy Vandijck
Posted
Posted

Well, thanks for the answer, yet it still looks strange to me. I got confused after reading this: http://pl.wikibooks.org/wiki/Asembler_x86/Instrukcje/SSSE3/PMULHRSW

Interesting.

The info on that page is different.

Still if you run the gcc testsuite for it it checks out on Intel.

I made a testsuite for the opemu a long time ago. (Somewhere on this thread)

Link to comment
Share on other sites
theconnactic
theconnactic
Posted
  • Author
Posted

 

Andy Vandijck , cache_size only from cupid.c ))

My cupid.c is new ...

Bronzovka, although I can confirm the cache misreporting bug with Andy's kernel, it must be noted it also reports ssse3 instructions instead of sse4.2, and i think this relates to the fact that both his kernels are the most stable, even for 10.8.4. With your latest 10.8.3 kernel, I got glitches so heavy that the system was rendered unusable.

 

All the best!

Link to comment
Share on other sites
Bronya
Bronya
Posted
Posted (edited)

Bronzovka, although I can confirm the cache misreporting bug with Andy's kernel, it must be noted it also reports ssse3 instructions instead of sse4.2, and i think this relates to the fact that both his kernels are the most stable, even for 10.8.4. With your latest 10.8.3 kernel, I got glitches so heavy that the system was rendered unusable.

 

All the best!

Yes ! But i found and fixed opemu.  i test my new kernel with sse4_2on athlon x64 ... !   :)

Edited by Bronya
  • Like 1
Link to comment
Share on other sites
carlo_67
carlo_67
Posted
Posted

works well Phenom 2 x6 1075T, start more 'fast, good fluidity', with and without DSDT,
unfortunately always with graphical artifacts, I hope will be resolved soon

anyway great job, I'm confident

ps: sorry for my english

Carlo_67

Link to comment
Share on other sites
spakk
spakk
Posted
Posted (edited)

Hi Andy, I have tested your current kernel for ML10.8.3  with ML10.8.2, it boots, but after a few minutes I get a Kernel Panic, I think that the cause of the kernel panics is not your current kernel. I started the DarwinDummper before the kernel panic, maybe someone can see where the cause is :(

  Global Memory (PCIe):   0 MB

:(

 

in the Diagnostic Report folder I find a CVMCompiler.crash -.> OpenGL.framework problem with CVMCompiler

DarwinDumper_2.7.5_Chameleon_2.1_ML_mein.zip

Edited by spakk
Link to comment
Share on other sites
 Share
Go to topic listing
×
×
  • Create New...