Author Topic: Backporting the Meklort patches for auto patching mach_kernel's CPUID panic etc.  (Read 63655 times)

0 Members and 1 Guest are viewing this topic.

andyvand

  • VoodooLabs
  • Posts: 51
I think it would be a great idea to also backport Meklort's patches which fix atom support (and auto patch the cpuid panic).
This could have other advantages like auto patching the kernel for various things.
This way we could make it possible for running vanilla kernel (without patches) on much other (normally not supported) cpu's.
I've generated a full differences patch file (attached below).
Let me know if I should spend some work on this too (when I have the time).

prasys

  • Entrant
  • Posts: 7
The problem with his code (its superb) is the memory hog and we'll be having issues with AMD. So if we want , we can limit to say Intel Pentium 4/Pentium Ds for now (with SSE3)

andyvand

  • VoodooLabs
  • Posts: 51
Yeah... we could do that or change the code slightly to fetch first a bool for PatchXNUCpuid=Yes and then patching the binary.
Otherwise no patching.

zef

  • Administrator
  • Posts: 265
How about to make this feature more generic by implementing a very simple patcher 'engine'? This way the user can supply a patch image (eg. "KernelPatch=<patchfile>") which will be applied before the kernel gets executed. The patch image may contain some CRC data to make sure we patch the right kernel binary followed by an offset,length,data array.
ASUS P8Z68-V PRO/GEN3 | i5-2500k | 16GB RAM | GTX560 | Keyboard | Mouse | Devilsound DAC

andyvand

  • VoodooLabs
  • Posts: 51
That's a great idea Zef.
We must then write some method for patching.
If we also expand the patcher a little we could also patch up certain drivers this way.
May become very interesting this way (with a little more work).
I'll look into the precise working and think about designing an optimal binary patch format (+ a fast & efficient way for applying).

diamondsw

  • Observer
  • Posts: 11
Sorry to dig up an old topic, but has there been any progress on this or coordination with Meklort? I bring it up as the 10.6.3 update made this type of improvement important again. A patched kernel was ultimately released, but it would be great if all the netbook users (and perhaps AMD, P4, etc) users could also avoid these issues.

As I'm no kernel/bootloader/ACPI/BIOS dev, I'm of course in no position to say how hard any of this is.  ;D

meklort

  • VoodooLabs
  • Posts: 65
Nope, no coordination has happend (but I'd be happy to work in the voodoo svn with my own branch).

Anyway's, the only real issue with the code is it doesn't work on 64bit machines. The memory addresses are different and I currently am not reading the correct info from the symtable. I have updated the code so that it's cleaner, however it still needs some work.  The only other issue is that this currently assumes that the offending panic call is always the first panic call in the cpuid_set_info function. Apple could easily change the location / order of the panic call and the patcher would break (although it'd be easy to fix).

On a slightly less related note, I'm wondering about prasys memory hog comment (let me know what issues you see and I'll see if I can change them). The code doesn't (as far as I know) use any extra memory, it patches the kernel in place without copying it. The only extra memory used is the symbol string as well as a couple of pointers. I do agree that it shouldn't be run on AMD machines (or sse2 only machines), but that should be a fairly easy check with cpuid.


return c ? c : !c;

zef

  • Administrator
  • Posts: 265
Nope, no coordination has happend (but I'd be happy to work in the voodoo svn with my own branch).

Hi meklort,

Welcome here! Just added your account to the Chameleon project members. Feel free to maintain your own branch in the repo :)

Bye,
zef
ASUS P8Z68-V PRO/GEN3 | i5-2500k | 16GB RAM | GTX560 | Keyboard | Mouse | Devilsound DAC

meklort

  • VoodooLabs
  • Posts: 65
If anyone is wondering, I've committed the kernel patcher to my local branch. I've cleaned up the code slightly, as well as made it much easier for others to add their own patches. Anyways, I've also included a patch to take the place of SleepEnabler.kext (for those of you who need it), and this time it *won't* cause a panic when the kernel is updated, and, even more importantly, it's not dependent on the pm struct not changing.

Sorry it's taken so long to get it in my branch. I'll be adding other patches soon.
return c ? c : !c;

Blackosx

  • Forum Moderator
  • Posts: 1150
Thanks for the report meklort. It's great to hear of the svn being kept up to date.
10.10.5 / 10.11 GM1 | Asus Maximum IV Gene-Z | i7-2600 3.40GHz | 4GB | Radeon 5770 1GB

Donk

  • Entrant
  • Posts: 7
Thanks for the patcher. I have been supporting VMware virtualization of Mac OS X for sometime on InsanelyMac. I have added a patch for lapic.c to allow Snow Leopard to run on ESXi 4. Once I am happy with it I'll post the changes. It changes the check for the minimum version of the LAPIC to something more useful on certain VMware products.

meklort

  • VoodooLabs
  • Posts: 65
If you are talking about this line in the source:
      panic("Local APIC version 0x%x, 0x14 or more expected\n",
         (LAPIC_READ(VERSION)&LAPIC_VERSION_MASK));

I'd suggest just removing the panic call (replace with nops) or replacing the call with a printf instead of panic call. that is, it's be much better to remove the panic call than to change the 0x14 check to a smaller value.

I'd be happy to write a bit of code to remove it (ore replace with _printf) if you'd like.
return c ? c : !c;

Donk

  • Entrant
  • Posts: 7
That would be excellent. I have modified kernels to use printf, but the intention as with your work is to use the vanilla kernel. I have a working version and have installed 10.6 and run through to 10.6.3 on ESXi, so it is the only change plus the Chameleon 2 loader that is needed to get this running for ESXi (its virtual hardware is a little behind the other VMware products, which don't need the patch).

I have some other hacks to Chameleon for VMware only and probably not of interest to the wider audience, but will post code when happy with it.

meklort

  • VoodooLabs
  • Posts: 65
Well, I've updated the patching code, but I haven't tested the lapic_init patch yet. Let me know if it works.
return c ? c : !c;

Eps

  • Entrant
  • Posts: 7
Well, I've updated the patching code, but I haven't tested the lapic_init patch yet. Let me know if it works.

I have compiled your build 155 file and found a problem.
It's hang on booting,so I take a look what's going on by verbose option.

Code: [Select]
UHCI controller [8086:27c8] at 00:1d.0 base 301(6021)
Setting Legacy USB Off on controller [8086:27c8] at 00:1d.0
Legacy USB Off Done
EHCI controller [8086:27c8] at 00:1d.0 DMA @0
UHCI controller [8086:27c9] at 00:1d.1 base 302(6041)
Setting Legacy USB Off on controller [8086:27c9] at 00:1d.1
Legacy USB Off Done
EHCI controller [8086:27c9] at 00:1d.1 DMA @0
UHCI controller [8086:27ca] at 00:1d.2 base 303(6061)
Setting Legacy USB Off on controller [8086:27ca] at 00:1d.2
Legacy USB Off Done
EHCI controller [8086:27ca] at 00:1d.2 DMA @0
UHCI controller [8086:27cb] at 00:1d.3 base 304(6081)
Setting Legacy USB Off on controller [8086:27cb] at 00:1d.3
Legacy USB Off Done
EHCI controller [8086:27cb] at 00:1d.3 DMA @0
UHCI controller [8086:27cc] at 00:1d.7 base 0(0)
Setting Legacy USB Off on controller [8086:27cc] at 00:1d.7
Legacy USB Off Done
EHCI controller [8086:27cc] at 00:1d.7 DMA @0e8284000

I think that DMA deteced at 0e8284000 is the main reason for booting hang.
But I don't know what's happend in Legacy USB Off function.
By the way,I boot my OSX from USB.