10.6.4 legacy kernel for INTEL/AMD ready to download by qoopz/nawcom/AnV/BlackKnight/mucha - a few new features

[skn]

No, I unfortunetely don't have enough computers around to debug it.

I've decided to drop 64bit kernel untill I get some news on why it does this (then I'll fix it)

Hi AnV,

OK. If you decide to fix the bug you can count on me to test it!

Thank you for the reply!

[Azimutz]

Amazing Azimutz, you only added bcopy_sse3_64.s and modified within cpuid.c in the CPU family check the default to CPUFAMILY_INTEL_MEROM.

yeah... that's the minimum required for these cpu's (with sse3, em64t & no Ssse3), when it comes to fixes and with Chameleon as it is.

About cpu family, it's set to Merom just because.. i left it like that from previous tests.

 

Any idea why more patched kernel's won't boot into the 64bit kernel (why they just restart) ?

I think so... in fact, i should have thought of this earlier. Qoopz and i, we did worked on a followup to the "annappirtrvh" kernel before he went MIA;

here is the diff as Qoopz left it: hostosv8.diff.zip To cut it short, i remembered this comment on tsc.c "//qoopz: no get_PIT2 for x86_64" and the related instant reboot, at the time we were testing it. So now, instead of adding the comment related code to the kernel, after reading a bit i compiled a i386/x86_64 from your v5 diff, booted it with "-force64 -notscverify",

et voi lá no instant reboot.

Here is the kernel i used: mach_kernel.zip just updated the version, you left it at v4 on the diff.

That's it... hope it helps.

[ATrom]

Hi, quick question (I think this may be obvious / well-known to you all, if so sorry!):

 

With this patch/kernel can you run 64-bit osx apps on an AMD proc (specifically a phenom II) ? Actually, I have a kernel now that will run 64bit apps if you use -force64, but then it won't run 32bit apps (illegal instruction). So my more general question is: with this kernel/setup, can I boot in such a way that both 32bit and 64bit apps run ?

 

If so, then the (possibly less obvious) follow-up question: can you do this inside a vmware vm ?

 

Any info and/or RTFM pointers much appreciated.

 

Thanks very much for all the awesome work!

[skn]

So now, instead of adding the comment related code to the kernel, after reading a bit i compiled a i386/x86_64 from your v5 diff, booted it with "-force64 -notscverify",

et voi lá no instant reboot.

Excellent! I can confirm that there is no more instant reboot with your patched kernel and -notscverify flag. Unfortunately I can not use full 64-bit (yet!) due to a bug with the NVidia kext for my old 7600 GS video card.

Thank you Azimutz!

 

Actually, I have a kernel now that will run 64bit apps if you use -force64, but then it won't run 32bit apps (illegal instruction). So my more general question is: with this kernel/setup, can I boot in such a way that both 32bit and 64bit apps run ?

Try to boot with arch=i386 -force64. You should get 64-bit support although the kernel itself will run in 32-bit mode.

[ATrom]

Try to boot with arch=i386 -force64. You should get 64-bit support although the kernel itself will run in 32-bit mode.

 

Thanks very much for the suggestion, but unfortunately that doesn't seem to work for me. With or without "arch=i386", booting with -force64 means I can run 64bit apps fine, but 32bit apps produce "Illegal instruction", though System Profiler confirms the kernel is in 32bit mode. It's strange that I seem to be able to get one or the other but not both.

 

If you're pretty sure this should work, maybe my kernel is too old (it reports as 10.0.0) ? Would it make sense to try just swapping in the mach_kernel referenced here, or do you really need to run the pkg install ? Can you run the pkg install inside a vm ? Sorry for all the questions, feel free to point me to docs if there are some out there that I haven't been able to find !

[skn]

If you're pretty sure this should work, maybe my kernel is too old (it reports as 10.0.0) ? Would it make sense to try just swapping in the mach_kernel referenced here, or do you really need to run the pkg install ? Can you run the pkg install inside a vm ? Sorry for all the questions, feel free to point me to docs if there are some out there that I haven't been able to find !

Are you still using the first Snow Leopard release (10.6)? Upgrade to 10.6.4 through the combo package available from Apple and replace the kernel with the one just released by Azimutz/AnV (I think you cannot just replace the kernel and keep old kexts). Probably there is some bug in previous legacy kernels (I've never tried 10.0.0 kernel in 64-bit mode).

I have no experience on AMD platform (I don't know the exact procedure to upgrade on AMD - on Intel it's quite simple) so be careful before upgrading your system. Don't forget to backup it first!

[ATrom]

Are you still using the first Snow Leopard release (10.6)? Upgrade to 10.6.4 through the combo package available from Apple and replace the kernel with the one just released by Azimutz/AnV (I think you cannot just replace the kernel and keep old kexts). Probably there is some bug in previous legacy kernels (I've never tried 10.0.0 kernel in 64-bit mode).

I have no experience on AMD platform (I don't know the exact procedure to upgrade on AMD - on Intel it's quite simple) so be careful before upgrading your system. Don't forget to backup it first!

 

I upgraded the OS to 10.6.4 a while back, but it's booting the kernel (10.0.0) that's in the bootloader disk I'm using ("Empire EFI"). It's probably amazing that it's working so well.

 

By "the one just released by Azimutz/AnV" you mean the mach_kernel.zip that Azimutz posted earlier today ?

 

Thanks for all your help !

[skn]

I upgraded the OS to 10.6.4 a while back, but it's booting the kernel (10.0.0) that's in the bootloader disk I'm using ("Empire EFI"). It's probably amazing that it's working so well.

 

By "the one just released by Azimutz/AnV" you mean the mach_kernel.zip that Azimutz posted earlier today ?

 

Thanks for all your help !

You're welcome!

Yes, I mean the mach_kernel.zip just posted by Azimutz.

Also I don't know if you'll need to run the AMD Instruction Patcher released by AnV (refer to post #132). AMD is a complete different world for me!

[Mohamed Khairy]

@ Azimutz

 

i tested your kernel it work only on arch i386 on arch x86-64 it restarts

 

 

 

anther thing chameleon bootloader cant identify busratio and FB of pheonem ii so must use busratio=xx flag is it possible to fix

 

thanks for you and for andy also

[Maniac10]

I tested your kernel, Azimutz but I get the same reboot as always, it can't even boot to arch=i386. Back to anv v5, hope this can be sorted out.

[Azimutz]

Sorry for the delay guys, but time is not much

So, any of you guys that tested the kernel (besides skn) used the -notscverify flag as i mentioned?

The kernel is exactly the same as the one Andy posted, it just has x86_64 arch plus. Also, the -notscverify key may not work for everyone,

since it only disables tsc verification and the guilty part can still be called in another place other than the verification.

I didn't made any changes to the kernel because i don't have what it takes; maybe Andy can come up with something

 

Mohamed Khairy,

busratio=xx is a "kernel flag" and it should be working; are you using it properly?

It should be used like this on Boot.plist

<key>Kernel Flags</key>

<string>busratio=xx</string>

or typed at boot prompt.

 

p.s.: i can't help much when it comes to AMD; never had one and unless someone offers me one, i think i will never have!?

[Mohamed Khairy]

@ Azimutz

 

i know that it is kernel flag and i use it from first try on my pc when setuping 10.5.8

 

when i see bootloader log

 

it just identify cpu speed but other data 000 nothing

 

so i hope bootloader detect it fine so no need for this flag

 

thanks

[Azimutz]

Ok, i understood you were having problems with the flag on the kernel. As you can see, even the code on the kernel is not up to the task,

that's why you need the flag, otherwise the code would do it for you.

 

Now, about the kernel... did you used the -notscverify flag?

[Mohamed Khairy]

Ok, i understood you were having problems with the flag on the kernel. As you can see, even the code on the kernel is not up to the task,

that's why you need the flag, otherwise the code would do it for you.

 

Now, about the kernel... did you used the -notscverify flag?

CPU: Vendor/Model/ExtModel: 0x68747541/0x4/0x0
CPU: Family/ExtFamily:	  0xf/0x1
CPU: MaxCoef/CurrCoef:	  0x0/0x0
CPU: MaxDiv/CurrDiv:		0x0/0x0
CPU: TSCFreq:			   3210MHz
CPU: FSBFreq:			   0MHz
CPU: CPUFreq:			   0MHz
CPU: NoCores/NoThreads:	 1/4
CPU: Features:			  0x000002cf

 

this is log of my cpu FSB IS 0

so my hope is that it is detect auto so no need for more flags

 

for kernel i tested it with this flag but the same

[crazybert]

Initially looked good for me, BUT:

 

After installing this kernel I'm unable to connect to windows (samba) shares anymore.

 

Finder keeps "Connecting..." but it never happens.

 

Rolling back resolves this issue :-(

 

Any clues?

 

Thanks!

[dxm765]

hey everyone just want to check if this update will work on my intel Q6600 and my EliteGroup G31T-M (V1.0)? i think it will or at least should just wanted to double check before i go updating.

[oldnapalm]

You don't need a legacy kernel for Intel Core2Quad CPU.

[dxm765]

Oh ok thank you so much for your reply

[s_woodywood]

Initially looked good for me, BUT:

 

After installing this kernel I'm unable to connect to windows (samba) shares anymore.

 

Finder keeps "Connecting..." but it never happens.

 

Rolling back resolves this issue :-(

 

Any clues?

 

Thanks!

 

Same thing happened to me. I used OSx86 Tools to repair permissions and that took care of the problem.

[quake]

this worked great on my Intel based Aspire and also on my custom AMD. Both now at 10.6.4. Just install Combo Update, before rebooting install the new kernel and Voila! Thank you.

[Snerler]

How do I update the legacy kernel to the latest V5 version?

[Andrea3000]

Do someone knows what may cause this kernel panic? It happens completely random even twice a day.

I'm using the latest anv 10.6.4 legacy kernel (but it was happening even with the previous versions).

Here's my pc specs:

Pentium D820

Motherboard: MSI p4m890m

Snow Leopard 10.6.4 running 32bit with everything working through DSDT

Thank you

[Andy Vandijck]

yeah... that's the minimum required for these cpu's (with sse3, em64t & no Ssse3), when it comes to fixes and with Chameleon as it is.

About cpu family, it's set to Merom just because.. i left it like that from previous tests.

 

 

I think so... in fact, i should have thought of this earlier. Qoopz and i, we did worked on a followup to the "annappirtrvh" kernel before he went MIA;

here is the diff as Qoopz left it: hostosv8.diff.zip To cut it short, i remembered this comment on tsc.c "//qoopz: no get_PIT2 for x86_64" and the related instant reboot, at the time we were testing it. So now, instead of adding the comment related code to the kernel, after reading a bit i compiled a i386/x86_64 from your v5 diff, booted it with "-force64 -notscverify",

et voi lá no instant reboot.

Here is the kernel i used: mach_kernel.zip just updated the version, you left it at v4 on the diff.

That's it... hope it helps.

Excellent.

I will add this bit of code to my patch too and make the 10.5.0 kernel (when it comes out)

[Andy Vandijck]

@Azimutz: I modified your patch slightly so that on x86_64 boot in case of BUSRATIO_TIMER flag it defaults to the BUSRATIO_EFI part instead (then it can at least get some value and should work for all)

Code snippet below:

 

 	case BUSRATIO_BOOTFLAG:
			/* tscGranularity was already set. However, check for N/2. N/2 is specified by
			 * giving a busratio of 10 times what it is (so last digit is 5). We set a cutoff
			 * of 30 before deciding it's n/2. TODO: find a better way */
			if (tscGranularity == 0) tscGranularity = 1; // avoid div by zero
			N_by_2_bus_ratio = (tscGranularity > 30) && ((tscGranularity % 10) != 0);
			if (N_by_2_bus_ratio) tscGranularity /= 10; /* Scale it back to normal */
			break;
#ifndef __i386__ //AnV: in case of x86_64 boot default for busratio timer to EFI value
	case BUSRATIO_TIMER:
#endif
		case BUSRATIO_EFI:
			/* This uses the CPU frequency exported into EFI by the bootloader */
			cpuFreq = EFI_CPU_Frequency();
			prfsts  = getFakeMSR(cpuFreq, busFreq);
		tscGranularity = (uint32_t)bitfield(prfsts, 44, 40);
			N_by_2_bus_ratio = prfsts & bit(46);
			break;
		case BUSRATIO_INTEL_MSR:
			/* This will read the performance status MSR on intel systems (Apple method) */
			prfsts = rdmsr64(IA32_PERF_STS);
			tscGranularity	= (uint32_t)bitfield(prfsts, 44, 40);
			N_by_2_bus_ratio= prfsts & bit(46);
			break;
		case BUSRATIO_ATHLON:
			/* Athlons specify the bus ratio directly in an MSR using a simple formula */
			prfsts		= rdmsr64(AMD_PERF_STS);
			tscGranularity  = 4 + bitfield(prfsts, 5, 1);
			N_by_2_bus_ratio= prfsts & bit(0); /* FIXME: This is experimental! */
			break;
		case BUSRATIO_PENTIUM4_MSR:
			prfsts		= rdmsr64(0x2C); // TODO: Add to header
			tscGranularity	= bitfield(prfsts, 31, 24);
			break;
		case BUSRATIO_PHENOM_SHANGHAI:
			/* Phenoms and Shanghai processors have a different MSR to read the frequency
			 * multiplier and divisor, from which the cpu frequency can be calculated.
			 * This can then be used to construct the fake MSR. */
			prfsts		= rdmsr64(AMD_COFVID_STS);
			printf("rtclock_init: Phenom MSR 0x%x returned: 0x%llx\n", AMD_COFVID_STS, prfsts);
			uint64_t cpuFid = bitfield(prfsts, 5, 0);
			uint64_t cpuDid = bitfield(prfsts, 8, 6);
			/* The base for Fid could be either 8 or 16 depending on the cpu family */
			if (cpuid_info()->cpuid_family == CPU_FAMILY_AMD_PHENOM)
				cpuFreq = (100 * Mega * (cpuFid + 0x10)) >> cpuDid;
			else /* shanghai */
				cpuFreq = (100 * Mega * (cpuFid + 0x08)) >> cpuDid;
			prfsts = getFakeMSR(cpuFreq, busFreq);
			tscGranularity = (uint32_t)bitfield(prfsts, 44, 40);
			N_by_2_bus_ratio = prfsts & bit(46);
			break;
#ifdef __i386__ //qoopz: no get_PIT2 for x86_64
		case BUSRATIO_TIMER:
			/* Fun fun fun. :-|  */
			cpuFreq = timeRDTSC() * 20;
			prfsts = getFakeMSR(cpuFreq, busFreq);
			tscGranularity = (uint32_t)bitfield(prfsts, 44, 40);
			N_by_2_bus_ratio = prfsts & bit(46);
			break;
#endif
		case BUSRATIO_AUTODETECT:
		default:
			kTscPanicOn = 1; /* see sanity check below */
	};

#ifdef __i386__
	/* Verify */
	if (!PE_parse_boot_argn("-notscverify", &boot_arg, sizeof(boot_arg))) {
		uint64_t realCpuFreq = timeRDTSC() * 20;
		cpuFreq = tscGranularity * busFreq;
		if (N_by_2_bus_ratio) cpuFreq += (busFreq / 2);
		uint64_t difference = 0;
		if (realCpuFreq > cpuFreq)
			difference = realCpuFreq - cpuFreq;
		else
			difference = cpuFreq - realCpuFreq;

		if (difference >= 4*Mega) {
			// Shouldn't have more than 4MHz difference. This is about 2-3% of most FSBs.
			// Fall back to using measured speed and correct the busFreq
			// Note that the tscGran was read from CPU so should be correct.
			// Only on Phenom the tscGran is calculated by dividing by busFreq.
			printf("TSC: Reported FSB: %4d.%04dMHz, ", (uint32_t)(busFreq / Mega), (uint32_t)(busFreq % Mega));
			if (N_by_2_bus_ratio)
				busFreq = (realCpuFreq * 2) / (1 + 2*tscGranularity);
			else
				busFreq = realCpuFreq / tscGranularity;
			printf("corrected FSB: %4d.%04dMHz\n", (uint32_t)(busFreq / Mega), (uint32_t)(busFreq % Mega));
			// Reset the busCvt factors
			busFCvtt2n = ((1 * Giga) << 32) / busFreq;
			busFCvtn2t = 0xFFFFFFFFFFFFFFFFULL / busFCvtt2n;
			busFCvtInt = tmrCvt(1 * Peta, 0xFFFFFFFFFFFFFFFFULL / busFreq);
			printf("TSC: Verification of clock speed failed. "
			       "Fallback correction was performed. Please upgrade bootloader.\n");
		} else {
			printf("TSC: Verification of clock speed PASSED.\n");
		}
	}
#else
printf("TSC: Verification of clock speed not available in x86_64.\n");
#endif

[skn]

How do I update the legacy kernel to the latest V5 version?

You just need to replace the mach_kernel file found in the root (/) directory.