Voodoo Kernel BETA 2 - Available now

[Fourof4]

I tried to test this.. but I could not even enter the boot up process after kernel loading..

 

I booted up with "voodoo_beta2 -v" and I used official AppleSMBIOS.kext and SMBIOSResolver.kext

 

oh.. and I am using Munky's boot partition.. I dont know if this matters though..

[Snerler]

I tried it with AMD Athlon X2 processor and the kernel boots and runs all applications with the exception of VMare Fusion 2.0. I get a kernel panic when a virtual machine starts. Is this a known problem?

[xtreme_xtc]

Used on a P4 2.4b Northwood has the same problem as Beta1 it cannot detect the proper TSC and busratio. Had to manually add busratio=18 and fsb=133000000. It sets it as busratio=1 and fsb=100, which is incorrect ofcourse. Other then that it boots just fine.

[mercurysquad]

I tried it with AMD Athlon X2 processor and the kernel boots and runs all applications with the exception of VMare Fusion 2.0. I get a kernel panic when a virtual machine starts. Is this a known problem?

Yes. For VMWare, running kernel must be named /mach_kernel

 

Used on a P4 2.4b Northwood has the same problem as Beta1 it cannot detect the proper TSC and busratio. Had to manually add busratio=18 and fsb=133000000. It sets it as busratio=1 and fsb=100, which is incorrect ofcourse. Other then that it boots just fine.

Known issue. As I've mentioned before, P4 Northwood users must set busratio=XX bootflag. It is detecting 100 MHz FSB because that's what your bootloader is sending.

[RX07]

Ok.....

 

voodoo_beta2c using following bootflag -->> TSC test ok.

 

-v busratio=21 fsb=125000000

 

for AMD Athlon64, 2625Mhz (250x10.5)

[FavleX]

ok.

voodoo_beta2 is working here on my Wind

Sleep either.

Just noticed a big artifact on System Preferences .app , when Display submenu is being selected

 

 

 

[mercurysquad]

I have TSC problem just like Moro21,

 

athlon64 x2 4200+ (BIOS setting FSB 250Mhz, 10.5x, turn-off CNQ, HT 4x)

 

Leo4allv4.1.1

voodoo_beta 2c kernel

AppleSMBIOS.kext (official)

AppleSMBIOSEFI.kext (Chun-Nan's made)

forcedeth.kext (bhst2 new version)

 

(1) no any booting options, TSC test different 6~7 sec.

 

(1a) booting with -v -tscpanic, report;

rtclock_int: 1 (AMD ATHLON)

TSC frequency: 393.751623Mhz, bus=262.501082Mhz, multiplier=1.5x

 

(2) booting with -v busratio=262

TSC test different 2 sec.

 

(3) booting with -v busratio=263

TSC test different 2 sec.

 

(3) booting with -v busratio=262.5

--->> kernel panic occur (just like -v -tscpanic options when booting)

 

Actually let me analyze this problem in detail, so everyone has a better understanding of this issue.

 

The kernel keeps track of time by counting CPU ticks. To convert cpu ticks into real time, it needs to know how many ticks there are in 1 second. This is why it needs to know the cpu freq exactly, which can be found out by the fsb freq and multiplier. Apple does this by reading the multiplier from the CPU (we do this too), and reading the FSB frequency from EFI (we do this too -- but this is fake EFI and the bootloader measures the FSB and exports to the kernel).

 

Now in your case the FSB is 250 MHz. Multiplier 10.5. This gives ~2625 million ticks per second. The 250MHz fsb is usually a bit less or more, so you could have say 248.2 MHz or 253.05 MHz etc. The bootloader measures this using another timer. In your case, the bootloader somehow measured 262.5 MHz. This is a difference of 12.5 MHz. With a multiplier for 10.5, you get a difference of ~130 MHz per second. This means, when 2625+130 = 2755M ticks have passed, then the kernel thinks 1 second has passed. When in real, 0.05 second extra has passed. So in 2 minutes, 0.05*120 = 6 second extra has passed.

 

This is why you see an offset of 6 seconds.

 

To correct this we need to accurately measure the CPU speed. And for that we need the bootloader to accurately measure the FSB. My guess is that the bootloader is measuring the CPU freq fine (2625 MHz), then assuming that the bus ration is 10 (not 10.5), so dividing we get 262.5 instead of 250 (real). The kernel however, correctly finds busratio 10.5, NOT 10, and because of this mismatch, it thinks your CPU speed is something it is not. End result: bootloader bug.

 

Since now after 13 alphas and 2 betas it is clear that bootloader's FSB export is not reliable on AMD (freakin AMD's tsc implementation is even worse than pentium M), I'll have to look for workarounds. I'll get in touch with Chameleon devs to verify my suspicion that it's a bug in the bootloader. Let's see.

 

 

Edit: corrected some math and removed AMD-bashing

 

Update 2: Kabyl confirms: (re-phrased) Yes turns out it's a bug in chameleon. And not really a bug in chameleon as much as a BUG IN FREAKING AMD DOCUMENTATION! They never documented non-integer bus ratio for athlons/opterons of K8 family. They simply say "other values are reserved".

 

Well the kernel won't include a workaround for this, so we avoid duplicated code. AMD Athlon users who are having audio or timing issues will also need to upgrade to the newer chameleon. Until then, pass fsb=xxxxxxx to the kernel.

[B612]

Yes. For VMWare, running kernel must be named /mach_kernel

 

I'm using my voodoo_beta2c kernel from EFI partition. The kernel in root is vanilla, and so is the installation I have in this partition. VMWare always gives me a panic. Is there a way I can fix this without having to substitute the vanilla kernel with the patched one?

[mercurysquad]

I'm using my voodoo_beta2c kernel from EFI partition. The kernel in root is vanilla, and so is the installation I have in this partition. VMWare always gives me a panic. Is there a way I can fix this without having to substitute the vanilla kernel with the patched one?

No. VMWare uses certain 'hacks' to get address of some kernel symbols by reading the kernel file directly. They have hard-coded it to be /mach_kernel, so this will not work if your running kernel is something else. This is a bug in VMware.

 

You might try changing the default kernel to voodoo_beta2c in Boot.plist, but I can't guarantee it will work.

[Moro21]

Hi,

Thanks for the attachments. I still need you to follow step 5 of procedure 3 and attach the output of it.

 

 

okok

 

i've done...

 

 

Actually let me analyze this problem in detail, so everyone has a better understanding of this issue.

 

The kernel keeps track of time by counting CPU ticks. To convert cpu ticks into real time, it needs to know how many ticks there are in 1 second. This is why it needs to know the cpu freq exactly, which can be found out by the fsb freq and multiplier. Apple does this by reading the multiplier from the CPU (we do this too), and reading the FSB frequency from EFI (we do this too -- but this is fake EFI and the bootloader measures the FSB and exports to the kernel).

 

Now in your case the FSB is 250 MHz. Multiplier 10.5. This gives ~2625 million ticks per second. The 250MHz fsb is usually a bit less or more, so you could have say 248.2 MHz or 253.05 MHz etc. The bootloader measures this using another timer. In your case, the bootloader somehow measured 262.5 MHz. This is a difference of 12.5 MHz. With a multiplier for 10.5, you get a difference of ~130 MHz per second. This means, when 2625+130 = 2755M ticks have passed, then the kernel thinks 1 second has passed. When in real, 0.05 second extra has passed. So in 2 minutes, 0.05*120 = 6 second extra has passed.

 

This is why you see an offset of 6 seconds.

 

To correct this we need to accurately measure the CPU speed. And for that we need the bootloader to accurately measure the FSB. My guess is that the bootloader is measuring the CPU freq fine (2625 MHz), then assuming that the bus ration is 10 (not 10.5), so dividing we get 262.5 instead of 250 (real). The kernel however, correctly finds busratio 10.5, NOT 10, and because of this mismatch, it thinks your CPU speed is something it is not. End result: bootloader bug.

 

Since now after 13 alphas and 2 betas it is clear that bootloader's FSB export is not reliable on AMD (freakin AMD's tsc implementation is even worse than pentium M), I'll have to look for workarounds. I'll get in touch with Chameleon devs to verify my suspicion that it's a bug in the bootloader. Let's see.

 

 

Edit: corrected some math and removed AMD-bashing

 

Update 2: Kabyl confirms: (re-phrased) Yes turns out it's a bug in chameleon. And not really a bug in chameleon as much as a BUG IN FREAKING AMD DOCUMENTATION! They never documented non-integer bus ratio for athlons/opterons of K8 family. They simply say "other values are reserved".

 

Well the kernel won't include a workaround for this, so we avoid duplicated code. AMD Athlon users who are having audio or timing issues will also need to upgrade to the newer chameleon. Until then, pass fsb=xxxxxxx to the kernel.

 

then i must wait the new chameleon release?

 

from your google space:

"Known bug with Chameleon bootloader. Marking as WontFix. Upgrade to newer Chameleon when it's released."

 

or i can start the kernel with " voodoo_beta2 fsb=2500 " all right??

[RX07]

Actually let me analyze this problem in detail, so everyone has a better understanding of this issue.

 

The kernel keeps track of time by counting CPU ticks. To convert cpu ticks into real time, it needs to know how many ticks there are in 1 second. This is why it needs to know the cpu freq exactly, which can be found out by the fsb freq and multiplier. Apple does this by reading the multiplier from the CPU (we do this too), and reading the FSB frequency from EFI (we do this too -- but this is fake EFI and the bootloader measures the FSB and exports to the kernel).

 

Now in your case the FSB is 250 MHz. Multiplier 10.5. This gives ~2625 million ticks per second. The 250MHz fsb is usually a bit less or more, so you could have say 248.2 MHz or 253.05 MHz etc. The bootloader measures this using another timer. In your case, the bootloader somehow measured 262.5 MHz. This is a difference of 12.5 MHz. With a multiplier for 10.5, you get a difference of ~130 MHz per second. This means, when 2625+130 = 2755M ticks have passed, then the kernel thinks 1 second has passed. When in real, 0.05 second extra has passed. So in 2 minutes, 0.05*120 = 6 second extra has passed.

 

This is why you see an offset of 6 seconds.

 

To correct this we need to accurately measure the CPU speed. And for that we need the bootloader to accurately measure the FSB. My guess is that the bootloader is measuring the CPU freq fine (2625 MHz), then assuming that the bus ration is 10 (not 10.5), so dividing we get 262.5 instead of 250 (real). The kernel however, correctly finds busratio 10.5, NOT 10, and because of this mismatch, it thinks your CPU speed is something it is not. End result: bootloader bug.

 

Since now after 13 alphas and 2 betas it is clear that bootloader's FSB export is not reliable on AMD (freakin AMD's tsc implementation is even worse than pentium M), I'll have to look for workarounds. I'll get in touch with Chameleon devs to verify my suspicion that it's a bug in the bootloader. Let's see.

 

 

Edit: corrected some math and removed AMD-bashing

 

Update 2: Kabyl confirms: (re-phrased) Yes turns out it's a bug in chameleon. And not really a bug in chameleon as much as a BUG IN FREAKING AMD DOCUMENTATION! They never documented non-integer bus ratio for athlons/opterons of K8 family. They simply say "other values are reserved".

 

Well the kernel won't include a workaround for this, so we avoid duplicated code. AMD Athlon users who are having audio or timing issues will also need to upgrade to the newer chameleon. Until then, pass fsb=xxxxxxx to the kernel.

 

 

 

@mercurysquad,

 

THANKS your detail explain!!

 

I have clearly understand what problem cause 6~7 sec!!

 

and (as I say in #55 of this thread)

 

 

 

Ok.....

 

voodoo_beta2c using following bootflag -->> TSC test ok.

 

-v busratio=21 fsb=125000000

 

for AMD Athlon64, 2625Mhz (250x10.5)

 

I have test5 twice and get 0 sec different

 

which mean using "busratio=21 fsb=125000000" is correct bootflag??

 

thanks

 

 

@Moro21,

 

my problem very like yours,

maybe try to set fsb=FSB (in Herz)/2 and busratio=(BIOS setting)*2

ex:

 

250Mhz * 10.5 ==> fsb=125000000 busratio=21

220Mhz * 8.5 ===> fsb=110000000 busratio=17

 

maybe you can get 0 sec diffecent in test5

[Moro21]

@Moro21,

 

my problem very like yours,

maybe try to set fsb=FSB (in Herz)/2 and busratio=(BIOS setting)*2

ex:

 

250Mhz * 10.5 ==> fsb=125000000 busratio=21

220Mhz * 8.5 ===> fsb=110000000 busratio=17

 

maybe you can get 0 sec diffecent in test5

 

sorry..I didn't understand the concept..

 

my cpu clock is 2500mhz... how to start?? with fsb=xxxxx busratio=yyy

thank for your help!

[mercurysquad]

Eh guys, the PDF mentions everything clearly..... but let me explain once again:

 

Use your real FSB in Herz and busratio. If your bus ratio is not an integer (like 8.5, 10.5 etc.): just omit the decimal point!. Kernel will understand that bus ratio cannot be so high, and will automatically divide by 10.

 

So if your FSB is 250MHz and bus ratio is 10.5, use: fsb=250000000 busratio=105

Another example: For FSB 200 MHz and ratio 8.5 use: fsb=200000000 busratio=85

And more examples: FSB 133 MHz ratio 13: fsb=133000000 busratio=13 (here no 130 because it is simple integer)

 

I hope it's clear now.

BUS RATIO is the same as MULTIPLIER.

BUS SPEED is the same as FSB FREQUENCY.

 

@Moro21:

Look at the bus speed: it is 201 MHz and multiplier is 12.5. So use fsb=201000000 busratio=125 and you're set.

 

NOTE: Chameleon has been update already, and it should be released with beta3. Then NO ONE has to supply any bootflags.

[Moro21]

Eh guys, the PDF mentions everything clearly..... but let me explain once again:

 

Use your real FSB in Herz and busratio. If your bus ratio is not an integer (like 8.5, 10.5 etc.): just omit the decimal point!. Kernel will understand that bus ratio cannot be so high, and will automatically divide by 10.

 

So if your FSB is 250MHz and bus ratio is 10.5, use: fsb=250000000 busratio=105

Another example: For FSB 200 MHz and ratio 8.5 use: fsb=200000000 busratio=85

And more examples: FSB 133 MHz ratio 13: fsb=133000000 busratio=13 (here no 130 because it is simple integer)

 

I hope it's clear now.

BUS RATIO is the same as MULTIPLIER.

BUS SPEED is the same as FSB FREQUENCY.

 

@Moro21:

Look at the bus speed: it is 201 MHz and multiplier is 12.5. So use fsb=201000000 busratio=125 and you're set.

 

NOTE: Chameleon has been update already, and it should be released with beta3. Then NO ONE has to supply any bootflags.

 

ok.. thk u very much... and sorry for misunderstanding

 

where can i found the beta3 of cameleon?

i've found boot1hp.. is this??

[mercurysquad]

ok.. thk u very much... and sorry for misunderstanding

 

where can i found the beta3 of cameleon?

i've found boot1hp.. is this??

 

New Chameleon is not yet released. It will be released with the last beta version of Voodoo (beta 3) in a few days.

[bhst2]

ok.

voodoo_beta2 is working here on my Wind

Sleep either.

Just noticed a big artifact on System Preferences .app , when Display submenu is being selected

 

Sorry to say but I don't think it is the kernel that is causing that

Here is mine and i don't have any artifacts

[RX07]

Eh guys, the PDF mentions everything clearly..... but let me explain once again:

 

So if your FSB is 250MHz and bus ratio is 10.5, use: fsb=250000000 busratio=105

Another example: For FSB 200 MHz and ratio 8.5 use: fsb=200000000 busratio=85

And more examples: FSB 133 MHz ratio 13: fsb=133000000 busratio=13 (here no 130 because it is simple integer)

 

I hope it's clear now.

BUS RATIO is the same as MULTIPLIER.

BUS SPEED is the same as FSB FREQUENCY.

 

NOTE: Chameleon has been update already, and it should be released with beta3. Then NO ONE has to supply any bootflags.

 

 

 

thank again .....

 

busratio=105 fsb=250000000

 

TSC test5 report OK. (0 sec).....

[Guest cavallo]

Voodoo 9.5 Kernel BETA 2 Download

 

Please read the Test plan and debug procedure PDFs before proceeding with the beta test. Please understand that this is a beta test - it may break your system, and novices should not attempt to test the kernel!

 

The beta brings several fixes for AMD users, as well as generic fixes for cache information, timing code and opcode patcher. AMD users should see improved performance without any timer/div-zero/erratic mouse behaviour. Athlon and Phenom users experiencing audio or timer issues should no longer have these problems. Pentium 4 model 2 users no longer have to specify busratio. AMD users should be able to run Marvin, Zephyroth. Skype and other utilities without problems.

 

Note: While we are pushing the opcode/cpuid patcher in stages, it is not functional yet. Many apps will work without patching, but absence of a dynamic library patcher means you cannot rely on this behaviour until the final version is released.

 

As always, successes go here. Bugs go on Google Code.

 

Thanks!

~VoodooLabs

 

i can't load it why?

I have two leo4all 4.1 installed on the 40 gb maxtor i loaded and it is fantastic, on the main one 465 gb hd no way to load it.

[Moro21]

New Chameleon is not yet released. It will be released with the last beta version of Voodoo (beta 3) in a few days.

 

ok.. tnk 4 the info..

 

YES!! starting @ boot with voodoo_beta2 fsb=201000000 busratio=125

WORK!!!!!!

 

now, it's all ok!! audio,reboot,sleep...

 

tnk!!

 

tsc report OK (0sec)

[JackHair]

On the system in my sig the kernel is totally stable. All test passed without bootflags. I noticed parallels is running way better now. It used to crash on me alot, but haven't got a single crash since I use beta2c.

I still need to do some more stress testing.

 

Keep up the good work

 

Edit:

I left my PC on for the night. It was sleeping when I woke up. OS X woke up nicely. and I did another test5 run. Passed again.

Paralles also ran when I left my PC, it's still running/responding nicely.

Looking very good

[ar4er]

Sleep/Resume Passed: [X] Yes [_] No [_] With issues

 

Shutdown Passed: [X] Yes [_] No [_] With issues

 

Audio/Video performance Passed: [X] Yes [_] No [_] With issues

 

TSC stability Passed: [_] Yes [X] No [_] With issues

Local sleep time: 120 seconds
Remote sleep time: 121 seconds

Reported time difference between local and remote is 1 seconds

 

Cache information Passed: [X] Yes [_] No [_] With issues

hw.l2cachesize: 524288
hw.l1dcachesize: 65536
hw.l1icachesize: 65536
hw.cachelinesize: 64
hw.cachesize: 4294967296 65536 524288 0 0 0 0 0 0 0
hw.cacheconfig: 2 1 1 0 0 0 0 0 0 0
hw.cachelinesize = 64
hw.l1icachesize = 65536
hw.l1dcachesize = 65536
hw.l2cachesize = 524288

 

Normal Loading occurs only with the boot flag fsb = 200000000

ar4er_ar4ers_mac_pro.local.zip

[moskivirit]

Hello, Voodoo XNU Beta 2c works great on my P4 HT Northwood, all tests passed OK.

Chameleon 1.0.11 would report multiplier as 0 and fsb as 100mhz which are wrong, CPU frequency was OK. So i currently use a modified chameleon with hardcoded fsb and multiplier until beta3.

 

I tried the original beta2 and it worked without adding any flags. With beta2c i must specify busratiopath=6 , or it would take the second path by default, Pentium 4 EFI path, and couldn't find the multiplier, it would return the multiplier as 1. busratiopath=6 works fine for me!

 

I've also tested the Toast app which was mentioned by cavallo in this thread, and i couldn't get it to start without Rosetta PPC emulation.

Much thanks to the VoodooLabs team

[mercurysquad]

I tried the original beta2 and it worked without adding any flags. With beta2c i must specify busratiopath=6 , or it would take the second path by default, Pentium 4 EFI path, and couldn't find the multiplier, it would return the multiplier as 1. busratiopath=6 works fine for me!

Yes it was part of the changes I made for P4, and then reversed as either this or another change was causing kernel panic for other P4 users. I will put it back for next beta because this was not the reason for the KP.

[B612]

am I the only one that cannot wake up from sleep? (why?!?)

[mercurysquad]

am I the only one that cannot wake up from sleep? (why?!?)

There are so many people who cannot suspend/resume that I have stopped accepting bug reports for suspend/resume issues. Suspend/resume support is done as far as the kernel is concerned. If you can't resume, it's a kext problem.