TASK FORCE - [AMD] to missing SSE4.1 Instruction set - older CPUs on macOS Sierra (10.12.x)

[spakk]

I am just building the kernel and will report later

I will now check this kernel with my CPU and report later

 

Edit:

I've made a video and will upload it later

AMD10.12.6-SSE4.1.zip

[ydeng]

I am just building the kernel and will report later

I will now check this kernel with my CPU and report later

 

Edit:

I've made a video and will upload it later

None of these instructions is sse4.1.  I turned on printing for all instructions executed by opemu.  You may selectively print to see boot messages.

[spakk]

None of these instructions is sse4.1.  I turned on printing for all instructions executed by opemu.  You may selectively print to see boot messages.

I'll look where I made the mistake

[AXAXAXAXAXAX]

None of these instructions is sse4.1. I turned on printing for all instructions executed by opemu. You may selectively print to see boot messages.

I managed to boot into single user mode. Can I do something useful there?

[spakk]

I managed to boot into single user mode. Can I do something useful there?

IMG_1918.JPG

Insert the USB dummies into S/L/E and test again

USB-Fix.zip

[AXAXAXAXAXAX]

Insert the USB dummies into S/L/E and test again

[spakk]

what a mainboard you have?

[AXAXAXAXAXAX]

what a mainboard you have?

Asrock N68C-S USS

 

Now I stuck at this point:

The cursor doesn't respond to my USB mouse but USB keyboard seems to be working.

[spakk]

Asrock N68C-S USS

 

Now I stuck at this point:

IMG_1928.JPG

The cursor doesn't respond to my USB mouse but USB keyboard seems to be working.

 

1. can not find information to your controller, start systeminfo.app or dpci-manager.app and see which controller is installed

2. or put this into org.chanmeleon.boot.plist, may it can help?

    USBBusFix

    Yes

 

3. if possible boot with -v -f or with -s ..etc

 

4. Which drivers are in extra/extensions?

[ITzTravelInTime]

so do this means that we have a working kernel? or what? I am waiting for something to test on my q6600

[spakk]

I do not think so now, but we can hope soon

[spakk]

do you have solved the problem ?

[AXAXAXAXAXAX]

do you have solved the problem ?

I guess there is a bug somewhere in opemu, probably in sse41.c. I added printf in sse41.c and the kernel started working and it doesn't matter what to put in printf, it will work while printf is there. Here is some reference to that https://stackoverflow.com/questions/6079865/why-does-a-printf-stop-a-crash-from-occuring/6079878#6079878

 

and here is my test kernel. i put dots in printf in it to be able to see other print

kernel.zip

[spakk]

I guess there is a bug somewhere in opemu, probably in sse41.c. I added printf in sse41.c and the kernel started working and it doesn't matter what to put in printf, it will work while printf is there. Here is some reference to that https://stackoverflow.com/questions/6079865/why-does-a-printf-stop-a-crash-from-occuring/6079878#6079878

 

and here is my test kernel. i put dots in printf in it to be able to see other print

so now it stops at this endless loop with Opemu: UD2 error.

What changes you have made?

[AXAXAXAXAXAX]

so now it stops at this endless loop with Opemu: UD2 error.

What changes you have made?

I've used ydeng's patch and added printf in op_see41_run. That's all

and printf should be disabled in other places in opemu because it will get a kernel panic if it isn't.

[AXAXAXAXAXAX]

New test kernel

 

Edit:

It boots to the white screen with loading cursor but then the system shuts down with this log

kernel.zip

[spakk]

I think it has something to do with the graphics card

 

Edit:

this is my test result

[ydeng]

I've used ydeng's patch and added printf in op_see41_run. That's all

and printf should be disabled in other places in opemu because it will get a kernel panic if it isn't.

Where did you put the printf exactly?  I see a whole bunch of sse4.1 instructions on your single user mode boot screen.  There is some strange side effect going on.

[AXAXAXAXAXAX]

Where did you put the printf exactly?  I see a whole bunch of sse4.1 instructions on your single user mode boot screen.  There is some strange side effect going on.

i put it just above of switch statement of mnemonic.

[ydeng]

i put it just above of switch statement of mnemonic.

Do you have the full log of single user mode?

[spakk]

Do you have the full log of single user mode?

this is correct, you can boot only with "single user mode", every other input goes into a kernel panic

sory, a misunderstanding

 

Edit:

but the information that "AXAXAXAXAXAX" has made regarding printf () in sse41.c, can not be alone, there must be other changes in the source. he should check the source again

I do not get the same effect with the changes as the last kernel from "AXAXAXAXAXAX" , therefore there must be something else changed.

[AXAXAXAXAXAX]

Do you have the full log of single user mode?

this is correct, you can boot only with "single user mode", every other input goes into a kernel panic

sory, a misunderstanding

 

Edit:

but the information that "AXAXAXAXAXAX" has made regarding printf () in sse41.c, can not be alone, there must be other changes in the source. he should check the source again

I do not get the same effect with the changes as the last kernel from "AXAXAXAXAXAX" , therefore there must be something else changed.

I think only printf in sse41.c affected that. But I'll check it with clean sources and report later.

 

Edit:

I applied ydeng's patch onto sourses, commented printf in opemu_ktrap and opemu_utrap in opemu.c and enabled printf in op_sse41_run in sse41.c and built this kernel and it doesn't get kernel panic

kernel.zip

 

[ydeng]

IMG_1961.PNG

IMG_1962.PNG

IMG_1964.PNG

IMG_1965.PNG

IMG_1966.PNG

IMG_1967.PNG

IMG_1969.PNG

 

I think only printf in sse41.c affected that. But I'll check it with clean sources and report later

This looks like some kind of race conditions.  The instructions are working.  But the results are committed  to xmm registers directly.  If something else happens between the trap return and thread continuation, content of xmm registers might be missed up.  Could you put printk the value of op_obj.ring0 as well?

[ITzTravelInTime]

so the emulation is working right? we are close, but there is the need for some check for the results, or other wise the content of the xmm registers will not the rigth, If I have understood correctly

[AXAXAXAXAXAX]

This looks like some kind of race conditions.  The instructions are working.  But the results are committed  to xmm registers directly.  If something else happens between the trap return and thread continuation, content of xmm registers might be missed up.  Could you put printk the value of op_obj.ring0 as well?

It is always 0