Jump to content

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

Mountain Lion AMD legacy kernel x64_86 ssse3 ssse3 emulator

  • Please log in to reply
6351 replies to this topic

#161
theconnactic

theconnactic

    Stubborn AMD user

  • Local Moderators
  • 2,944 posts
  • Gender:Male
Hi, bcobco! Did you find the source code for their sse3 emulator inside that site? It isn't in the .pdf, which i'd already have. And yes: i think it's better to continue an existing project - and i think voodoo team won't mind, since they abandoned it - than start a new fork all from the beginning.

Important news: today we have a new soldier in our ranks. In fact, a veteran and decorated hero of the AMD kernel crusades. I'm talking about Nawcom, who is since this morning trying his patches on the Mountain Lion kernel. With his help, our chances are vastly improved: Nawcom, as anyone here should know, is the author of the very successful Snow Leopard legacy kernel. Regardless of his success at the short term, i think very highly valuable info and insights will come from his work.

As for me, i still haven't tried those experiences i talked about friday, but today is the day. I'll keep you updated.

#162
MacFaulty

MacFaulty

    InsanelyNut

  • Members
  • PipPipPip
  • 158 posts
  • Gender:Male
  • Location:Tulip & Cheese country
  • Interests:IT Management and creating web apps

Hi, bcobco! Did you find the source code for their sse3 emulator inside that site? It isn't in the .pdf, which i'd already have. And yes: i think it's better to continue an existing project - and i think voodoo team won't mind, since they abandoned it - than start a new fork all from the beginning.

Important news: today we have a new soldier in our ranks. In fact, a veteran and decorated hero of the AMD kernel crusades. I'm talking about Nawcom, who is since this morning trying his patches on the Mountain Lion kernel. With his help, our chances are vastly improved: Nawcom, as anyone here should know, is the author of the very successful Snow Leopard legacy kernel. Regardless of his success at the short term, i think very highly valuable info and insights will come from his work.

As for me, i still haven't tried those experiences i talked about friday, but today is the day. I'll keep you updated.


Nawcom's back? I'll give him my best wishes for it's successfull work and wish him all luck he can get to get through his medical issues.

#163
Lordadmiral Drake

Lordadmiral Drake

    InsanelyMac Sage

  • Members
  • PipPipPipPipPipPip
  • 415 posts
  • Gender:Male
  • Location:Austria
Cool, now we have a REAL capacity to work on the kernel :)

Too bad my programming skills are basic to say the least, or I'd help out on that too

#164
ZackehSoul

ZackehSoul

    InsanelyMac Protégé

  • Members
  • PipPip
  • 65 posts
  • Gender:Male
  • Location:Leeds, UK

I'm talking about Nawcom, who is since this morning trying his patches on the Mountain Lion kernel.

Which IRC is he usually in? Have you told him about #LegacyKernel?

#165
bcobco

bcobco

    InsanelyMac Geek

  • Members
  • PipPipPip
  • 142 posts
  • Gender:Male
  • Location:Argentina
xnu-dev project is abandoned

http://code.google.c...wiki/SourceCode

the only working link is the one with the old implementation (the bad one) the second implementation i dont find it

#166
theconnactic

theconnactic

    Stubborn AMD user

  • Local Moderators
  • 2,944 posts
  • Gender:Male
Well, time to do my own promised experiments.

As i posted before, i'm going to

Remove core crypto altogether,

Patch the bcopy.s and combine both.



#167
theconnactic

theconnactic

    Stubborn AMD user

  • Local Moderators
  • 2,944 posts
  • Gender:Male
UPDATE: No luck yet: the voodoobuild.sh is not working. Without it, all i have is two diff files (one for bcopy_64_sse3.s, other for bcopy_64_ssse3.s) that are incomplete and so useless.

Trying to remove corecrypto, to see where it takes me (i think i know, but...)

#168
theconnactic

theconnactic

    Stubborn AMD user

  • Local Moderators
  • 2,944 posts
  • Gender:Male
UPDATE AGAIN: well, stuck in the same place as zchef2k. Now i'll check out if Lion has the core crypto file and, if it has, replace the one of Mountain Lion for it.

#169
theconnactic

theconnactic

    Stubborn AMD user

  • Local Moderators
  • 2,944 posts
  • Gender:Male
ONE MORE UPDATE: Without the corecrypto.kext, or editing its plist replacing its last string for "Safe Boot" (a trick i learned at Netkas site), the result i get is the same as zchef2k, post #132. Won't even post any pictures because of that.

#170
bcobco

bcobco

    InsanelyMac Geek

  • Members
  • PipPipPip
  • 142 posts
  • Gender:Male
  • Location:Argentina
seems that nawcom is member of that project (?)




xnu-dev mailing list:

http://groups.google.com/group/xnu-dev

#171
theconnactic

theconnactic

    Stubborn AMD user

  • Local Moderators
  • 2,944 posts
  • Gender:Male
Hi, folks!

Just summarizing what we've already achieved, to help newcomers in this topic to get a grasp of what's going on:

- Firstly, we tried removing bad ID calls inside XNU/osfmk/i386/cpuid.c and a few other files, as stated in post #83. Limiting ourselves to do this, we could get the system to boot on an AMD machine to the point all hfs files are read, then it freezes in a black screen before the point console output would start (the "vanilla" behavior on an unsupported CPU would be an instant reboot);

- Realizing it would be not enough, i decided to apply the highly successful AMD patch from RAWx86 (bronzovkaANVoodoo) to the Mountain Lion XNU kernel. Since the patches were designed for use with 10.7.4 Lion, i had to do myself some adaptations to the kernel to compile. The output kernel is at the post #118. This kernel gives us a kernel panic backtraced to corecrypto.kext, as you can see in post #122, right after the kernel starts to run. Anyway, it takes us farther than our first experiment;

- Removing corecrypto.kext, or altering its info.plist (in my case, i change the last string line to Safe Boot) gets the system frozen after a few lines of console output, as you can see in post #132. That's the current situation for now.

Possible causes to investigate:

1) As stated by zachensoul, the issue could lie on a necessary answer corecrypto must give to the system, and it's not doing so, so while keep it returns us a kernel panic, remove it won't work - and in fact does not work - since the system needs that answer to be correct to running properly. The possible solution for it would be it has to be fooled into returning the answer the system is looking for. However, the obstacle is how to trick it: zchef2k tried some changes, to no avail, as stated in post #142;

2) Maybe this is an issue caused by the lack of some CPU instructions Intel processors from core 2 on have, like the much discussed suplemental SSE3. Well, i think now it's time to go deep in that ssse3 emulator thing, be this the case or not.

One more thing: we now have a chat room for AMD and other unsupported CPUs kernel discussion in IRC, in the server osx86.hu: #LegacyKernel. Join us!

For now, this is it.

#172
theconnactic

theconnactic

    Stubborn AMD user

  • Local Moderators
  • 2,944 posts
  • Gender:Male
Hi, nice folks!

i've been reading pictures of our corecrypto-related kernel panics. I really really wanted to understand the panic debugging info, so i googled for advice and found this:

http://developer.app...063/_index.html

There i learned that the message at the end of the line one, "type 6 = invalid opcode", means a textual description of the error, the number "6" meaning the exception vector in decimal. As the guide recommended me to do, i look for it at the volume 3A of the intel CPU guide (Intel 64 and IA-32 Architectures Software Developer’s Manual, Volume 3A: System Programming Guide, Part 1) and found this:


Interrupt 6—Invalid Opcode Exception (#UD)


Exception Class Fault.
Description
Indicates that the processor did one of the following things:
  • Attempted to execute an invalid or reserved opcode.
  • Attempted to execute an instruction with an operand type that is invalid for its accompanying opcode; for example, the source operand for a LES instruction is not a memory location.
  • Attempted to execute an MMX or SSE/SSE2/SSE3 instruction on an Intel 64 or IA-32 processor that does not support the MMX technology or SSE/SSE2/SSE3/SSSE3 extensions, respectively. CPUID feature flags MMX (bit 23), SSE (bit 25), SSE2 (bit 26), SSE3 (ECX, bit 0), SSSE3 (ECX, bit 9) indicate support for these extensions.
  • Attempted to execute an MMX instruction or SSE/SSE2/SSE3/SSSE3 SIMD instruction (with the exception of the MOVNTI, PAUSE, PREFETCHh, SFENCE, LFENCE, MFENCE, CLFLUSH, MONITOR, and MWAIT instructions) when the EM flag in control register CR0 is set (1).
  • Attempted to execute an SSE/SE2/SSE3/SSSE3 instruction when the OSFXSR bit in control register CR4 is clear (0). Note this does not include the following SSE/SSE2/SSE3 instructions: MASKMOVQ, MOVNTQ, MOVNTI, PREFETCHh, SFENCE, LFENCE, MFENCE, and CLFLUSH; or the 64-bit versions of the PAVGB, PAVGW, PEXTRW, PINSRW, PMAXSW, PMAXUB, PMINSW, PMINUB, PMOVMSKB, PMULHUW, PSADBW, PSHUFW, PADDQ, PSUBQ, PALIGNR, PABSB, PABSD, PABSW, PHADDD, PHADDSW, PHADDW, PHSUBD, PHSUBSW, PHSUBW, PMADDUBSM, PMULHRSW, PSHUFB, PSIGNB, PSIGND, and PSIGNW.
  • Attempted to execute an SSE/SSE2/SSE3/SSSE3 instruction on an Intel 64 or IA-32 processor that caused a SIMD floating-point exception when the OSXMMEXCPT bit in control register CR4 is clear (0).
  • Executed a UD2 instruction. Note that even though it is the execution of the UD2 instruction that causes the invalid opcode exception, the saved instruction pointer will still points at the UD2 instruction.
  • Detected a LOCK prefix that precedes an instruction that may not be locked or one that may be locked but the destination operand is not a memory location.
  • Attempted to execute an LLDT, SLDT, LTR, STR, LSL, LAR, VERR, VERW, or ARPL instruction while in real- address or virtual-8086 mode.
  • Attempted to execute the RSM instruction when not in SMM mode.


Obviously, this by itself doesn't tell everything. Remember, could it be any of the cases above. But since our AMDs doesn't support SSSE3 instructions, this makes a strong case (no pun intended) for the ones i underlined above. Meklort told me to disassemble the kext and look for the invalid opcode, if it was the issue (now we know it was). He hinted to the terminal command otool -tVv, which i used to get an assembly listing for debugging info. Perhaps the panic tells us exactly for what to look for in the listing, so i'll keep on trying to decipher it.

P.S.: I'm using instant idiot's picture from post #143. Unfortunately i lost all the pics of my kp.

P.P.S.: Here's the output of the otool, just in case someone want to take a look (would help a lot) and don't want wasting time obtaining it himself: Attached File  corecrypto debugging.txt   129.91KB   9 downloads

P.P.P.S.: The BSD process corresponding to the thread of the panic was not a kernel task. It's unknown. That should mean that it does not originate from within the kernel (which is good) but somewhere else. That seems to confirm that naughty corecrypto.kext is guilty.

#173
bcobco

bcobco

    InsanelyMac Geek

  • Members
  • PipPipPip
  • 142 posts
  • Gender:Male
  • Location:Argentina
theconnactic please read carefully that "SSE3 Emulator.pdf" paper.
it explains what to do with processor interrupt number 6 (invalid op code).
i only readed once, but i remember that voodoo team played with that interrupt.
when int6 happens, they look to see if instruction is on unsupported, and act according that.
that people did a really good job. that paper offers a first solution and a second improved solution.
i think that the problem has more and better solutions, but it needs deep kernel and hardware knowledge.
the source code has dissapeared, but the algorithm is there. it just needs to be implemented.

#174
MacFaulty

MacFaulty

    InsanelyNut

  • Members
  • PipPipPip
  • 158 posts
  • Gender:Male
  • Location:Tulip & Cheese country
  • Interests:IT Management and creating web apps
Ooh, I really wish I could be of any help. You guys are AWESOME. I mean it! Coming this far already :) Keep it up. Will be busy lately so I guess no time for beta test coming 4 weeks or so, but I'll stick to this topic and will follow it :D

You guys rock!

Greetings from Holland :)

#175
ZackehSoul

ZackehSoul

    InsanelyMac Protégé

  • Members
  • PipPip
  • 65 posts
  • Gender:Male
  • Location:Leeds, UK
Yay, emulation!

#176
instant idiot

instant idiot

    InsanelyMac Geek

  • Members
  • PipPipPipPip
  • 182 posts
  • Gender:Male
For what it's worth, here's what happens with theconnactic's kernel on an Intel Core i3-2350m which, of course, runs the unmodified mach_kernel perfectly.

EDIT: Glad I could help!

Attached Files



#177
theconnactic

theconnactic

    Stubborn AMD user

  • Local Moderators
  • 2,944 posts
  • Gender:Male
Instant idiot, thank you very much for this post! Earlier today, i asked for pictures of a vanilla verbose boot to see how it behaves and what lines appear, and what's the role of corecrypto. You gave me the latter. Thanks again, very valuable info. :)

#178
instant idiot

instant idiot

    InsanelyMac Geek

  • Members
  • PipPipPipPip
  • 182 posts
  • Gender:Male
Here's Mountain Lion booting on my 4530s (I think that's what you wanted.): https://youtu.be/yBsX2H2nmN4

#179
zchef2k

zchef2k

    InsanelyMac Protégé

  • Members
  • PipPip
  • 79 posts
The diff in the link below contains some sort of sse3 emulation that was done for 1504.9.26. Apply it to the 1504.9.26 sources and take a look around- especially the sse3emu c and header files in osfmk/i386/commpage.

Turbo and mercurysquad are credited in the diff's pseudocode. Is this what we're looking for?

Here

-Z

#180
instant idiot

instant idiot

    InsanelyMac Geek

  • Members
  • PipPipPipPip
  • 182 posts
  • Gender:Male
It looks like R:A:W:X86's kernel has the (elusive?) SSE3 emulator built in! If that's the case, then wouldn't it be easy enough to get the emulator's source from R:A:W:X86's sources? (Not to mention that zchef2k apparently just found the sources for it.)

This is with a 32-bit only SSE3 and SSSE3-less Intel Pentium M 1.8 GHz. It only stops at waiting for root device (USB issues, I guess.), so my guess is that it'll actually boot.

Attached Files







Also tagged with one or more of these keywords: Mountain Lion, AMD, legacy kernel, x64_86, ssse3, ssse3 emulator


8 user(s) are reading this topic

0 members, 8 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