10.6.3 legacy kernel for INTEL/AMD ready to download by qoopz/nawcom - a few new features

[Black Knight]

well its a new CPU what did you expect... at least its working on Leopard..... now I don't use this Legacy 10.6.3 for Snow, I simply use the AnV's 10.2.0 no clue if that would help you on yours.

 

I am planning on buying one of those amd 6-cores, but for another build ofcourse.

Try either using my 10.6.3 kernel from infinitemac.com in the new releases section or use the bootflag fsb=200000000. Let me know if it works.

[hnak]

Try either using my 10.6.3 kernel from infinitemac.com in the new releases section or use the bootflag fsb=200000000. Let me know if it works.

Thank you, fsb=200000000 works.

Though I knew fsb wasn't detected correctly, I did not care too much about it.

[Black Knight]

I thought that was the case. My suggestion is to use my kernel (found here: http://osx86.net/f36/blackknight-anv-qoopz...d-phenom-t5112/ since it is Andy's kernel with corrected Phenom FSB detection. The problem is probably due to TurboCore as it bumps the CPU speed over 3.0GHz which causes kernel panics without proper FSB detection. If you tried overclocking your Phenom X4 920 at 3.1 GHz or above, you'd see the same thing happen. My kernel modifies the FSB to be detected as double the default which is how Phenoms calculate their CPU speed and multipliers. Voodoo added a cap on the CPU multiplier of 30 and when combined with a 100MHz FSB comes out to 3.0 GHz. My kernel makes it so the multiplier is correct to the BIOS setting which is 15 and a FSB of 200MHz. This theoretically means that if your processor is capable, you could overclock to 6.0 GHz before you'd see a kernel panic. Also, since my mod is a FSB detection rather than a hardcoded FSB speed, if you overclock the FSB, the kernel will correctly detect the speed and adjust accordingly.

 

Thank you, fsb=200000000 works.

Though I knew fsb wasn't detected correctly, I did not care too much about it.

[hnak]

I thought that was the case. My suggestion is to use my kernel (found here: http://osx86.net/f36/blackknight-anv-qoopz...d-phenom-t5112/ ...

Even with your kernel, it still requires "fsb=200000000" in kernel arguments to boot.

I'll take a look at this issue.

[Black Knight]

Could you send me a screenshot of your console output of the kernel? I want to see what it says at the top when it boots and detects the CPU speed and multiplier. It could be that the CPU is not listed as a Phenom in the CPUID or whatever and if that's the case, my mod wouldn't apply until it is corrected. I hope Andy takes a look at this topic too as he might know more about CPUID detection than I do.

 

Even with your kernel, it still requires "fsb=200000000" in kernel arguments to boot.

I'll take a look at this issue.

[hnak]

Could you send me a screenshot of your console output of the kernel? I want to see what it says at the top when it boots and detects the CPU speed and multiplier. It could be that the CPU is not listed as a Phenom in the CPUID or whatever and if that's the case, my mod wouldn't apply until it is corrected. I hope Andy takes a look at this topic too as he might know more about CPUID detection than I do.

I investigated a little bit deeper.

Actually, the problem arises from the fact that EFI_FSB_frequency() returns 0.

The function gets a value of /efi/platform/FSBFrequency and it is 0x5126084 ( 85090436 ) in this case, then rejected by (90*Mega < frequency) check.

I guess the problem exists in EFI ( Chameleon RC4 ).

A fallback for the case frequency == 0 && cpu == AMD ( to set frequency = 200MHz ) might be necessary.

 

I also noticed modified FSB is shown as 170MHz ( probably, 200Mhz * 2.8GHz / 3.3GHz )

It is possible that max fid obtained from AMD_COFVID_STS is Turbo frequency and does not match the one of p-state0.

[Black Knight]

That's definitely in the kernel as I've seen that condition. I think that your processor has a different CPU Family ID and so my detection code isn't recognizing it as a Phenom or Shanghai and applying the fix accordingly. I need to know what the CPU family is. I'm still working on a way to find out for you, but if you have a clue, let me know.

 

I investigated a little bit deeper.

Actually, the problem arises from the fact that EFI_FSB_frequency() returns 0.

The function gets a value of /efi/platform/FSBFrequency and it is 0x5126084 ( 85090436 ) in this case, then rejected by (90*Mega < frequency) check.

I guess the problem exists in EFI ( Chameleon RC4 ).

A fallback for the case frequency == 0 && cpu == AMD ( to set frequency = 200MHz ) might be necessary.

[hnak]

I believe it is still 10h family.

 

This is what I get from sysctl.

 

machdep.cpu.vendor: AuthenticAMD

machdep.cpu.brand_string: AMD Phenom II X6 1055T Processor

machdep.cpu.family: 16

machdep.cpu.model: 10

machdep.cpu.extmodel: 0

machdep.cpu.extfamily: 1

machdep.cpu.stepping: 0

machdep.cpu.feature_bits: 395049983 8396809

machdep.cpu.extfeature_bits: 4023647231 14335

machdep.cpu.signature: 1052576

[Black Knight]

Yeah, that's what I just discovered too. It should be working then. When you look at your console output using FSB=200000000, what busratio path does it take? It should be like line 3 in your kernel log at the start of boot. Does it take busratio path 3 (AMD Phenom)? If not, what does it take?

[hnak]

Following is related dmesg ( wth fsb=200000000 ) .

 

rtclock_init: Taking bus ratio path 3 (AMD Phenom)

rtclock_init: Phenom MSR 0xc0010071 returned: 0x3042003140000c11

TSC: Reported FSB: 200.0000MHz, corrected FSB: 170.176477MHz

TSC: Verification of clock speed failed. Fallback correction was performed. Please upgrade bootloader.

TSC: Frequency = 0.0000MHz, FSB frequency = 170.176477MHz, bus ratio = 16.5

[Black Knight]

Okay, I think I see the problem. Your CPU is causing a problem because of the default cpu multiplier of 16.5 (3.3GHz = 200*16.5) and a normal multiplier of 14 (2.8 GHz = 200 * 14). The reason the FSB is being corrected to 170 is because the CPU is actually running at 2.8 GHz (170 * 16.5). If you used the bootflag (busratio=14) to hardcode the multiplier at 14, the FSB should be correctly detected as 200MHz, but this still doesn't eliminate the problem. Try this and give me the same output from the Console as before. Maybe it will detect the right path.

 

I think you might be right that Chameleon isn't reporting the FSB correctly to the kernel. The FSB shouldn't be less than 90MHz.

[hnak]

Okay, I think I see the problem. Your CPU is causing a problem because of the default cpu multiplier of 16.5 (3.3GHz = 200*16.5) and a normal multiplier of 14 (2.8 GHz = 200 * 14). The reason the FSB is being corrected to 170 is because the CPU is actually running at 2.8 GHz (170 * 16.5). If you used the bootflag (busratio=14) to hardcode the multiplier at 14, the FSB should be correctly detected as 200MHz, but this still doesn't eliminate the problem. Try this and give me the same output from the Console as before. Maybe it will detect the right path.

 

I think you might be right that Chameleon isn't reporting the FSB correctly to the kernel. The FSB shouldn't be less than 90MHz.

It became:

TSC: Reported FSB: 200.0000MHz, corrected FSB: 200.566195MHz

 

---

 

I added 2 code fragments in tsc_init() ( in tsc.c ) and fixed the problems for now.

 

1. Right after calling EFI_FSB_frequency(), add:

if(busFreq == 0)

busFreq = 200 * Mega;

 

2. Right after calling rdmsr64(AMD_COFVID_STS), add:

prfsts = rdmsr64(AMD_PSTATE0_STS + (uint32_t)bitfield(prfsts, 34, 32));

[Black Knight]

The problem with your hard-coding the FSB at 200MHz is that it doesn't let you overclock the bus without it reporting correctly to the system. It probably won't affect how the system runs though. We need to find a better solution to distribute it though. I find it interesting that it is detecting the processor as a Phenom and taking the correct busratio path, which is good. It's either not detecting the FSB or the busratio correctly from Chameleon. Could you try something else for me and set the CPU multiplier to like 12 or so and see if it boots correctly without hard-coding any FSB or busratio? Do you have an option to turn off turbocore in the BIOS? If you do, try disabling it and see if it works with my kernel or the standard one from this topic. I'd like to see if it works under the 3.0 GHz cap. It might detect the FSB as 100MHz, and the bus ratio as 24, but it should at least boot. Then lets look at the console output again.

 

I'm curious as to what your second mod does. Could you explain?

[hnak]

The problem with your hard-coding the FSB at 200MHz is that it doesn't let you overclock the bus without it reporting correctly to the system. It probably won't affect how the system runs though. We need to find a better solution to distribute it though. I find it interesting that it is detecting the processor as a Phenom and taking the correct busratio path, which is good. It's either not detecting the FSB or the busratio correctly from Chameleon. Could you try something else for me and set the CPU multiplier to like 12 or so and see if it boots correctly without hard-coding any FSB or busratio? Do you have an option to turn off turbocore in the BIOS? If you do, try disabling it and see if it works with my kernel or the standard one from this topic. I'd like to see if it works under the 3.0 GHz cap. It might detect the FSB as 100MHz, and the bus ratio as 24, but it should at least boot. Then lets look at the console output again.

 

I'm curious as to what your second mod does. Could you explain?

1st part is a fallback to avoid crash. Though it may not be the best location, fsb == 0 should be checked at some point, since it's fatal.

 

2nd part is, to take cold boot p-state index ( AMD_COFVID_STS[32:34] ), then get the preset p-state data of the index ( AMD_PSTATE0_STS+0..7 ). It works regardless of boost, I think.

 

I will do some testing and tell you the result later.

 

result:

 

Your kernel boots when boost = 0 and crashes when boost = 1 even if multiplier is set to 12.

When boost = 0, fsb is correctly detected as 200MHz ( ratio is also correct ).

[Alien69]

Hi all !

 

Can some one help me ? i have isntalled the Snow Leopard Server on my PC all went well, but then i have updated to 10.6.3 and i have CPU error i know my CPU as been blocked by apple, but i used the patched kernel from legacy and i keep having cpu panics

 

here is the image:

 

 

My Specs are:

 

MB: Foxconn P43AL

CPU Intel Celeron 430 1.8Ghz

1Gb Memory

 

Can some one help me ? is urgent i need this server up and running

 

thanks in advance.

[ZackMacAttack]

I tested it on my bootcd, instant restart on i5. Can anybody confirm this?

 

qoopz 10.0.0 works fine.

 

I am using qoopz 10.0.0 right now on an i5 and it works great (Except I can't get 64-bit support). I was told that if you have more then 3 GB of ram you have to use the "-force64" kernel flag for it to load. I Have not tested this but I will as soon as my reinstall and update to 10.6.3 is complete.

 

EDIT: I Cannot get this to work. I guess i have to go back to 10.0.0 Kernel

[kiaixplnation]

Does this kernel work with the Intel Celeron p4500 processor?

[jinchuriki]

who knows about kernel or others for 980XX?

 

thx for help!

[sheednu]

I wish I understood all this stuff.... does this work with 10.5.8?

 

Alright, xnu src was released so that means patching up that source code so everyone else can use the latest and greatest kernel.

 

Standard fixes are included, plus a few extra stuff:

 

* Built-in kernel blacklister automatically blacklists bad kexts from loading. Therefore you don't need to use a disabler to disable it manually

* bigger dmesg Which translates to a larger log file so that you can troubleshoot easily

* uuid patching/fix Eliminates the need of UUID kext or specifying manually

* fsb detection

* cpu cache detection

* reboot fix- Eliminates the need of OpenHaltRestart and fixes shutdown/reboot issue

* sse3emu -SSE3 emulator for SSE2 processors . Bear in mind that most of the applications in Snow Leopard run fine with this emulator.

 

Some things added:

 

* For people wanting to use XCode apps, I decided to add all the CHUD kexts to the kext blacklist. This means no more kp hell when installing and dealing with the development tools. If anyone thinks this is something that shouldn't be added, let me know.

 

Features in this specific package:

 

* If you have SleepEnabler installed, your SleepEnabler kext will get updated. If you don't use it, don't worry about it - it won't get installed.

* All of the CPUIDs in the new versions of programs from the 10.6.3 update will get patched. this means you don't need to deal with the hell regarding iTunes, etc.

 

(The actual patcher program also gets installed (/usr/local/bin/patcher, you can run from anyware via Terminal) as well as the CPUID text file (/Library/CPUIDs/*) Though this is only important to people who love control and want to be able to run it themselves :-P - this is all automated in the installer regardless. Unfortunately we still havent gotten on the fly patching working, so this is a reasonable fix for it for now.)

 

I do make cpuid files for updates and keep them online http://nawcom.com/osx86/cpuids/ for AMD people to use regarding updates as well as a nice frontend to Maxxuss' patcher app, drag and drop a cpuid.txt file onto the app to launch it - just like Taruga's HDA Patcher.

 

Anyways, good luck to all. Source diffs are always available. -> http://nawcom.com/osx86/files/10.6/Kernels...-1504.3.12.diff

 

If anyone wants to contribute I'm always on irc - irc.osx86.hu #snowleopard #hackint0sh; irc.voodooprojects.org #chameleon #xnu-chat; irc.moofspeak.net #osx86.

 

Updated code - If you had issues before please try the new version

 

For the people that have been getting instant reboots, so far them booting with arch=i386 works. I am looking into why this is needed in this version of the kernel by looking into diffs between xnu versions. Since this kernel is only one architecture i386 is the only real option. I've updated the pkg so it checks to see if you have arch=i386 in kernel flags, and if you don't it will add it to your kernel flags.

 

External link: http://nawcom.com/osx86/files/10.6/Kernels...-10.3.0.pkg.zip

Another External link: http://www.mediafire.com/?mqyzohqmnyg

 

If you are looking for the 10.6.2 xnu kernel, look here: http://www.insanelymac.com/forum/index.php?showtopic=191606

[hiqu]

who knows about kernel or others for 980XX?

 

thx for help!

 

 

This works on gulftown 6 core processor based workstation HP Z400

[LeXa2]

Two my cents: this kernel works quite good inside VirtualBOX 3.2.0 guest running on the AMD Phenom II X4 host. VirtualBOX 3.2.0 virtualizes almost all hardware except for CPUID, so it is required to use patched kernel for Mac OS to boot up on hosts with the "wrong" CPUs. The only problems faced with this kernel are sporadic panics (approx once in a couple of days) during normal work, and guaranteed kernel panic when trying to Shutdown/Reboot the VM.

 

I've got some questions that might be noob/dumb but I would appreciate answers. Tell me please is it possible to run, say, Mac OS X 10.6.3 using the kernel from the older releases (for ex. kernel 10.2.0 from Mac OS 10.6.2 or kernel 9.5 from Mac OS X 10.5.x)? Would be there any unforeseen consequences in using such kernel/OS combinations? And - in case that's possible - what to do with the System.kext? I had read somewhere that the version of System.kext should always match the version of a kernel and that failing to provide a match would almost certainly cause a stange system behavior and kernel panics. Is that true? Where to get System.kext matching the older kernels?

Thanks in advance for answers!

[—lxm.]

Did update to 10.6.3 but get KP. Installed legacy kernel 10.3.0 prior to. Can someone please help decipher KP? Much appreciated.

[AMDFTW]

Thanks for the release!

[Jason K Carter]

Did update to 10.6.3 but get KP. Installed legacy kernel 10.3.0 prior to. Can someone please help decipher KP? Much appreciated.

 

I get the same issue.

[ninjonxb]

Hi, I installed the version released a couple days ago. I have an AMD Athelon 62 X2 processor.

 

I messed up and did not run the update and my system is still running 10.6 when i updated the kernal.

 

As soon as I boot i get a kernal panic.

 

I have tried to go in and put in the old com.apple.Boot.plist file but it still tries to boot to the legacy_kernal

 

So how do I uninstall this? or how do i tell chameleon to boot to mach_kernal.test7 so i can try to apply the update?

 

Thanks.