2463 replies to this topic

[theconnactic]

My kernel panic (sorry for the bad bad photo):

 Photo on 10-5-12 at 3.49 AM #2.jpg   165.01K   48 downloads

As you cannot see (again, sorry), my panic had com.apple.kec.corecrypto (1.0) in backtrace. I googled  immediately, still no useful info.

[bcobco]

in my system, it blanks screen but immediately turns back to boot loader. i cannot see messages.

maybe the best way to test is in a working osx-10.8 system

[PookyMacMan]

Lordadmiraldrake, first off you are using Mountain Lion? Not Lion?

Second, you could always see if you can find an Apple kext in S/L/E with a similar name and then remove it...

theconnactic, good find! And that emulator you mentioned earlier...the Leopard kernels indeed had an SSE3 emulator, and a good one too. But you either forgot the extra S in your post or didn't remember that we want an SSSE3 emu.

[spakk]

theconnactic, on 05 October 2012 - 06:19 AM, said:

UPDATE! It compiled! It compiled!

Who wants to test it first?

If someone actually gets to the console (because i don't think it will really boot to the desktop or even to Launchd) please post pictures. Everybody report back. Later i'll post the diff. The problem was indeed at cpuid.c, as i thought, and i solved it in a clumsy way: "commented" the offending functions.

Unzip it, put at the root of your OSX disk and boot with the flag "con" (without the quotes): connactic.zip

Hi theconnactic , I will test them and then i will inform you.

[zchef2k]

bcobco, on 05 October 2012 - 08:24 AM, said:

in my system, it blanks screen but immediately turns back to boot loader. i cannot see messages.

maybe the best way to test is in a working osx-10.8 system

Same here. What bootloader should we be using for this testing? I'm currently using Chameleon 3255.

Good work on the compile, theconnactic.

[spakk]

zchef2k, on 05 October 2012 - 02:35 PM, said:

Same here. What bootloader should we be using for this testing? I'm currently using Chameleon 3255.

Good work on the compile, theconnactic.

I've had the best experience with 10.7.4 with cparm. I will try out various bootloader

[zchef2k]

spakk, on 05 October 2012 - 03:03 PM, said:

I've had the best experience with 10.7.4 with cparm. I will try out various bootloader

I've noticed that I get nowhere with mach_kernel as a symlink. I'm all good now having abandoned symlinking the kernel and switched bootloaders to chameleon svn r2069.

For giggles I moved corecrypto.kext out of the way and now it hangs early in the process with "SAFE BOOT DETECTED - only valid OSBundleRequired kexts will be loaded."

Judging by the name of the kext, I can guess what it does. It seems, though, there's a lot dependent on it. I don't guess appeasing it can be avoided.

[theconnactic]

Could you post a screenshot, please?

PookyMacMan, on 05 October 2012 - 01:07 PM, said:

Lordadmiraldrake, first off you are using Mountain Lion? Not Lion?

Second, you could always see if you can find an Apple kext in S/L/E with a similar name and then remove it...

theconnactic, good find! And that emulator you mentioned earlier...the Leopard kernels indeed had an SSE3 emulator, and a good one too. But you either forgot the extra S in your post or didn't remember that we want an SSSE3 emu.

No, Pooky, i didn't forget it. But if we're to write a ssse3 emulator, we'll be better using a successful emulator as a draft, than writing it entirely from scratch. The problem is that i have no sources for the best sse3 emulator, only binaries, which won't help much...

zchef2k, on 05 October 2012 - 03:56 PM, said:

I've noticed that I get nowhere with mach_kernel as a symlink. I'm all good now having abandoned symlinking the kernel and switched bootloaders to chameleon svn r2069.

For giggles I moved corecrypto.kext out of the way and now it hangs early in the process with "SAFE BOOT DETECTED - only valid OSBundleRequired kexts will be loaded."

Judging by the name of the kext, I can guess what it does. It seems, though, there's a lot dependent on it. I don't guess appeasing it can be avoided.

What if we do a rollback? Say, use the Lion or even the 64-bit Snow Leopard com.apple.kec.corecrypto? I will try it tonight.

[Lordadmiral Drake]

PookyMacMan, on 05 October 2012 - 01:07 PM, said:

Lordadmiraldrake, first off you are using Mountain Lion? Not Lion?

Second, you could always see if you can find an Apple kext in S/L/E with a similar name and then remove it...

theconnactic, good find! And that emulator you mentioned earlier...the Leopard kernels indeed had an SSE3 emulator, and a good one too. But you either forgot the extra S in your post or didn't remember that we want an SSSE3 emu.

I have an Intel Hackintosh that is currently running Lion 10.7.4 (trying to upgrade to ML atm) and an AMD Athlon powered HP Laptop that has no OS X on it right now. I want to install ML on the laptop HDD using a USB 3.0 to SATA II adapter.

[PookyMacMan]

theconnactic, on 05 October 2012 - 04:06 PM, said:

No, Pooky, i didn't forget it. But if we're to write a ssse3 emulator, we'll be better using a successful emulator as a draft, than writing it entirely from scratch. The problem is that i have no sources for the best sse3 emulator, only binaries, which won't help much...

What if we do a rollback? Say, use the Lion or even the 64-bit Snow Leopard com.apple.kec.corecrypto? I will try it tonight.

Ah OK lol, I see where you're going there. Isn't there a source for the Leo Voodoo kernels? They had an SSE3 emu...I'll see if I can find something on that.

Did Snow Leo even have corecrypto? I think only Lion might have that...unless I am completely out of date LOL.

[zchef2k]

theconnactic, on 05 October 2012 - 04:06 PM, said:

Could you post a screenshot, please?

This is with corecrypto.kext moved outside /S/L/E and -x -v (or just -v for that matter) as flags.

I'm doing this all in ESXi 5.1 on a Supermicro H8DME-2 with dual hex-core Istanbul Opterons.

[theconnactic]

PookyMacMan, on 05 October 2012 - 05:10 PM, said:

Ah OK lol, I see where you're going there. Isn't there a source for the Leo Voodoo kernels? They had an SSE3 emu...I'll see if I can find something on that.

If you can, it will help a lot indeed: meklort sent me maxxus' one, but the voodoo emulator performs far far better. Meklort sent me a diff that mentions it, and a binary file of it, which i already had (the binaries are included with the RAWx86's patched kernel, on which i based my own patches). If i can take a look at the C (or even assembly) codes of the voodoo sse3 emulator, our chances improve a lot.

PookyMacMan, on 05 October 2012 - 05:10 PM, said:

Did Snow Leo even have corecrypto? I think only Lion might have that...unless I am completely out of date LOL.

I don't know either. If not, we roll back to the Lion one, or remove it altogether, renouncing to the modern cryptography it supposedly provides.

zchef2k, on 05 October 2012 - 05:12 PM, said:

This is with corecrypto.kext moved outside /S/L/E and -x -v (or just -v for that matter) as flags.

The interesting about it is that it doesn't panic: it hangs instead. So, i guess the CPU id issues are gone for good. Maybe this also indicate that the all-64-bit kexts of Mountain Lion fails to load because of the missing ssse3 instructions. We need further testing, specially with a Bulldozer machine, to confirm this.

zchef2k, on 05 October 2012 - 05:12 PM, said:

I'm doing this all in ESXi 5.1 on a Supermicro H8DME-2 with dual hex-core Istanbul Opterons.

A little off topic here, but what a heck of a machine! It will be really cool to see it singing the Mountain Lion roaring tune. On the other side, server parts are usually harder to make them to work and usually have less support, even on the Intel side. Did you ever try OSX on it?

[zchef2k]

theconnactic, on 05 October 2012 - 07:09 PM, said:

A little off topic here, but what a heck of a machine! It will be really cool to see it singing the Mountain Lion roaring tune. On the other side, server parts are usually harder to make them to work and usually have less support, even on the Intel side. Did you ever try OSX on it?

Not on this rig. I've done an SL build on Opterons before and Lion builds on Xeons.

I like it complicated

[Lordadmiral Drake]

theconnactic, on 05 October 2012 - 07:09 PM, said:

We need further testing, specially with a Bulldozer machine, to confirm this.

What about AMD E-Series APUs, do they have SSSE3?

[SS01]

theconnactic, on 05 October 2012 - 04:06 PM, said:

No, Pooky, i didn't forget it. But if we're to write a ssse3 emulator, we'll be better using a successful emulator as a draft, than writing it entirely from scratch. The problem is that i have no sources for the best sse3 emulator, only binaries, which won't help much...

I'm guessing you know this already, but Nawcom's Snow Leopard legacy kenel does sse3 emulation, and from what I hear it does a darn good job. I'm sure he'd give you the sources if you asked..

Also, you have to remember - back in the 10.5 days, OSx86 was in full swing. With 10.4 we started getting the idea that maybe, just maybe, Apple's trusted computing DRM scheme could be cracked or worked around, and Mac OS X could be run on standard x86 hardware. By 10.5, that idea took off, and pretty much all Mac users smart enough to know what the x86 and PPC differences were started looking in to it (hence distros appeared - the general majority of people wanted a Windows-like, insert-disc-and-click install). Apple halted, or at least slowed down, this growth via various DMCA crackdowns and SMC enchancements, which is why the community is now back to the small group of hackers it was in the 10.4 days. All this goes to say, however, that OSx86's best days were (arguably) the 10.5 ones - so in other words, I'm sure searching on GitHub or Google Code would yield plenty of (potentially valuable) results.

[zchef2k]

On this corecrypto issue. If you look at the Info.plist, the first key is AppleKernelExternalComponent. (Probably not fascinating but it's been a couple of years since I went fiddling around with this stuff). Looking at OSKextLibPrivate.h in the xnu kernel source I found this. Could cpu id(entification) still be at play here?

/*!
* @define   kAppleKernelExternalComponentKey
* @abstract A boolean value indicating whether the kext is vending kernel
*		   KPI, and needs special loading behavior.
*/
#define kAppleKernelExternalComponentKey "AppleKernelExternalComponent"
// properties found in the registry root
#define kOSKernelCPUTypeKey			 "OSKernelCPUType"
#define kOSKernelCPUSubtypeKey		  "OSKernelCPUSubtype"
#define kOSStartupMkextCRC			  "OSStartupMkextCRC"			 /* value is 32-bit OSData */
#define kOSPrelinkKextCountKey		  "OSPrelinkKextCount"			/* value is 32-bit OSNumber */
#define kOSPrelinkPersonalityCountKey   "OSPrelinkPersonalityCount"	 /* value is 32-bit OSNumber */

[ZackehSoul]

CoreCrypto is the module which controls the cryptography of info & comms (in really vague terms, privacy) which is why it's necessary for ML. If there's any issues with corecrypto the machine should usually just flip off and write an error log to system.log (have you checked that?). The reason it then hangs once it's removed is because the system is programmed to shut down the system if the integrity of the module is compromised, or continue with the startup if validated. My guess would be that because it doesn't exist, the system can't figure it out either way and so just hangs because it's unable to confirm either action.

Your KP resulting in a backtrace to com.apple.kext.corecrypto is merely due to the fact that the system startup found an issue in it (which doesn't necessarily mean there's something wrong with that specifically, of course) and so flipped a KP.

If the issue is actually purely down to corecrypto, it could probably be patched by modifying FIPS_POST in the corecrypto.dylib to throw true even if it returns false. Not sure of the effect this would have on ML functionality though.

Can't really be much more specific as I have no AMD machine on me to have a look at it myself, but I figured I'd try throw a couple of ideas out there.

[SS01]

ZackehSoul, on 05 October 2012 - 09:59 PM, said:

CoreCrypto is the module which controls the cryptography of info & comms (in really vague terms, privacy) which is why it's necessary for ML. If there's any issues with corecrypto the machine should usually just flip off and write an error log to system.log (have you checked that?). The reason it then hangs once it's removed is because the system is programmed to shut down the system if the integrity of the module is compromised, or continue with the startup if validated. My guess would be that because it doesn't exist, the system can't figure it out either way and so just hangs because it's unable to confirm either action.

Your KP resulting in a backtrace to com.apple.kext.corecrypto is merely due to the fact that the system startup found an issue in it (which doesn't necessarily mean there's something wrong with that specifically, of course) and so flipped a KP.

If the issue is actually purely down to corecrypto, it could probably be patched by modifying FIPS_POST in the corecrypto.dylib to throw true even if it returns false. Not sure of the effect this would have on ML functionality though.

Can't really be much more specific as I have no AMD machine on me to have a look at it myself, but I figured I'd try throw a couple of ideas out there.

Might be simpler to just whip up a kext to do it tbh.

Or --possible noob alert-- just disable corecrypto.

[ZackehSoul]

SS01, on 05 October 2012 - 10:37 PM, said:

Or --possible noob alert-- just disable corecrypto.

Disabling corecrypto is what zchef2k did, and it hangs because the system needs to detect it. It's probably easier to have it detected and work around it rather than rewrite the stuff that interacts with it

[SS01]

ZackehSoul, on 05 October 2012 - 10:44 PM, said:

Disabling corecrypto is what zchef2k did, and it hangs because the system needs to detect it. It's probably easier to have it detected and work around it rather than rewrite the stuff that interacts with it

I see - sorry about that. I'd still use a kext just to be safe - much easier to boot with -x and delete a kext than having to recompile the kernel.

Just thought of a possible last resort if we end up in the same 32-bit only boat as Lion:
1. Patch the netkas 32-bit XNU to work with AMD.
2. Switch all ML kexts to their 32-bit Snow Leopard equivalents, or in the case of ML-only kexts rewrite them completely.
3. Install to AMD rig (either via swapping HDs with an Intel rig, or through a ModUSB-like program) and party hard.

Obviously very last resort, but just saying it's there.