Private alpha test of Voodoo 9.5 Kernel

[Nick14]

Which kext?? On C2D or other Apple-supported CPUs this kernel is 99.99% vanilla.

 

Also, if no other kernel worked on your p-M then it's obviously not the kernel's fault. PentiumM is the best tested cpu because the kernel is mostly being developed on a pentium m.

 

And guys for the last time - PLEASE ALSO REPORT WHAT KERNEL PANIC YOU GET INSTEAD OF JUST SAYING KERNEL PANICC!!!11!

 

thanks.

Ohh I ment kernel ok Thx beocuse it worked Perfectly on my P4HT desktop and C2D vostro

 

But when the first realese of voodoo it worked on the PentiumM but i'm going to try again soon i just installed xp

[ar4er]

Voodo alpha 13 works well only with the flag fsb = 200000000, and restart after hibernation and does not work. After a restart, the screen goes out and nothing happens, it must continue button on the system unit.

[lastowl]

Just kernel panics my system my spec in my sig and the panic is in the pic

I booted with -v busratio=14 fsb=800000000 and tried cpu=1

The 9.4 kernel did boot on my system if that helps and nforce kernels do boot on my system aswell but none of the voodoo 9.5 have

[ar4er]

-v busratio=14 fsb=800000000 and tried cpu=1

Do you busratio = 3.5 (2800/800), or busratio=14 fsb=200000000 (14*200=2800)

[Dxn]

I just wanted to report that the alpha 13 kernel is working flawlessly with the only boot flag being the cpus=1, which I need for the onboard LAN to work.

 

AMD Athlon X2 6000+

M2N-SLI Deluxe

 

Excellent work. I can't wait for the open beta.

[moes]

hi

 

Installed retail with boot123 (munky's topic) and updated to 10.5.5

I started using the

mach_kernel (from the old 10.5 osx86 dvd) and toh(netkas) copied from iAtkos 10.5.4.

Both kernels boot and have their own benefits.....and then started using voodoo_alpha13.

Because there was some real difference in performance i did some xbench tests (xbench 1.3)

 

Did the test without the disk/hd-test....took to long and is a slow "test-install"-hd annyway.

 

Here are some relevant results:

 

toh-disktest= 59.3 (working: serial/sys. prof) proper shutdown

 

mach-disktest= 60.3 (working serial) proper shutdown

 

voodooalpha13-disktest=22.6 double speed spinners+beach ball (working: serial/usb/sys. prof)

 

 

The voodoo kernel gives best compatibility but doesn't shut down ok, gives a much lower xbench score.....and still can't solve the very fast animation of bouncing icons ,spinner and beach ball.!!!

 

pentium 4 (northwood) 2,8 ghz ((hyper threading)

MB: albatron865 pe/pro

2,5 ram (dual channel)

nvidia GF5700le 265mb

20 gb ide

default sound by usb guitar amp :e-mu tracker pre

 

 

 

to login with boot123:

 

rd(0,1)/voodoo_alpha13 busratio=14 -f rd-diskXsY

 

14X200=2800......2,8 ghz???

 

How can i fix the speedy interface???

 

 

 

[mercurysquad]

We'll look into all the reports we have received so far.

 

However - can everyone please report all issues on this page? That makes it much easier to track each separate issue, as we can tag comments etc, and easily see which bugs are still not fixed before releasing the next beta. It also allows others to view existing issues to find solutions to their problems and avoid repeating already-reported bugs. Help us help you!

 

News on the beta: We are still preparing the test plan and debug procedures, so it will not be available immediately.

 

hi

 

voodooalpha13-disktest=22.6 double speed spinners+beach ball (working: serial/usb/sys. prof)

The voodoo kernel gives best compatibility but doesn't shut down ok, gives a much lower xbench score.....and still can't solve the very fast animation of bouncing icons ,spinner and beach ball.!!!

 

 

I've answered this for you before: please see 3rd answer in this post to understand the Xbench issue. You're using a Northwood core P4 which is known to have incompatibilities with Voodoo unless you use an updated Chameleon bootloader - this will be available together with the final release (or perhaps during beta).

 

Until then, please make sure your bus frequency is correct. To check you busFreq, boot with busratio=0 - this will force a kernel panic and will show your busFreq= xxx MHz. Make sure it is actually close to 200. This has been observed before (ref. ritalin assuming bus ratio was 200 mhz with 11x, turns out it was 100 mhz with 22x).

 

EDIT: Exactly what I thought. I checked the specs for you and your CPU uses 100 MHz fsb, not 200. Boot up with busratio=28 and your problems will be solved. Refer to that wikipedia link to confirm.

 

EDIT 2: Anyone interested in Xbench comparison (I don't think it's a kernel benchmark, but anyway..) attached are results from my system, comparing Voodoo pre-Beta (this has on-the-fly patcher enabled) vs. ToH 9.2 kernel. I ran the tests 2-3 times and the results are somewhat consistent within the margin of error, Voodoo being about 1 to 2% faster than ToH on an average (which doesn't mean much, but e.g. the veclib fft test is 12% faster).

 

And on this page you can find some internal benchmark results we made to compare old (included with ToH) sse3 emulator with new (voodoo).

[tehnick]

Hi, I noticed you mentioned "fixing" the AMD timing issue.

 

Is this the same issue outlined here? : http://www.infinitemac.com/f5/amd-dual-cor...mouse-bug-t734/

 

There is dozens of random issues that appear to be pointing at AMD dual-core processors, and I've been forced to use the cpus=1 flag to disable one of the cores just to relieve some of them. No one has managed to "fix" this since the very first OSX86 release when it was discovered. I'd imagine this would deal with the kernel, but do all of those symptoms point towards the timing bug? Or is there other things with AMD causing problems?

[mercurysquad]

whoa.. it's gonna to take some time to go through the 45 page thread. I've never had an AMD based osx86 machine, so I have not experienced these issues (nor very familiar with them). The AMD fixes I've been talking about do relate with the tsc, though. There is also a tsc sync patch in the kernel (not written by me) which should help. Has anyone run alpha13 without any bootflags and confirmed the issues still exist?

 

Anyway to put it concisely: things which I have changed directly relate to the timing code, so it might very well fix the problems, but I can't be sure unless I know the problems in detail and the cause of it. So yeah, let me go through the thread.

[SP1950]

---------- CPUID START ----------
CPUID: Basic Leaves:
CPUID: 00000000: eax = 00000001, ebx = 68747541, ecx = 444d4163, edx = 69746e65
CPUID: 00000001: eax = 00060fb1, ebx = 01020800, ecx = 00002001, edx = 178bfbff
CPUID: 00000002: eax = 00000000, ebx = 00000000, ecx = 00000000, edx = 00000000
CPUID: 00000003: eax = 00000000, ebx = 00000000, ecx = 00000000, edx = 00000000
CPUID: 00000004: eax = 00000000, ebx = 00000000, ecx = 00000000, edx = 00000000
CPUID: Extended leaves:
CPUID: 80000000: eax = 80000018, ebx = 68747541, ecx = 444d4163, edx = 69746e65
CPUID: 80000001: eax = 00060fb1, ebx = 000008cb, ecx = 0000011f, edx = ebd3fbff
CPUID: 80000002: eax = 20444d41, ebx = 6c687441, ecx = 74286e6f, edx = 3620296d
CPUID: 80000003: eax = 32582034, ebx = 61754420, ecx = 6f43206c, edx = 50206572
CPUID: 80000004: eax = 65636f72, ebx = 726f7373, ecx = 30363320, edx = 00002b30
CPUID: MSR : 0xa0b020b
----------- CPUID END -----------

 

FSB:250MHz

CPU Freq: 2375MHz

Running a13 9.5.0 kernel on nforce chipset

audio stutters and clock drifts

a new beta would be appreciated!

thanks!

[Strimer]

Thank you! Works fine!

 

Intel D930

Gigabyte X48-DS5

Geforce 8400GS 256MB

8GB RAM 800MHz

 

80GB HDD SATA AHCI-Modus

DVD-Burner SATA AHCI-Modus

 

Anything works fine (PS/2, Firewire, Sound (ALC-889), Graphics (NVKUSH), USB2 (sometimes slow!)

[JackHair]

whoa.. it's gonna to take some time to go through the 45 page thread. I've never had an AMD based osx86 machine, so I have not experienced these issues (nor very familiar with them). The AMD fixes I've been talking about do relate with the tsc, though. There is also a tsc sync patch in the kernel (not written by me) which should help. Has anyone run alpha13 without any bootflags and confirmed the issues still exist?

 

Anyway to put it concisely: things which I have changed directly relate to the timing code, so it might very well fix the problems, but I can't be sure unless I know the problems in detail and the cause of it. So yeah, let me go through the thread.

 

I've been running alpha13 on my AMD for a few days now without flags, and the only minor issue I get is that reboot/shutdown don't always work. Sometimes after reboot it just sits there after OSx closes and should reboot, and I have to press the reset button. At shutdown I ones (yes only ones) had the "you have to press reset button....." msg. Other then that no issues.

[xeongx]

Thinkpad

Intel Celeron 1.4Ghz

1.25GB Ram

30GB hard drive

Intel GMA900

 

PC

AMD Athlon 64 3400+

1GB Ram

200GB hard drive

ATI 9600

[lastowl]

tried the suggestion alway the same fault as shown in my previous post pic

[mercurysquad]

Seems to be probably something in the kernel instead of the kext. I'm trying to track down the creator of the nforce kernel so we can discuss what changes are needed. I don't have the hardware so cannot test/fix on my own, unless someone can explain the issue. Hopefully this will be fixed before the final release as I expect a lot of people are affected by this.

[General_Cartman]

Alpha 13 working fine on the AMD system in my signature. No Sleep or Restart though.

[Voyn1x]

Hi mercurysquad, i'm one of the admins over at infinitemac who also suffers from the dual core bug mentioned earlier on my Athlon 4200 x2.

 

I've been testing the alpha13 kernel without any flags. The system has now been up for 22hrs and i'm starting to suffer the usual symptoms like applications crashing with divide by zero errors like the following:

 

 Exception Type:  EXC_ARITHMETIC (SIGFPE)
Exception Codes: EXC_I386_DIV (divide by zero)
Crashed Thread:  1

Thread 1 Crashed:
0   libSystem.B.dylib				 0xffff0315 __gettimeofday + 53
1   libSystem.B.dylib				 0x90b52159 gettimeofday + 50
2   com.apple.CoreFoundation		  0x90328600 CFAbsoluteTimeGetCurrent + 32

 

Also at the moment my console log is littered with these mDNSResponder entries:

 

28/09/2008 08:34:01 mDNSResponder[16] mDNSPlatformRawTime: last_mach_absolute_time 3EA19EF3000046BC 
28/09/2008 08:34:01 mDNSResponder[16] mDNSPlatformRawTime: this_mach_absolute_time 3E241EFF000046BC 
28/09/2008 08:34:01 mDNSResponder[16] mDNSPlatformRawTime: last_mach_absolute_time 4496CD56000046BC 
28/09/2008 08:34:01 mDNSResponder[16] mDNSPlatformRawTime: this_mach_absolute_time 441979FF000046BC 
28/09/2008 08:34:01 mDNSResponder[16] mDNSPlatformRawTime went backwards by 7 ticks; setting correction factor to -1474660758 
28/09/2008 08:34:18 mDNSResponder[16] mDNSPlatformRawTime: last_mach_absolute_time 1BBA4C29000046C0 
28/09/2008 08:34:18 mDNSResponder[16] mDNSPlatformRawTime: this_mach_absolute_time 1B3D6056000046C0 
28/09/2008 08:34:18 mDNSResponder[16] mDNSPlatformRawTime went backwards by 7 ticks; setting correction factor to -1474660751 
28/09/2008 08:34:48 mDNSResponder[16] mDNSPlatformRawTime: last_mach_absolute_time 1774C52A000046C7 
28/09/2008 08:34:48 mDNSResponder[16] mDNSPlatformRawTime: this_mach_absolute_time 16F7FCF3000046C7 
28/09/2008 08:34:48 mDNSResponder[16] mDNSPlatformRawTime went backwards by 6 ticks; setting correction factor to -1474660745 
28/09/2008 08:36:34 mDNSResponder[16] mDNSPlatformRawTime: last_mach_absolute_time F715CB75000046DF 
28/09/2008 08:36:34 mDNSResponder[16] mDNSPlatformRawTime: this_mach_absolute_time F69BF69C000046DF 
28/09/2008 08:36:34 mDNSResponder[16] mDNSPlatformRawTime: last_mach_absolute_time F7512365000046DF 
28/09/2008 08:36:34 mDNSResponder[16] mDNSPlatformRawTime: this_mach_absolute_time F6D201F3000046DF 
28/09/2008 08:36:34 mDNSResponder[16] mDNSPlatformRawTime: last_mach_absolute_time F762D3B2000046DF 
28/09/2008 08:36:34 mDNSResponder[16] mDNSPlatformRawTime: this_mach_absolute_time F74A62BD000046DF 
28/09/2008 08:36:34 mDNSResponder[16] mDNSPlatformRawTime went backwards by 1 ticks; setting correction factor to -1474660744

 

which makes me think that there is still a timing issue between the cores. The 'backwards by x ticks' normally is a sign that the system is becoming unstable.

 

There's quite a few of us dual core owners who suffer from the 'bug' and would love to get this long standing problem fixed. This certainly looks like our chance

 

Send me a PM or come over to infinitemac if you want help with any testing!

CPUID_Log.txt

[mercurysquad]

Seems we're in luck because if it's tsc related - I know this part of the kernel pretty well, so I can definitely help investigate it further. At the moment something else is taking my time so the beta will not be out until around Wednesday or so. After that during beta I plan to work on the nForce KP and this unstable tsc issue. I've gotten an account on infinitemac.com so will post there if/when I need testers.

[R0GUE]

I concur with Voyn1x's findings. My Athlon X2 6000+ suffers from the exact same symptoms after several hours uptime. It can sometimes happen a lot sooner if I'm working in Photoshop for example. It seems the more stress the CPU's are under, the quicker the timing goes out of sync.

 

Edit: Added cpuid log

CPUID_Log.txt

[moes]

EDIT: Exactly what I thought. I checked the specs for you and your CPU uses 100 MHz fsb, not 200. Boot up with busratio=28 and your problems will be solved. Refer to that wikipedia link to confirm.

 

Thank you........busratio=28!!!!.........working 100% now....

[hotcorez]

Hello Everyone,

 

Regarding the AMD CPU core sync bug, please read my post:-

 

http://forum.insanelymac.com/index.php?sho...17558&st=60

 

There are tons of links which should give you plenty of backgorund on the CPU bug which affect Opterons and X2's on socket 939. Not sure if they fixed the bug in AM2 chips.

 

Cheers,

 

HC

[mercurysquad]

Hmm, this page seems to describe Linux's solution for this problem. I'll incorporate this into voodoo beta and see how it goes. Beta should be out oct 1.

[nikoperugia]

hi. let me know if you need testing on a 3.06ghz p4 prescott on sis chipset. everything worked with previous releases and kernels.

[hotcorez]

Hello mercurysquad,

 

I'm glad that i could be of help. Their seem to be more links on the page whic explain the cause of the tsc drift.

 

http://developer.amd.com/documentation/art...1214200692.aspx

 

The article says it only affects the K8 socket of multi core processors (pub date 12/14/2006)

 

I hope they fixed this for their next generation products on AM2

 

I will be definately interested to see how you can apply this patch. I imagine you will need some kind of kernel flag to engage this feature.

 

I woud like to praise you for your work as it will help when apple starts selling AMD machines, amongst other things

 

Biggup

[mercurysquad]

I read all pages of the article. Actually what surprises me is that from a quick look at oui's tsc sync patch, it seems this should fix the issue on AMD as well. But apparently it needs a closer look. Yeah when rewriting the tsc_init function I did notice in AMD's family 10h and 11h docs (ie. phenom/shanghai) that the tsc in those CPUs are P/C-state invariant (like modern intel core cpus) so they shouldn't drift (the docs seem to imply the tsc is also automatically internally synced per-core - says "no software workaround" should be needed). So if any phenom user can verify that this issue doesn't affect them, that'd help steer us in the right direction.

 

As for how to implement it (ie, use kernel flag or not) - this kind of thing should be autodetected by any sane OS kernel, and so will voodoo. There will be a flag anyway if someone needs to force turn on/off.