Voodoo Kernel BETA 2 - Available now

[beckend]

Man at last the mouse timing issue seems to be fixed, however kernel freezez from time to time, don't really know the reason thou, for example watching a movie can cause 1 second stutter every 30 mins or so.

 

Booting with -v -fsb=2483000000 busratio=125 (=3103.75 mhz), exact as windows

Booting without the flags causes a nightmare =P

RIG: AMD x2 5000+ BE, nforce 560+630a AHCI mode,8800gt 512 EFI, Leo4all@10.5.5

[bartolomiew]

Hi,

 

I'm testing this new kernel on a good old Dell Optiplex GX 260, it use a pentium 4 family 15 model 2.

 

kernel flag like this : busratiopath=0 => kernel panic

kernel flag like this : busratiopath=6 => works but doesn't detect real fsb, it see 100Mhz

kernel flag like this : busratiopath=0 fsb=133300000 busratio=19 => works fine, all tests passed except resume but I don't care about. Just a really annoying bug, random freeze random time using random software, any idea ?

[mercurysquad]

Man at last the mouse timing issue seems to be fixed, however kernel freezez from time to time, don't really know the reason thou, for example watching a movie can cause 1 second stutter every 30 mins or so.

 

Booting with -v -fsb=2483000000 busratio=125 (=3103.75 mhz), exact as windows

Booting without the flags causes a nightmare =P

RIG: AMD x2 5000+ BE, nforce 560+630a AHCI mode,8800gt 512 EFI, Leo4all@10.5.5

 

Is there an extra zero in your fsb?

 

Allrite, since no kernel supports 64bit with Amd yet may I ask what the main obstacle is preventing this ? 

Must be a pretty difficult one I suppose

No from what we know it's not one or two major things but several little differences between Intel and AMD 64bit support. I think it just needs some time to really sit down and get cracking at it, but I decided it was just not worth it. Might help with SnowLeopard but for now it's not worth the hassle to get amd64 working. One of the issues was that not all athlons support SYSCALL op, and we had this idea of emulating it like sse3. But it would be slow. And the primary goal of running 64bit is that it is faster. So what is the point of basically emulating 64bit and make it run slower than 32bit?

 

So let me say this again: for now there is no particular advantage in running 32bit. But we'll still be working on trying to make it work 'properly'. No promises.

 

Hi,

 

I'm testing this new kernel on a good old Dell Optiplex GX 260, it use a pentium 4 family 15 model 2.

 

kernel flag like this : busratiopath=0 => kernel panic

kernel flag like this : busratiopath=6 => works but doesn't detect real fsb, it see 100Mhz

kernel flag like this : busratiopath=0 fsb=133300000 busratio=19 => works fine, all tests passed except resume but I don't care about. Just a really annoying bug, random freeze random time using random software, any idea ?

 

Bootloader bug. Might be fixed in next Chameleon release. For now you gotta use the bootflags then. Also, don't put busratiopath=0 if you are already putting fsb and busratio.

[L0co]

working on voodoo beta_2c aprox 5 days - all works fine - greate! (AMD X2 5000 + Asus m3a)

but i have just installed adobe cs4 and all applications crash with same problem:

 

Process: Adobe Photoshop CS4 [9272]

Path: /Applications/Adobe Photoshop CS4/Adobe Photoshop CS4.app/Contents/MacOS/Adobe Photoshop CS4

Identifier: com.adobe.Photoshop

Version: 11.0 (11.0x20080919 [20080919.r.488 2008/09/19:02:00:00 cutoff; r branch]) (11.0)

Code Type: X86 (Native)

Parent Process: launchd [111]

 

Date/Time: 2008-10-21 23:13:45.698 +0300

OS Version: Mac OS X 10.5.5 (9F33)

Report Version: 6

 

Exception Type: EXC_BAD_ACCESS (SIGSEGV)

Exception Codes: KERN_INVALID_ADDRESS at 0x00000000b5b5b5b5

Crashed Thread: Unknown

 

Is there a problem with kernel?

[mercurysquad]

Perhaps. There have been fixes in beta3 which might fix this.

For now, try to boot with bootflag patcher_opts=0, or on a running system, type in terminal: sudo sysctl -w hw.optional.patcher_opts=0 before starting CS4. See if that helps.

[BartNijland]

Great kernel Runs very stable on my AMD 6000+

 

Only VMWare doesn't work. When you try to boot an OS, the system freezes.

 

But hey, what are beta's for;)

 

Great work!

[jonatasmz]

hey guys,, i´m geting a lot of kernel panics... i need to remove appleefiruntime.kext? and how can i do this?

 

i´m using ideneb 10.5.5 right now..

 

cya

[Dxn]

One of the issues was that not all athlons support SYSCALL op

 

How hard would it be to enable AMD64 support for chips that DO support SYSCALL?

 

Also, I'm experiencing an interesting phenomena: as an AMD user, there is no 64-bit support enabled in the OS as far as I can tell (my install didn't come with chess, but the hardware flags indicate that there is no support). However, when I stress my system, I've seen Leopard use as much as 6.5Gb out of the 8Gb of RAM I have installed. My understanding was that without 64-bit support, it could only utilize 4Gb of address space. Furthermore, I was encountering kernel panics due to my chipset kext because it was using the 32-bit getPhysicalSegment() function while trying to access 64-bit address space when loading large files into RAM (solved by using a kext that called a 64-bit compatible function).

 

If there is no 64-bit support on AMD, why would it seem as though Leopard thinks it's running in 64-bit mode?

[beckend]

sorry it was a typo, of course its 248300000

[mercurysquad]

Great kernel Runs very stable on my AMD 6000+

 

Only VMWare doesn't work. When you try to boot an OS, the system freezes.

 

But hey, what are beta's for;)

 

Great work!

 

This is a VMWare bug - the kernel MUST be named /mach_kernel for it to work.

 

No more vmware bug reports please unless you are having problems WITH the kernel as /mach_kernel

Sorry to sound like an ****** but I've answered this 50 times

 

sorry it was a typo, of course its 248300000

 

Another frequent one. You probably see ~262.5 MHz reported as fsb freq by the bootloader.

AMD Athlon users who have non-integer cpu multiplier: This is a bootloader bug (Chameleon). Chameleon devs have fixed this, waiting on them to make a release.

 

Actually the Voodoo kernel changes some fundamental things in how the kernel was patched, and so exposes a few critical bugs in parts which the kernel depends on (like bootloader). This was never an issue with ToH or other kernels because they used different methods and didn't depend so much on the bootloader (that's part of the reason there is no NON-EFI voodoo kernel. Supporting legacy hardware is enough of a hassle so we're not supporting legacy software too since they're easily upgradable).

 

How hard would it be to enable AMD64 support for chips that DO support SYSCALL?

 

Also, I'm experiencing an interesting phenomena: as an AMD user, there is no 64-bit support enabled in the OS as far as I can tell (my install didn't come with chess, but the hardware flags indicate that there is no support). However, when I stress my system, I've seen Leopard use as much as 6.5Gb out of the 8Gb of RAM I have installed. My understanding was that without 64-bit support, it could only utilize 4Gb of address space. Furthermore, I was encountering kernel panics due to my chipset kext because it was using the 32-bit getPhysicalSegment() function while trying to access 64-bit address space when loading large files into RAM (solved by using a kext that called a 64-bit compatible function).

 

If there is no 64-bit support on AMD, why would it seem as though Leopard thinks it's running in 64-bit mode?

 

This requires a detailed explanation, but in short:

1) On CPUs with SYSCALL, the behaviour of AMD is a bit different. As I said we have not looked into it in detail, but it *still doesn't work* on those cpus either.

 

2) You don't need full 64bit to access >4GB memory. PAE (physical addressing extension) allows you to use >4GB. Most CPUs have 36 bits, 40 bits or even 48 bits PAE. Infact the kernel is totally 32bit even in "64 bit mode", it just allows 64bit apps to run and provides them kernel services, and the memory manager is able to use PAE to access more than 4gb memory (plus other stuff like NX bit support).

 

3) The kext problem, to simplify the explanation: This is because traditionally PCI memory was wrapped back from the 4GB area. Now with >4GB, there must be either a "hole" or if the memory is flat, you need to use virtual addresses in case the pci memory is mapped to some other place in recent versions of OS X (like wrapped back from the real end of memory). It's similar to the 1MB hole that exists because BIOS calls were mapped there back when 640k was enough for just anybody. Here is some information about this from a very well known developer of top-notch operating systems (scroll down).

 

4) Leopard doesn't think it's running in 64bit mode, as I said the kernel always runs in 32bit mode - it's a 32bit binary.

[BartNijland]

This is a VMWare bug - the kernel MUST be named /mach_kernel for it to work.

 

Ah okay. Then this kernel is very stable for me, can't wait for final too use it full-time.

[beckend]

"You probably see ~262.5 MHz reported as fsb freq by the bootloader."

Where do i see this? Cause i see it clearly after booting it says 248,3 fsb and 3103 mhz and multiplier of 12,5, which is my real bios settings, and this bootloader bug you're speaking of, what bad effects does it have?

[Dxn]

2) You don't need full 64bit to access >4GB memory. PAE (physical addressing extension) allows you to use >4GB. Most CPUs have 36 bits, 40 bits or even 48 bits PAE. Infact the kernel is totally 32bit even in "64 bit mode", it just allows 64bit apps to run and provides them kernel services, and the memory manager is able to use PAE to access more than 4gb memory (plus other stuff like NX bit support).

 

Ah, good to know. Coming from windows, where you need a 64-bit OS for windows to use more than 3Gb of RAM, I didn't realize that leopard worked that way.

[mercurysquad]

"You probably see ~262.5 MHz reported as fsb freq by the bootloader."

Where do i see this? Cause i see it clearly after booting it says 248,3 fsb and 3103 mhz and multiplier of 12,5, which is my real bios settings, and this bootloader bug you're speaking of, what bad effects does it have?

Boot with -v -tscpanic to check the busFreq. (disregard multiplier=1).

[General_Cartman]

Firstly I wanna say that this kernel is by far the best non-vanilla kernel I have ever used. Using it on the AMD machine in my sig, and it is totally stable, and faster than the ToH kernels I used before. Sleep isn't functioning but that is no biggy.

 

I tried using this kernel on my friends Hackintosh with a Asrock 775DUAL-VSTA. When i do the TSC stablilty test, it gets the FSB right but says it can't initilise the RTC as it can't get the multiplier and suggests I use a boot flag or upgrade chameleon (which I have done). The CPU is a core 2 duo E4300 which has a multi of 9. However when I use busratio=9, or busratio=09 or busratio=90 (i'm kinda confused as to which one to use hahaha) it still can't detect the multi. Is this going to be a problem? The system still keeps perfect time, so is there anything else this lack or RTC will affect. Also, is there something stupid I have missed when I enter the boot flag?

 

Thanks for an awesome kernel, keep up the good work!

[NickRiley]

Test 1 Passed: [_] Yes [X] No [_] With issues

Tried to put my computer on Sleep, couldn’t get it up back. Rebooted

Test 2 Passed: [X] Yes [_] No [_] With issues

Test 3 Passed: [X] Yes [_] No [_] With issues

Test 4 Passed: [X] Yes [_] No [_] With issues

Test 5 Passed: [X] Yes [_] No [_] With issues

Test 7 Passed: [X] Yes [_] No [_] With issues

• Well the first thing I noticed is that I can run SPORE at last now I can play it at highest settings thanks a lot for the kernel..
  
• Increased Xbench results with 4%
  
• At last I got rid of mouse/sound issue which were appearing after 2-3 hours of using the computer
  

The kernel seems to be very stable.. the most stable from those i tried earlier, but i still have an annoying problem with my USB, everything that i'm trying to connect to it (my iPhone, USB flash drive, card reader) won't be visible unless i make a reboot, is there any solution to that? I think this is my only problem with the system, everything else works just perfect now

[L0co]

Perhaps. There have been fixes in beta3 which might fix this.

For now, try to boot with bootflag patcher_opts=0, or on a running system, type in terminal: sudo sysctl -w hw.optional.patcher_opts=0 before starting CS4. See if that helps.

 

unfortunately this trick doesn't help.(

waiting for beta3...

[mercurysquad]

unfortunately this trick doesn't help.(

waiting for beta3...

Does CS4 work on another kernel? If yes, which.

Also try to get a log of the crash report.

[Dabluest]

The kernel seems to be very stable.. the most stable from those i tried earlier, but i still have an annoying problem with my USB, everything that i'm trying to connect to it (my iPhone, USB flash drive, card reader) won't be visible unless i make a reboot, is there any solution to that? I think this is my only problem with the system, everything else works just perfect now

 

Your problem with mounting USB devices might be related to not having matching versions of the kernel and System.kext. Since this version of the Voodoo kernel is 9.5.0 you must also have version 9.5.0 System.kext or you may run into problems like you described.

 

To check your System.kext version go to: /System/Library/Extensions/. Right click on System.kext and select Get Info. If it doesn't say version 9.5.0, then download the correct System.kext here.

 

If that doesn't fix the problem, then check out this guide for a possible solution.

 

Good luck

[L0co]

Does CS4 work on another kernel? If yes, which.

Also try to get a log of the crash report.

on stage 9.4.0 i have the same problem

May be the problem in my LawlessPPC version of Mac... tomorrow i'll try on iDeneb with this two kernel (stage and voodoo) and report...

 

Whatever crash_log attached...

crash_log.rtf

[Nick14]

Does this support Hyperthreading ??

[NickRiley]

Your problem with mounting USB devices might be related to not having matching versions of the kernel and System.kext. Since this version of the Voodoo kernel is 9.5.0 you must also have version 9.5.0 System.kext or you may run into problems like you described.

 

To check your System.kext version go to: /System/Library/Extensions/. Right click on System.kext and select Get Info. If it doesn't say version 9.5.0, then download the correct System.kext here.

 

If that doesn't fix the problem, then check out this guide for a possible solution.

 

Good luck

 

Thanks a lot it helped..

[mercurysquad]

on stage 9.4.0 i have the same problem

Well obviously in that case it's not prudent to report it as a kernel bug..

 

 

For other testers, here's a lecture

 

As I've mentioned before, beta test doesn't mean 'zomg it dont work i gotta report this' -- as a beta tester it's your job to do this sort of screening/triage before sending us a bug report. Our job is to then take it from there and fix it. I shouldn't have to say "attach a crash report" as it's fairly obvious that without it there is absolutely nothing we can do. I shouldn't have to repeat "boot with -v -tscpanic" if I have documented the process once. Or keep asking "do you have an athlon with non-integer bus ratio?" And so on..

 

You really need to do independent trouble-shooting and research, and once you're sure the kernel is the problem, then report it. Beta testing doesn't mean we are offering tech support It's the opposite: It means you as a tester are offering to take on some of the troubleshooting work.

 

So here's for starters: The typical process I have seen so far for sleep related testing is thus: Tester tries to sleep and then resume. It doesn't wake up. Tester reports it as a bug.

 

Wrong.

 

What you should do instead, is boot into safe mode ( -x ) and then try sleep/resume. If it doesn't work, try BIOS settings or read up on the forums. If it did, then try loading the kexts you need one by one (check which of your hardware devices isn't working, and load its kext, or check a diff of kextstat output from your regular bootup and the safe mode bootup). Try resuming after each new loaded kext. At one point you will find which kext is causing your system to not wake up. And then, regardless of whether it worked out or not, you will invariably test the same thing on another non-voodoo kernel, and preferably an older voodoo beta too, so we can cross-check and verify that indeed this is a regression in the latest voodoo beta.

 

This was just an example. Please try to be smart beta testers. It is very possible that we'll have to have a closed beta3 if we don't stop getting "timing error" bug reports without following TSC debug procedure, or sleep/resume error without following the above process. Or VMware error when your kernel is not /mach_kernel, or other problems from users who later say it never really worked for them before either. If you think all this is too much hassle, or that you just don't know enough about OS X or the kernel's inner workings to be able to troubleshoot on your own -- then it is best you DON'T try to test the beta at all, because spurious reports will only confuse us more.

 

Also a quick note: Go through the ENTIRE bug list (use search option) and check if your or a similar bug has not already been reported. Right now we are a small project, we have only about 60 reports so far, so it's not a big deal. But more than half of them are more tech support requests than bug reports, which kinda defeats the purpose of an open beta.

 

Cheers.

[L0co]

Well obviously in that case it's not prudent to report it as a kernel bug..

For other testers, here's a lecture

...

 

I'm sorry for this ungrounded bugreport, next time I'll be consideratly..)

[mercurysquad]

I'm sorry for this ungrounded bugreport, next time I'll be consideratly..)

Hey the forum is meant for discussion so it's no problem at all. I was talking about bug reports others have posted on google code.