overdue-scratch

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

0 Members and 1 Guest are viewing this topic.

Azimutz

  • VoodooLabs
  • Posts: 420
  • Paranoid Android
@Mek,
i know these patches are 32 bit only. What i meant is, 10.6 kernel always kp's when i build it 32/64 bit;
i overseen/forgot that fact and it lead me to think the patch wasn't working.
Edit: in fact, the kp has nothing to do with architecture. The same minimal patch i use on 10.6.2/3 doesn't
work on 10.6.. can't really understand why.

Anyway, i cleaned my previuos the post to avoid more confusion.
Patch works, either by removing panic call or impersonating family/model, that's all!
Never mind the rest... let it roll ;)

p.s.: info on my cpu is on my signature->System->CPU
« Last Edit: May 25, 2010, 08:53:33 PM by Azimutz »
 System & Patches: http://goo.gl/i961
 Chameleon:
- trunk builds: http://goo.gl/9G1Hq
- pref pane: http://goo.gl/OL2UT

yehia2amer

  • Observer
  • Posts: 15
my hp laptop need a patched kernel to work with all 4 cores although the cpu is fully supported
so can this help to edit the Bootloader and use the vanilla kernel

the problematic kernel file is "lapic.c" in the path "xnu-1504.3.12/osmfk/i386/lapic.c"
 
the code Must be changed to this (the Bold part) :
----------------------------------------------------------
/* ExtINT */
if (get_cpu_number() == master_cpu) {
value = LAPIC_READ(LVT_LINT0);
value &= ~LAPIC_LVT_MASKED;
value |= LAPIC_LVT_DM_EXTINT;
LAPIC_WRITE(LVT_LINT0, value);
}

/* NMI: ummasked, off course */
LAPIC_WRITE(LVT_LINT1, LAPIC_LVT_DM_NMI);

/* Timer: unmasked, one-shot */
LAPIC_WRITE(LVT_TIMER, LAPIC_VECTOR(TIMER));
-----------------------------------------------------------------

any help will be appreciated , hope i can run vanilla  :)

meklort

  • VoodooLabs
  • Posts: 65
I'll take a look and see how easy it'll be to implement.

EDIT: Looks like I should be able to free up enough space in that function to add the required code, but I may have to remove the lapic_dont_panic kernel option to do so, in either case I can always for lapic_dont_panic to be true as well (well, I can remove the one panic that it affects).
« Last Edit: June 12, 2010, 11:27:31 PM by meklort »
return c ? c : !c;

yehia2amer

  • Observer
  • Posts: 15
great news, i am ready to test anytime  ;D

Azimutz

  • VoodooLabs
  • Posts: 420
  • Paranoid Android
Hi Meklort, back to haunt you ;D

Usb stuff fixed, thanks. On my machine the EHCI device is also only one and the last.
USBLegacyOff patch is applied last and makes my boot hang as before; just mentioning, i know it's a specific patch and i don't need it. Atm, i'm only using UHCIreset; something got fixed, maybe on latest system updates so i don't need EHCIacquire for now.

Checking "md0Ramdisk" stuff for the first time...
Ok, i understand the use of a postboot image, though i don't fully know how to use it.
Anyway, my first doubt is about the code; do you really need to look for Postboot.img on rd(0,0)?
I'm finding that strange but, that's a path to a ramdisk... if so, you should do it like this to avoid
"Failed to read boot sector from BIOS device 100h. error=1" message. Check this topic for my adventures on the subject.

That's it, for now...
« Last Edit: July 26, 2010, 02:28:01 PM by Azimutz »
 System & Patches: http://goo.gl/i961
 Chameleon:
- trunk builds: http://goo.gl/9G1Hq
- pref pane: http://goo.gl/OL2UT

meklort

  • VoodooLabs
  • Posts: 65
I've added the check for the rd.

Yes, I absolutely *must* check for the ramdisk in rd(0,0). The md0 ramdisk is a device that the xnu kernel sets up at /dev/md0 when it detects the correct properties in the registery, it's a very different thing than chameleons ramdisk feature. It's not possible to load the md0 ramdisk from a boot cd due to having to swap it with the install DVD. Because of that, I need a way to access the Postboot.img file, hence adding it to the Preboot.dmg and reading that in before the cd is swapped.

On my machine the usb legacy off code doesn't hang anymore, I'll take a look at it again and see what's going on.

 
return c ? c : !c;

Azimutz

  • VoodooLabs
  • Posts: 420
  • Paranoid Android
Just saw the update...
Right, in that case i understand the need for loading a Postboot from a Preboot. My doubt is mainly because i'm not sure how long the contents of a ramdisk (Preboot) stay available?! I've always assumed they stay available until reboot, but some stuff got me doubts... is that true? I mean, do the files loaded from a Preboot stay available on RAM until next reboot or...?

About usb legacy hang, reading through the topic now, i recalled i got it when i tested the patch before; i only mentioned it now out of curiosity. Will check it better...
« Last Edit: July 26, 2010, 07:34:52 PM by Azimutz »
 System & Patches: http://goo.gl/i961
 Chameleon:
- trunk builds: http://goo.gl/9G1Hq
- pref pane: http://goo.gl/OL2UT

meklort

  • VoodooLabs
  • Posts: 65
Got it.

The Preboot ramdisk is only guaranteed to be available so long as chameleon is running. Once XNU starts it can and will reclaim the memory (well, it doesn't even know it was used).

The Postboot (md0) ramdisk is allocated in memory reserved for the kernel, and then the kernel is notified by a memory map not to reuse it.

I fixed the issue with the usb legacy patch before. I had it run on the uhci and ehci device, not just the ehci device which caused issues. It's been fixed (for me) since before I imported it to trunk.
« Last Edit: July 27, 2010, 01:38:15 AM by meklort »
return c ? c : !c;

Azimutz

  • VoodooLabs
  • Posts: 420
  • Paranoid Android
Aah, ok... thanks for clearing out that stuff. Thinking better i was kind of noob :P should have got to the conclusion my self, but reading it explained this way helps a lot!

The usb fixes... found what was creating the hang for me; i was using a sleep(5) right after the usb_loop call and it seems that mixing it with EHCIacquire+USBLegacyOff it's not a good idea! I was doing this to have time to see the messages on the screen; no hangs without the sleep().
To be able to check this properly i moved the usb_loop call before Wait key, which turned out to be a better idea.
The only usb fix that makes my boot hang is still UHCIreset. I was under the impression that USBLegacyOff also did the same but it's not true!
So, all seems fine. Sorry for the false alarm :)
Will be back later with some kernel patcher related stuff...
 System & Patches: http://goo.gl/i961
 Chameleon:
- trunk builds: http://goo.gl/9G1Hq
- pref pane: http://goo.gl/OL2UT

Azimutz

  • VoodooLabs
  • Posts: 420
  • Paranoid Android
Hi Meklort,

just to mention that, on rev 494 the kernel patcher module fails to build:
Code: [Select]
kernel_patcher.c: In function ‘patch_cpuid_set_info’:
kernel_patcher.c:391: error: expected expression before ‘<’ token
kernel_patcher.c:391: error: expected statement before ‘)’ token
kernel_patcher.c:395: error: expected expression before ‘else’
can't get rid of the last one.

Also, i just tried to build from a folder Exported by the svn client (without .svn dirs) and i get this:
Code: [Select]
svn: Path '../..' ends in '..', which is unsupported for this operation
ld: malformed version number: -final_output
here fails building symbols module.

I'll be back later with more talk.. "family busy" atm :)
« Last Edit: September 05, 2010, 11:36:28 PM by Azimutz »
 System & Patches: http://goo.gl/i961
 Chameleon:
- trunk builds: http://goo.gl/9G1Hq
- pref pane: http://goo.gl/OL2UT

meklort

  • VoodooLabs
  • Posts: 65
Both should be fixed now.
return c ? c : !c;

Azimutz

  • VoodooLabs
  • Posts: 420
  • Paranoid Android
Yep, confirmed :) Thanks.
Will test 64 bit kernel patching asap... see ya later.
« Last Edit: September 05, 2010, 11:37:12 PM by Azimutz »
 System & Patches: http://goo.gl/i961
 Chameleon:
- trunk builds: http://goo.gl/9G1Hq
- pref pane: http://goo.gl/OL2UT

meklort

  • VoodooLabs
  • Posts: 65
In your branch I noticed you added this too boot.c:

getBoolForKey(kKPatcherKey, &patchKernel, &bootInfo->bootConfig);   
if (patchKernel == true)

If you want that, please remove it from there and add it to the module itself. Where you have it right now it really means "disable the exec kernel hook," which any module can hook into. The way you have it now, this could break them. If you add the check to the module itself, it'll let you disable just that module.
return c ? c : !c;

Azimutz

  • VoodooLabs
  • Posts: 420
  • Paranoid Android
Ok, thanks for the tip :) i had this on my list of questions. I'm not really sure of the usefulness of the key,
but if it's there it should work properly. For now it's easier than add/remove module, to boot Leo for instance, were i use
Voodoo kernel (patcher doesn't like it at all). Will work on it... will ask you if i get in trouble, but i understand what you mean.

About the kernel patcher; panic removal works fine on x86_64! I still have to patch the kernel, or i get commpage panic:
Quote
commpage no match for last, next address ffff1000
the rest of the panic is on the ugly pic attached. Kernel patcher reports this on normal verbose:
Quote
64 bit - patched kernel

0xE8 0x7B 0xC0 0xFD 0xFF
0x90 0x90 0x90 0x90 0x90
Unable to locate _commpage_stuff_routine
I checked the kernel for this symbol and it's really not present; the closest i can find is
Quote
_commpage_32_routines
_commpage_64_routines
Anyway, the obvious first question here is, what's the commpage panic the patcher is supposed to fix?
From my experience, i know this commpage panic on Pentium D, is due to the fact that although these processors have
em64t instructions, they lack Suplemental sse3 ones. The patch i use it's basically the one on the last commits on the
Voodoo kernel here (the bcopy_sse3x_64.s stuff). I assume this is not the target of the patcher as it is!?
The second question is, is it possible to apply a patch of this nature with kernel patcher?
If needed i can post a diff of the patch. I have to confess that i never tried to bypass this panic in any other way.

Just to remind, i'm on a Pentium D 925, family 15 model 6. This is detected at boot,
Quote
WARNING: ACPI_SMC_PlatformPlugin - getCPUIDInfo unknown CPU family: family 0xf, model 0x6
-- power management may be incomplete or unsupported
and by most apps after boot; only System Profiler shows C2D because of the booter.

That's it for now... be back later.


EDIT: check rev 498, about the kernel patcher key; is that fine?
« Last Edit: September 06, 2010, 09:52:29 AM by Azimutz »
 System & Patches: http://goo.gl/i961
 Chameleon:
- trunk builds: http://goo.gl/9G1Hq
- pref pane: http://goo.gl/OL2UT

meklort

  • VoodooLabs
  • Posts: 65
The _compage_stuff_routine patch is for a machine that I was running and had an issues, you can ignore it, I'll probably fix it to run on more kernels, but it's not a major issue for me.

you can also ignore the hex output, I had it there just for debugging.

The "commpage no match for last, next address ffff1000" panic shouldb't be there, probably has something to do with one of the patches working improperly, I ran into that once and then fixed it, but I haven't uploaded it.

As far as the ACPI_SMC_PlatformPlugin panic, the CPUID patch just removes the panic for now, I have it partially working in 64bit but it's not done yet.

Yes, other patches can be applied, some require more work than others, although I'll be writing some additional functions that'll let you do things a bit easier.
return c ? c : !c;