InfiniteMac OSx86 - Voodoo Kernel - Release candidate is out now

InfiniteMac OSx86 (http://infinitemac.com/forum.php)

- 10.X (http://infinitemac.com/forumdisplay.php?f=36)

- - Voodoo Kernel - Release candidate is out now (http://infinitemac.com/showthread.php?t=1640)

An direct update to 10.5.5 via Apple Software Update crashed at about 12% on a test system, I tried two attempts. Update my main system wouldn't be useful because it was messed up even with kernel 9.3.0, random kernel panics and hangs and so on. Are there special files (kexts etc.) which should be replaced if a user can't update?

Yesterday I had two crazy crashes while filling my memory to test the 64bit-adapted NForce driver: Logic and MainStage crashed shortly after, but the crash report shows only ??? in the list.

Do you want to fix the 'About this Mac' thing? I don't know, if parts of the system don't recognize the processor correctly some things may not work like they should.

It seems that my applications did not become obsolete ...

I'm happy ! :)

Quote:

Originally Posted by mercurysquad (Post 18587)

Random application crashes have been reported. This is an issue with our custom-dyld built for opcode patcher support, so make sure you are using latest 10.5.5.

Will I be able to install from a retail 10.5.1 dvd and upgrade _after_ the install, or do I need an updated retail dvd?

Quote:

Originally Posted by PingunZ (Post 18596)

Will I be able to install from a retail 10.5.1 dvd and upgrade _after_ the install, or do I need an updated retail dvd?

Updating is basically the same as always. ;)

All this kernel does is erase the distinction between AMD and Intel users, meaning you can follow a guide previously written only for Intel machines an in *theory* everything should go just as well.

You still have to take precautions so your machine doesn't crash, if for example IntelCPUManagement gets loaded, you still need to make sure that you re-install the kernel if it's overwritten by an update, etc, etc.

What Dies said. In fact I can confirm that the crash at 12% was because of AppleIntelCPUPowerManagement.kext -- I hosed my system recently because of just that (and I have an Intel Pentium M..). So in short for updating, follow Intel guides, don't just blindly run software update for critical updates. The kernel erases distinction between AMD and Intel -- NOT between vanilla and patched setups.

Also @naquaada. re: processor identification. AMD is identified as Core Solo or Core Duo on purpose. For that part of the kernel, we had the option to report the processor either as one of Apple-supported CPUs, or report it as Unknown. There is no way to identify the cpu as anything else. Unknown doesn't work for some apps (installers specially) so we went with Intel Core..

Quote:

Originally Posted by zephyroth (Post 18594)

It seems that my applications did not become obsolete ...

I'm happy ! :)

Zephyroth your excellent utility is not yet obsolete but I'd recommend re-channelizing your expertise to other areas than cpuid patching, as 100% parity between intel & amd is a goal of Voodoo. Which means all opcode patching related bugs will be fixed with high priority.

People are incorrectly assuming that the kernel allows them to update straight from software update - this is only true as much as for non-vanilla Intel users. From what I gather, your utility still does a whole lot of things apart from patching CPUIDs, so the utility is still relevant. Feel free to get in touch with us if you need more detailed info about the kernel and its workings.

Everyone else please note that you can run prepatched binaries no problem, but it doesn't mean the kernel will not disassemble each binary as it is loaded (since we have no way to tell whether the binary is already patched or not unless we load it). This means you won't gain any performance by prepatching your whole HDD. Since on-the-fly is really very fast, the amount of time you'll spend reading the HDD, patching binaries and rewriting it back to disk will probably be longer than what the opcode patcher will take in total during average usage. If you still insist on prepatching manually and don't want to use the patcher at all, boot with patcher_opts=0.

Quote:

Originally Posted by mercurysquad (Post 18601)

AMD is identified as Core Solo or Core Duo on purpose. For that part of the kernel, we had the option to report the processor either as one of Apple-supported CPUs, or report it as Unknown. There is no way to identify the cpu as anything else. Unknown doesn't work for some apps (installers specially) so we went with Intel Core..

I'm not sure about this. In System Profiler the processor is detected correctly as AMD Opteron, in 'About this Mac' (I'll shorten it with 'ATM' now) is it Intel Core Duo. If a program/installer needs system information, from which source it will take them? From there where System Profiler gets it or from there where ATM gets it? What about the tools from zephyroth and PCwiz which could write custom text in the processor and memory fields in ATM? I never had a tool which doesn't working because of an unknown processor, and only the Parallels installer checked for an Intel CPU. But this was easily to remove. I think the most people would like a correct cpu name in ATM. An kernel option for this would be better, so that the cpu is detected either as 'unknown', 'Intel' or the correct type. BTW, what is the option to specify the maximal usable memory?

For users which have problems with a kernel panic directly at the start, try booting with -f to fix all kernel extensions, this works for me. I added it in apple.com.boot.plist, my system actually crashes nearly all ten minutes, no matter which kernel. It's rather frustrating.

I will still work on cpuid patching, for my own knowledge and for some people who experience trouble with this kernel or who can't install EFI (which I think is necessary to use the voodoo kernel).

At the moment I'm learning Objective-C which, I think, is a good idea if I want to create applications for Mac OS. :)

Quote:

Feel free to get in touch with us if you need more detailed info about the kernel and its workings.

Sure but not now. I prefer to learn alone as much as possible before !

And thanks for the work you and your team have done, I wanted a kernel like this one when I created my first release of Mac OS X !

Quote:

Originally Posted by naquaada (Post 18603)

I'm not sure about this.

OK. Explanations follow.

Quote:

In System Profiler the processor is detected correctly as AMD Opteron, in 'About this Mac' (I'll shorten it with 'ATM' now) is it Intel Core Duo. If a program/installer needs system information, from which source it will take them?

You see it from the user-visible program perspective. In the kernel there are sysctl keys for cputype, cpu family, cpu model, cpu vendor string, cpu brand string. Then there is the cpuid instruction itself. And a couple other methods.

Quote:

From there where System Profiler gets it or from there where ATM gets it?

System Profiler is a mess itself, it does some cpuid itself, takes some values from sysctl, and so on. While fixing some bugs I found that the "cpu type" sysctl key is used by installers to check whether they are running on intel or PPC.

Quote:

What about the tools from zephyroth and PCwiz which could write custom text in the processor and memory fields in ATM?

That is just cosmetic. There is a text file which can be freely modified and has nothing to do with the kernel.

Quote:

I never had a tool which doesn't working because of an unknown processor, and only the Parallels installer checked for an Intel CPU. But this was easily to remove.

Others did. Silverlight installer is one. You also say Parallels. These will only work on "Intel" cpu, not powerpc. They do not KNOW about an AMD possibility.

Quote:

I think the most people would like a correct cpu name in ATM.

Sure. Use one of the tools to modify what you want to be displayed. The text string is trivial.

Quote:

An kernel option for this would be better, so that the cpu is detected either as 'unknown', 'Intel' or the correct type.

Not at all. Kernel option so that people read "AMD Opteron" in about this mac? Why is about this mac important at all when you are fully aware that 50% of your CPU's functionality is running emulated as intel?

And second, we do NOT have the option to identify the CPU correctly. It's either Unknown, OR an Intel CPU. The kernel, the programs, installers and kexts do NOT know about anything else. I will paste that part of the code so it will be clearer:

The part which sets the cpu type:

Code:

        /* hw.cpufamily */

        switch (cpuid_info()->cpuid_family) {

                case 6:

                        switch (cpuid_info()->cpuid_model) {

                                case 13:

                                        cpufamily = CPUFAMILY_INTEL_6_13;

                                        break;

                                case 14:

                                        cpufamily = CPUFAMILY_INTEL_6_14; /* Core Solo/Duo */

                                        break;

                                case 15:

                                        cpufamily = CPUFAMILY_INTEL_6_15; /* Core 2 */

                                        break;

                                case 23:

                                        cpufamily = CPUFAMILY_INTEL_6_23;

                                        break;

                                case 26:

                                        cpufamily = CPUFAMILY_INTEL_6_26;

                                        break;

                                default:

                                        /* For other models, report Intel Core */

                                        cpufamily = CPUFAMILY_INTEL_6_14;

                        }

                        break;

                        /* mercurysquad: Report cpu family as one of the Apple-recognized

                         * CPUs, for CPU families other than 6. This entire system is very

                         * myopic, where the kernel explicitly encourages checking for a handful

                         * of families with arbitrary signatures. We cannot define our own

                         * signatures here as we never know when an installer or other app

                         * might check among only the ones stock kernel supports.*/

                case 15:

                        /* This applies to Pentium 4/D and AMD Phenom. In the future

                         * we might want to choose a more specific cpufamily based on the

                         * number of cores etc., but for now it's just not worth it IMO */

                        switch (cpuid_info()->cpuid_model) {

                                case 0:

                                case 1:

                                case 2:

                                        /* Report Core Solo/Duo for these models */

                                        cpufamily = CPUFAMILY_INTEL_6_14;

                                default:

                                        /* For higher models, report Core 2 Duo */

                                        cpufamily = CPUFAMILY_INTEL_6_15;

                        }

                default:

                        /* For unknown CPU families, just report Intel Core */

                        cpufamily = CPUFAMILY_INTEL_6_14;

        }

And the part where these cpu types are defined (these are the only choices we have). Even if we add some values here, it means nothing because we cannot change all the hundreds of programs or kexts which use the apple stock values:

Code:

/*

 *        CPU families (sysctl hw.cpufamily)

 *

 * These are meant to identify the CPU's marketing name - an

 * application can map these to (possibly) localized strings.

 * NB: the encodings of the CPU families are intentionally arbitrary.

 * There is no ordering, and you should never try to deduce whether

 * or not some feature is available based on the family.

 * Use feature flags (eg, hw.optional.altivec) to test for optional

 * functionality.

 */

#define CPUFAMILY_UNKNOWN    0

#define CPUFAMILY_POWERPC_G3 0xcee41549

#define CPUFAMILY_POWERPC_G4 0x77c184ae

#define CPUFAMILY_POWERPC_G5 0xed76d8aa

#define CPUFAMILY_INTEL_6_13 0xaa33392b

#define CPUFAMILY_INTEL_6_14 0x73d67300  /* "Intel Core Solo" and "Intel Core Duo" (32-bit Pentium-M with SSE3) */

#define CPUFAMILY_INTEL_6_15 0x426f69ef  /* "Intel Core 2 Duo" */

#define CPUFAMILY_INTEL_6_23 0x78ea4fbc  /* Penryn */

#define CPUFAMILY_INTEL_6_26 0x6b5a4cd2  /* Nehalem */

#define CPUFAMILY_ARM_9      0xe73283ae

#define CPUFAMILY_ARM_11     0x8ff620d8

#define CPUFAMILY_ARM_XSCALE 0x53b005f5



#define CPUFAMILY_INTEL_YONAH        CPUFAMILY_INTEL_6_14

#define CPUFAMILY_INTEL_MEROM        CPUFAMILY_INTEL_6_15

#define CPUFAMILY_INTEL_PENRYN        CPUFAMILY_INTEL_6_23

#define CPUFAMILY_INTEL_NEHALEM        CPUFAMILY_INTEL_6_26



#define CPUFAMILY_INTEL_CORE        CPUFAMILY_INTEL_6_14

#define CPUFAMILY_INTEL_CORE2        CPUFAMILY_INTEL_6_15

Why do people care about what it says for CPU?
This is a mean-less thing as it is just something that tells you what CPU you have and doesn't effect how the system runs
If people would just look at the big picture and see what mercurysquad and company have made and accomplished and be happy that they can run a system without patching and do the things that Intel user that run vanilla can do is quit a feat

Great Job on the kernel

On the AppleIntelPowermanagment.kext just get the null kext that way you don't have to worry about it when you update