ProjectOSX

Welcome Guest!

Returning User? Login here.

Want membership privileges? Register here.

 
 Start a new topic Add Reply
> Kernel Investigations
Slice
post May 17 2011, 07:43 AM
Post #1
The work is almost finished. Here is a result.

All of us like to use Vanilla kernel contemptuously looking on users with patched kernel.
Some issues may be resolved by Meklort's KernelPatcher.dylib, some by additional kexts like SleepEnabler.
Let look more closely on the kernel problems.
1. Unsupported CPU.
CODE
    /* verify we are running on a supported CPU */
    if ((strncmp(CPUID_VID_INTEL, info_p->cpuid_vendor,
             min(strlen(CPUID_STRING_UNKNOWN) + 1,
             sizeof(info_p->cpuid_vendor)))) ||
       (cpuid_set_cpufamily(info_p) == CPUFAMILY_UNKNOWN))
        panic("Unsupported CPU");

This may be corrected on the fly but it is not a full solution because cpuid calculations wrong for unsuppoted CPUs.
2. TSCFrequency. Again, the calculation is right only for supported CPU and is wrong for overclocked one.
3. Halt/Restart. Even thou you apply fixed FACP with registers 0xCF9 or 0x64 this is not full solution.
Fine restart was made many years ago by Daemon in patched Tiger's kernel.
CODE
+//Hardware reset
+void cr_wait(void)
+{
+    for(int i = 0; i < 0x10000; i++)
+        if ((inb(0x64) & 0x02) == 0) break;
+}
+
+void preapre_cold_reboot(void)
+{
+    for(int i = 0; i < 10; i++)
+    {
+        cr_wait();
+        IODelay(50);
+        outb(0x64, 0x60);
+        IODelay(50);
+        cr_wait();
+        IODelay(50);
+        outb(0x60, 0x14);
+        IODelay(50);
+        cr_wait();
+        IODelay(50);
+        outb(0x64, 0xfe);
+        IODelay(50);
+    }
+}
+
+void cold_reboot()
+{
+    for(;;)
+    {
+        preapre_cold_reboot();
+    }
+}

4. SSE3 emulation for those who need it.
http://www.projectosx.com/forum/index.php?showtopic=1428
5. VMWare support. Dunno if it is an issue.
6. Lapic patch? Not for all.
http://www.projectosx.com/forum/index.php?showtopic=1210
7. I found something new. File hw_defs.h
CODE
#define pmBase         0x400

This is true for any real Mac but for Hackintosh I see in FADT
CODE
[038h 0056  4]     PM1A Event Block Address : 00001000

I don't know how it is used by kernel or by system.
8. Memory leak problem. Yes, there are no perfect programs and mach_kernel still contains mistakes. I think it is one of them.
http://www.projectosx.com/forum/index.php?...ost&p=14698
When I get Lion sources I can find what is this.
9. HPET patch. I think it is obsolete.
10. Kext's blacklist. Strauss method to avoid problems instead of resolve it.

What else?

How to make your own kernel

PS. Looking into hex dump of Lion kernel I see places with many nop instructions. It is not possible to make this with compilers. It means Apple applies binary patch for his kernel wink.gif
Пожалуйста, прочитайте ЧаВо!
i3-2120 GA-H61M-S1, Radeon HD6670, ALC887(VoodooHDA 2.8), OS⌘10.8.3 (12D78),OS⌘ 10.7.5 Clover FakeSMC_plugins RealtekR1000v3
joe75
post May 17 2011, 11:28 AM
Post #2
"Vanilla" kernels being better has always been a misconception imho, i cant understand why so many people would think Apple would provide a better kernel then one that is customized and tailored to specific features or hardware requirements rolleyes.gif
:P5Q-EM :E8400 :Radeon HD5750

:DG45FC :E6550 :GeForce 9500GT
Kabyl
post May 17 2011, 01:03 PM
Post #3
The same goes for booters, KEXTs.. etc
гык-sse2
post May 17 2011, 02:34 PM
Post #4
QUOTE (Kabyl @ May 17 2011, 05:03 PM) *
The same goes for booters, KEXTs.. etc

So, let's revert to binary decrypts and patched AMD CPUIDs instead of DSMOS and on-the-fly mach-o patching - it would be faster if we were running on a Pentium Pro...
UEFI is a great way to get the best of the best in the world of imagination and creativity. ©Google Scribe
Kabyl
post May 17 2011, 03:05 PM
Post #5
QUOTE (гык-sse2 @ May 17 2011, 03:34 PM) *
So, let's revert to binary decrypts and patched AMD CPUIDs instead of DSMOS and on-the-fly mach-o patching - it would be faster if we were running on a Pentium Pro...

Irrelevant, I wish you would have taken a little time to think about it.
Slice
post May 18 2011, 08:02 AM
Post #6
What about Sleep enable? As I remember there was experimental sleep_kernel by Netkas.
Now we have SleepEnabler.kext. How it works?
kernel
CODE
/*
* Called by the power management kext to register itself and to get the
* callbacks it might need into other kernel functions.  This interface
* is versioned to allow for slight mis-matches between the kext and the
* kernel.
*/
void
pmKextRegister(uint32_t version, pmDispatch_t *cpuFuncs,
           pmCallBacks_t *callbacks)
{

SleepEnabler
CODE
    printf("[SleepEnabler] Registering PowerManagement dispatch table...\n");
    pmKextRegister(PM_DISPATCH_VERSION, &dispatchTable, &callbacks);
    
    printf("[SleepEnabler] Calling pmInitComplete()...\n");
    callbacks.initComplete();

Looks right. But the kernel is designed for AppleIntelCPUPowerManagement.kext that is closed source so we don't know what CPU types it supports and what pmBase if used.

TODO?
1. Implement into kernel own pmDispatch table to be independent on extra kexts and let a kext to reassign it? CPU dependency.
2. Join SleepEnabler and VoodooPower and drop AppleCPUPM? It will be PM_DISPATCH_VERSION dependent.

PS. I have to remind that very usual for hackintoshes CPUs Conroe and Yorkfield is not supported by native OSX although they somehow works.
PPS.
Currently SleepEnabler do not install many functions, one of them
CODE
/*
* Initialize the Cstate change code.
*/
void
power_management_init(void)
{
    static boolean_t    initialized    = FALSE;

    /*
     * Initialize the lock for the KEXT initialization.
     */
    if (!initialized) {
    simple_lock_init(&pm_init_lock, 0);
    initialized = TRUE;
    }

    if (pmDispatch != NULL && pmDispatch->cstateInit != NULL)
    (*pmDispatch->cstateInit)();
}
Пожалуйста, прочитайте ЧаВо!
i3-2120 GA-H61M-S1, Radeon HD6670, ALC887(VoodooHDA 2.8), OS⌘10.8.3 (12D78),OS⌘ 10.7.5 Clover FakeSMC_plugins RealtekR1000v3
Slice
post May 18 2011, 08:57 AM
Post #7
One another crutch - VoodooTSCsync. What is this?
http://code.google.com/p/voodootscsync/issues/detail?id=1
Same speak about pmDispatch table.
Пожалуйста, прочитайте ЧаВо!
i3-2120 GA-H61M-S1, Radeon HD6670, ALC887(VoodooHDA 2.8), OS⌘10.8.3 (12D78),OS⌘ 10.7.5 Clover FakeSMC_plugins RealtekR1000v3
Slice
post May 18 2011, 05:27 PM
Post #8
As I see SleepEnabler do very simple task
CODE
kern_return_t enable_exitHaltToOff(x86_lcpu_t *lcpu)
{
    return KERN_SUCCESS;
}

So we can do it in kernel
CODE
kern_return_t
pmCPUExitHaltToOff(int cpu)
{
    kern_return_t    rc; //    = KERN_INVALID_ARGUMENT;
    rc = KERN_SUCCESS;    //as in SleepEnabler

    if (pmInitDone
    && pmDispatch != NULL
    && pmDispatch->exitHaltToOff != NULL)
    rc = pmDispatch->exitHaltToOff(cpu_to_lcpu(cpu));

   return(rc);

}

This patch is compatible with any other solution
Пожалуйста, прочитайте ЧаВо!
i3-2120 GA-H61M-S1, Radeon HD6670, ALC887(VoodooHDA 2.8), OS⌘10.8.3 (12D78),OS⌘ 10.7.5 Clover FakeSMC_plugins RealtekR1000v3
DHP
post May 20 2011, 09:37 AM
Post #9
About point 7: Forget it. Isn't used anymore.

About point 9: I can boot without HPET in my DSDT and have it disabled in the UEFI BIOS so this sounds about right. However. This may not be the case for other setups.

About AppleIntelCPUPowerManagement.kext: I got it to load and register on my Sandy Bridge i7-2600K
Look here: http://www.insanelymac.com/forum/index.php...t&p=1685587

About SleepEnabler.kext: You won't need this when AICPMVers shows up in the registry - injected after the AppleIntelCPUPowerManagement.kext is loaded.
Slice
post Jun 6 2011, 08:52 AM
Post #10
Some memory diffs between 10.6.3 and 10.6.7
10.6.3
CODE
        // runtime services will be restarted, so no save
        case kEfiRuntimeServicesCode:
        case kEfiRuntimeServicesData:
        // non dram
        case kEfiReservedMemoryType:
        case kEfiUnusableMemory:
        case kEfiMemoryMappedIO:
        case kEfiMemoryMappedIOPortSpace:
        default:
        break;

10.6.7
CODE
        // runtime services will be restarted, so no save
        case kEfiRuntimeServicesCode:
        case kEfiRuntimeServicesData:
        // contents are volatile once the platform expert starts
        case kEfiACPIReclaimMemory:
        hibernate_page_list_allocate_avoided += num;
        break;

        // non dram
        case kEfiReservedMemoryType:
        case kEfiUnusableMemory:
        case kEfiMemoryMappedIO:
        case kEfiMemoryMappedIOPortSpace:
        default:
        break;

I am waiting for 10.6.8 and 10.7.0 with sources.
Пожалуйста, прочитайте ЧаВо!
i3-2120 GA-H61M-S1, Radeon HD6670, ALC887(VoodooHDA 2.8), OS⌘10.8.3 (12D78),OS⌘ 10.7.5 Clover FakeSMC_plugins RealtekR1000v3
гык-sse2
post Jun 9 2011, 05:20 AM
Post #11
I tried to install Lion DP4 on both machines. On desktop everything went fine (even with 32-bit kernel), on U90 panic:
"Process 1 execution of /sbin/launchd failed", BSD process name: init.
Otx says that all files in /sbin are fat i386/x86_64 in DP1 and x86_64 only in DP2 and higher.
Replacing launchd didn't help.
So, if we want to use Lion on 32-bit machines, we should write EM64T emulator in the kernel and to increase speed use "Open in 32-bit mode" checkbox for all fat applications.
UEFI is a great way to get the best of the best in the world of imagination and creativity. ©Google Scribe
Slice
post Jun 9 2011, 08:43 AM
Post #12
QUOTE (гык-sse2 @ Jun 9 2011, 09:20 AM) *
I tried to install Lion DP4 on both machines. On desktop everything went fine (even with 32-bit kernel), on U90 panic:
"Process 1 execution of /sbin/launchd failed", BSD process name: init.
Otx says that all files in /sbin are fat i386/x86_64 in DP1 and x86_64 only in DP2 and higher.
Replacing launchd didn't help.
So, if we want to use Lion on 32-bit machines, we should write EM64T emulator in the kernel and to increase speed use "Open in 32-bit mode" checkbox for all fat applications.

Non-real.
Wait for official version with sources. May be we can recompile /sbin utilities to be 32bits.
Or remain with Snow forever.
Пожалуйста, прочитайте ЧаВо!
i3-2120 GA-H61M-S1, Radeon HD6670, ALC887(VoodooHDA 2.8), OS⌘10.8.3 (12D78),OS⌘ 10.7.5 Clover FakeSMC_plugins RealtekR1000v3
Slice
post Oct 12 2011, 01:36 PM
Post #13
I made my own kernel 10.8.0 that has no memory KP booting with Clover. But I have a problem:
OS started only after 5minute pause.
I made voodoo_kernel using AnV sources. There is no such problem. But this kernel switched off CpuPM. angry.gif

Can anybody point me an origin of the pause? Why it absents with voodoo_kernel?
Checked with CPUs Yonah and Penryn, so it is not related to cpuid or SSE3. My CPUs are fully supported. The same for HPET and RTC. My chipsets ICH7M and 8M are native for Mac.

This is kernel.log of the pause
CODE
Oct 12 18:37:00 MacBook kernel[0]: VID2: Not usable
Oct 12 18:39:46 MacBook kernel[0]: IOHIDSystem: postEvent LLEventQueue overflow.
Oct 12 18:40:16: --- last message repeated 323 times ---
Oct 12 18:40:12 MacBook kernel[0]: IOHIDSystem: postEvent LLEventQueue overflow.
Oct 12 18:40:49: --- last message repeated 21 times ---
Oct 12 18:40:51 MacBook kernel[0]: IOHIDSystem: postEvent LLEventQueue overflow.
Oct 12 18:41:21: --- last message repeated 8 times ---
Oct 12 18:41:23 MacBook kernel[0]: IOHIDSystem: postEvent LLEventQueue overflow.
Oct 12 18:41:53: --- last message repeated 6 times ---
Oct 12 18:41:53 MacBook kernel[0]: IOHIDSystem: postEvent LLEventQueue overflow.
Oct 12 18:42:23: --- last message repeated 4 times ---
Oct 12 18:42:23 MacBook kernel[0]: IOHIDSystem: postEvent LLEventQueue overflow.
Oct 12 18:42:53: --- last message repeated 10 times ---
Oct 12 18:42:54 MacBook kernel[0]: IOHIDSystem: postEvent LLEventQueue overflow.
Oct 12 18:43:24: --- last message repeated 7 times ---
Oct 12 18:43:24 MacBook kernel[0]: IOHIDSystem: postEvent LLEventQueue overflow.
Oct 12 18:43:54: --- last message repeated 7 times ---
Oct 12 18:43:55 MacBook kernel[0]: IOHIDSystem: postEvent LLEventQueue overflow.
Oct 12 18:44:25: --- last message repeated 5 times ---
Oct 12 18:44:28 MacBook kernel[0]: IOHIDSystem: postEvent LLEventQueue overflow.
Oct 12 18:44:58: --- last message repeated 10 times ---
Oct 12 18:45:50 MacBook kernel[0]: rtR0InitNative: warning! failed to resolve special kernel symbols

8minutes the system was dead!!! And then alive.
Пожалуйста, прочитайте ЧаВо!
i3-2120 GA-H61M-S1, Radeon HD6670, ALC887(VoodooHDA 2.8), OS⌘10.8.3 (12D78),OS⌘ 10.7.5 Clover FakeSMC_plugins RealtekR1000v3
Slice
post Oct 12 2011, 08:36 PM
Post #14
I understand! rolleyes.gif
The problem with my kernel was caused by profiler kexts that wants to interact with kernel. Vanilla kernel built with PROFILER settings but mine.
Voodoo kernel is successful because of blacklisting these kexts. I did about the same but

1. I didn't forbid AppleIntelCPUPM. I want it!
2. I didn't set legacy mode for Intel CPU. So I can launch 64bit programs with 32bit kernel. (on Core2Duo)
3. Don't forbid CHUD*.
4. No "default macmodel" in kernel....
5. ( != ) instead of ( == ). Just a mistake.
6. No lapic patch - it freezes for me.

And my inventions
1. I resolved memory KP problem appears while booting with Clover.
2. Embedded SleepEnabler. Now the kext is not needed.
3. Implement large SSE3 emulator. Dunno why. May be for Pentium4 users.
4. Support for SandyBridge. It present in vanilla kernel but not in the sources. Support for Atom (tests needed).
5. Added absent headers.

Diff file and binary 32bit. All that I did is useful for 32bit kernel. If you want 64bit then use vanilla one.
Attached File  not_panic_1080.diff.zip ( 30.92K ) Number of downloads: 16

Attached File  mach_kernel.7.zip ( 2.29MB ) Number of downloads: 16


For the compilation I used the most recent tools created from last Apple's sources.

EDITED:
32/64bit kernel.
Attached File  mach_kernel.8.zip ( 4.63MB ) Number of downloads: 43
Пожалуйста, прочитайте ЧаВо!
i3-2120 GA-H61M-S1, Radeon HD6670, ALC887(VoodooHDA 2.8), OS⌘10.8.3 (12D78),OS⌘ 10.7.5 Clover FakeSMC_plugins RealtekR1000v3
 

Add Reply Start a new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 

Powered By IP.Board © 2013  IPS, Inc.