Jump to content

›› Voodoo XNU Kernel is now Released


mercurysquad
 Share

Voodoo kernel release  

1,280 members have voted

  1. 1. Has Voodoo kernel been working well for you?

    • Yes
      1067
    • No
      213
  2. 2. On which processor do you use this kernel?

    • Intel
      850
    • AMD
      454
  3. 3. Did you use the installer or installed manually?

    • Manually
      397
    • Installer, worked well
      783
    • Installer, but didn't work well
      100


561 posts in this topic

Recommended Posts

I got some freezes on AMD3000 sse3 + msi platinum sli ms7100 mobo on iAtkos 5i full intel system + voodoo 1.0 kernel running on pcefi9. System was fine with iAtkos 4a 10.5.4 amd decrypted system. I dunno if it is related to 10.5.5 system or the voodoo kernel.

Link to comment
Share on other sites

Hi everybody, i've updated my hackintosh to 10.5.5 with Mysticus methode and everythings seems to work, i've had chosen 9.4.0 StageXNU because i can't use vanilla kernel (reboot loops).

 

After i've tested this Voodoo kernel in final release and i have some problems. i've installed with the installer and after reboot and i want to watch a movie with vlc i have sound but not video, ishowu freezes also (no image), so i think it's a video kind of problem too.

 

I've reed documentation and there is nothing in the knowing issues section. I've reed this topic and i didn't see this problem appears neither. So i've would like to know if someone knows what should i do to make it works. And if i need to post some further information also.

 

Thanks

Link to comment
Share on other sites

i have heard non integer values do not work until a new boot loader is released.

Not true anymore. No bootloader upgrade is needed for any CPU. Only Intel Core i7 needs busratio= bootflag.

 

i've installed with the installer and after reboot and i want to watch a movie with vlc i have sound but not video, ishowu freezes also (no image), so i think it's a video kind of problem too.

I recommend you start with the Hardware & Drivers > Graphics section of the forums for troubleshooting video issues. Most likely your graphic card drivers are not properly set up.

 

I copy things or load something from disk the response is very slow. In 5.5 i didn't have any probs like this. May it be possible that my ATA-Kext isn't that fine for 5.6? May it be because of the old 5.5 Kernel?

Most likely it's an incompatibility with the kext instead of the kernel. Check the Hardware/Drivers section of the forum for help with troubleshooting - people there might know more about your issue. If after troubleshooting you have narrowed it down to the kernel, we'll look into it.

Link to comment
Share on other sites

Well I installed the kernel and under 10.5.5 it was perfect. Once I upgraded to 10.5.6, still good minus one thing:

 

I can no longer mount disk images, I get a kernel panic every time. Any ideas? (This is on both AMD and Intel machines, one Core 2 Duo, the others AMD 64x2s and two Pentium 4s (with native SSE3)...)

Link to comment
Share on other sites

Well I installed the kernel and under 10.5.5 it was perfect. Once I upgraded to 10.5.6, still good minus one thing:

 

I can no longer mount disk images, I get a kernel panic every time. Any ideas? (This is on both AMD and Intel machines, one Core 2 Duo, the others AMD 64x2s and two Pentium 4s (with native SSE3)...)

 

Read a few posts above.

Link to comment
Share on other sites

Finally, this kernel is the only one that has had working speedstep for me, however sleep still doesn't work as it hangs immediately upon resume, without restarting any devices which implies a kernel problem of some sort rather than a kext incompatibility.

 

Unfortunately, since you don't seem to be accepting sleep bug reports anymore I doubt this will be fixed any time soon. :)

 

Still, excellent work guys! I wish I had the time you guys have to devote to kernel hacking. :P

Link to comment
Share on other sites

I recommend you start with the Hardware & Drivers > Graphics section of the forums for troubleshooting video issues. Most likely your graphic card drivers are not properly set up.

 

thanks for the answer, in fact i've installed in a second clone and now it works :unsure: i don't know what happens because i just did the same thing in a clone.

 

Anyways it's working, it's looks quite stable, thanks.

 

Next step 10.5.6. :)

Link to comment
Share on other sites

Guest cavallo

What about firewire video cams not recognized by imovie and other applications?

To me everything useless without that, why on g4 there are no problems?

Link to comment
Share on other sites

Ok.. I was having problems to get my external USB audio card (Edirol UA-700) recognized..

I thought to my self.."maybe you should use the 10.5.5 System.kext, you noob.."..

So i did and the card got recognized :P

Think there's a lesson to learn from this :) even though, i was only testing..

Link to comment
Share on other sites

this has been working fine, but i get a kernel panic whenver i try to install my hp network printer. it is a photosmart c5180 and i am running the current installer from hp.com. it works untinl it gets to the printer queue install.

Try doing it in legacy mode.

Link to comment
Share on other sites

well in 10.5.6 i am getting very often this kernel panic (if i boot with no flags):

 

panic (cpu 0 caller O*001B10AE):

"Local APCI error /n"@/voodoo kernel/xnu-1228.7.58/osfmk/i386/mp.c:809

Debbugger called:<panic>

Backtrace (cpu 0), Frame:Return Address (4 potential args on stack)

0*108f28 : 0*12b08c (0*45bcf0 0*108f5c 0*133119 0*0)

0*108f78 : 0*1b10ae (0*466934 0*3c8 0*0 0*0)

0*108f98 : 0*44a962 (0*db 0*27fd3ef0 0*739000 0*0)

0*27fd3f94 : 0*136312 (0*1 0*37e37d8 0*0 0*0)

0*27fd3d4 : 0*1a20b5 (0*37e24f0 0*37decc 0 0d3628c 0*27fd3fe0)

Backtrace terminated-invalid frame pointer 0

BSD process name corresponding to current threead: Unknown

MacOs Version:

Not yet set

Kernel version:

Darwin Kernel Version 9.5.0: Sat Dec 6 19:39:54 IST 2008; Voodoo: Release 1.0: xnu-1228.7.58/Build/obj/RELEASE_I386.

 

Help please ;)

 

EDIT: I've just clean the caches, hopelly this will fix it. If someone has a better idea i will appreciate.

Link to comment
Share on other sites

First big problems with this kernel:

I was running Azureus (Vuze) at full speed, trying to open MS Word 2008 when this happened:

t272581_DSC0017.jpg

 

I thought that it was just a nforce driver, I had this before when running torrent programs,

but today this happened, while I was only surfing with Safari:

t272585_DSC0021.jpg

 

 

Now i wasnt using any torrent program, but I still got kernel panic, this wasnt happening before. Thats why I'm confused...

 

Using Leo4all with this voodoo kernel, 10.5.5.

Amd X2 procesor, MBO with nf4 chipset, radeon 3850 VGA, and 4 Gb of memory.

Link to comment
Share on other sites

Are you guys running the kernel in 64bit mode?

 

In any case you can *clearly* see that the *kexts* are crashing, not the kernel. The first one is obviously getPhysicalSegmen() which is a 64bit / 4+GB related problem with older drivers which were coded for 32bit only and assume no memory 'hole' at 4GB. The 2nd one is again a crash with the ATI Radeon driver. Look at the EIP: value, it is within the memory range of the ATIRadeonX2000 driver which caused the page fault.

 

Thanks for reporting it though, one of the more descriptive bug reports. We'll keep a watch on this.

 

 

And to all bug reporters,

 

The Voodoo kernel has exposed a lot of bugs in other pieces of code because it does many things *correctly* instead of working around them, and many KPs are likely caused by one of those situations. There are some genuine crashes which happen within the kernel itself (like sporadic "Machine Check" exceptions on AMD and other systems or dyld related crashes). We are investigating all these issues, the only thing making the process slower is simply not being able to reproduce these problems (eg. none of us has an AMD system so we can't possibly reproduce these bugs except with help of our testers). And this makes the progress seem slow from the user's perspective. What the OSx86 community hackers took 3 years to reach, we wrote from scratch in 3 months (and then some). Needless to say there are bugs left in R1 which we are unaware of. Please bear with us while we try to fix every problem, and please do report in detail all the issues you are having. Just keep in mind that you should try to narrow down the problem to the kernel itself, and NOT the combination of the kernel and something else.

 

Enjoy the vacations :whistle:

 

well in 10.5.6 i am getting very often this kernel panic (if i boot with no flags):

 

panic (cpu 0 caller O*001B10AE):

"Local APCI error /n"@/voodoo kernel/xnu-1228.7.58/osfmk/i386/mp.c:809

Debbugger called:<panic>

 

I assume it meant Local APIC error - in which case it's not a bug or crash but simply the processor/motherboard hardware misbehaving and not acting as expected by the kernel. We'll check if we can have some workaround for it in the next release. Thanks

 

Here one of my dv cam recognized but not by imovie or others why?post-194988-1229704152_thumb.jpg

Does it work if you switch kernels?

Link to comment
Share on other sites

Guest cavallo
Are you guys running the kernel in 64bit mode?

 

In any case you can *clearly* see that the *kexts* are crashing, not the kernel. The first one is obviously getPhysicalSegmen() which is a 64bit / 4+GB related problem with older drivers which were coded for 32bit only and assume no memory 'hole' at 4GB. The 2nd one is again a crash with the ATI Radeon driver. Look at the EIP: value, it is within the memory range of the ATIRadeonX2000 driver which caused the page fault.

 

Thanks for reporting it though, one of the more descriptive bug reports. We'll keep a watch on this.

And to all bug reporters,

 

The Voodoo kernel has exposed a lot of bugs in other pieces of code because it does many things *correctly* instead of working around them, and many KPs are likely caused by one of those situations. There are some genuine crashes which happen within the kernel itself (like sporadic "Machine Check" exceptions on AMD and other systems or dyld related crashes). We are investigating all these issues, the only thing making the process slower is simply not being able to reproduce these problems (eg. none of us has an AMD system so we can't possibly reproduce these bugs except with help of our testers). And this makes the progress seem slow from the user's perspective. What the OSx86 community hackers took 3 years to reach, we wrote from scratch in 3 months (and then some). Needless to say there are bugs left in R1 which we are unaware of. Please bear with us while we try to fix every problem, and please do report in detail all the issues you are having. Just keep in mind that you should try to narrow down the problem to the kernel itself, and NOT the combination of the kernel and something else.

 

Enjoy the vacations :whistle:

I assume it meant Local APIC error - in which case it's not a bug or crash but simply the processor/motherboard hardware misbehaving and not acting as expected by the kernel. We'll check if we can have some workaround for it in the next release. Thanks

Does it work if you switch kernels?

No it doesn't.

It's not a kernel problem, it is a kext problem.

Since i installed 10.5.6 kexts and i switch pc on with switched on camera it works.

If i switch off/on camera during use it stops working, i need to reboot.

It is not in any case normal.

Link to comment
Share on other sites

Guest cavallo

The only problem now for me is, i don't know if it really is.

In system profiler ram is recognized just by value 1gb each but no bus, if i have it where i put id's?

Thank's again for kernel and patience

Link to comment
Share on other sites

My opinon, reading lastest news from voodoo (longer time for 10.5.6 kernel dev because lots changed and voodoo team hasnt AMD PCs):

Perhaps it will be better in the future to split the dev voodoo team in an AMD voodoo and Intel Voodoo !

Why:

I am sure that the Intel Non SS3 Voodoo dev time for any new kernel (like now 10.5.6) is much less than

doing an allinone (Intel/AMD Kernel).

Perhaps voodoo Intel coould be RC in end of january 2009, while AMD RC takes end of feb (or even later)!

So why should Intel users wait ?

Also perhaps side effects will be eliminated and easier to handle user reports here (2 threads , Intel voodoo, AMD voodoo)

And, last but not least an AMD voodoo team would have own AMD machines and for sure own interest to get it worked.

The teams helps each other, but beta, RC , Final are uploaded by each group when its finished.

If AMD Voodoo teams has RC same time : good, if not, no problem. Every dev team puts out their kernel as soon as

possible . no team would have to wait for each other.

Link to comment
Share on other sites

Perhaps it will be better in the future to split the dev voodoo team in an AMD voodoo and Intel Voodoo !

Why:

I am sure that the Intel Non SS3 Voodoo dev time for any new kernel (like now 10.5.6) is much less than

doing an allinone (Intel/AMD Kernel).

Intel dev time is half of that of AMD, which is correct. However, the main idea of Voodoo was to combine and unify all kernels and make one universal kernel. There will be only one Voodoo.

 

Now about the idea of making 2 teams: instead of that I invite the community to port parts of the kernel and submit patches instead!. Simply making 2 teams will not help at all. There are 2-4 people working on Voodoo and we already divide our work, each person handling the part they are best familiar with. And secondly, by dividing into teams we will not automatically get access to AMD (or other) machines. What we need is MORE people. The Voodoo source is available and so is 9.6 kernel source, but where are patch submissions? So far only Andy Vandijk submitted one patch for 9.5, and cosmo1t has ported tsc sync to 9.6 (thanks to both of you). We need more contributors.

 

So yes Intel users (which number about 2x of AMD users, according to this thread's polls) will unfortunately have to wait, but there isn't another option, at least for now. Given this logic, we should also have a separate Pentium M branch, which requires barely 2 changes in the vanilla kernel. Actually the total source diff against stock is only about 250 kB (around 7000 lines), which is not much if you compare with other larger projects.

 

Thanks for suggestions though. Keep em coming.

Link to comment
Share on other sites

 Share

×
×
  • Create New...