Jump to content
325 posts in this topic

Recommended Posts

Sorry, allow me to clarify.

 

System originally installed from Leo4Allv3 which uses Dense's EFI installation script by default. It may be a bit of a misnomer, but "standard" being in the context of the installation medium.

Working on a hunch, that in that OSX86 Tools most recent version didn't work when trying to install Chameleon on my set up but the older version worked perfectly, I decided to go back to using good ol' kexthelper. That is not to say there is anything wrong with the wonderful OSX86 Tools but some people have reported problems and error messages beyond the Chameleon problem and pcwiz got them to revert to the older version. What I especially like about it is that you can be in one working partition and install kexts to another from there. I firstly deleted your kernel from root, then replaced it. Then I carefully deleted and reinstalled all of the kexts you advise be installed. On reboot, the problem was still there but, after repairing permissions and rebooting... everything was fine! I haven't tried sleep but sleep never worked on that laptop. Could it, then, be something as simple as making sure you have Chameleon installed before installing anything else, that installing Chameleon post installing kernel and kexts is a bad move? I need to read through all of the threads. I will try another clean install before the weekend and let you know how it goes. I will image it before installing anything else and use that image as a tester.

 

Meantime, thanking you guys :-)

did this start on another kernel???? Because to me the sigsegv error means that the program needs it cpuid's patching. Which soon this kernel will do on the fly

unfortunately no...

after patching with Marvin or AMD Patcher - having no results

on Zephyroth 10.5.2 rev.1 -> updated to 10.5.5 with voodoo kernel Photoshop starts w/o any patching... but just only Photoshop from all CS4 design premium.)

With over three days running, system is still stable as day one.

 

After getting used to not being able to sleep my system, this kernel reminds me how quiet my nights can be. Sleep/wake is definitely something easily taken for granted.

Beta is fairly close. AMD CPUID patching is working with nearly all applications. AMD64 bit issues being worked on and hopefully will be resolved soon. Mercurysquad also has to finalise up the CPU issues that are outstanding.

So, for my understanding, the most of Mercurysquad & Teams hard work is for AMD?!

I dont know if its really an good time investion, because some things which may be a problem even for

Intel C2D users are upcoming at least with 10.6.

I would prefer more Teamwork on EFI V9, NATIT, chameleon, DSDT (ACPI-Table patch (cpu=1 problem) on the fly patch), ATI+NV drivers..

I like your work but at least for desktop users it may be much easier to switch from AMD Board to Intel to avoid most of those AMD special kernel work. Dont undertsand me wrong - i am also glad for you AMD users but the freetime of dev Mercurysquad & Co should NOT be hold by 95% AMD fixes.

freetime of dev Mercurysquad & Co should NOT be hold by 95% AMD fixes.

 

Yes, you're right! You should get to decide what they get to work on and what they don't. :rolleyes:

 

Nevermind what they find interesting or what benefits the community as a whole... :D

 

 

BTW to everyone working on Voodoo, amazing job so far, and having a kernel that makes what cpu is in use irrelevant is one of the coolest features of this kernel and I'm pretty sure more people are excited about it than not.

Yes, you're right! You should get to decide what they get to work on and what they don't. ;)

Nevermind what they find interesting or what benefits the community as a whole... ;)

BTW to everyone working on Voodoo, amazing job so far, and having a kernel that makes what cpu is in use irrelevant is one of the coolest features of this kernel and I'm pretty sure more people are excited about it than not.

Sure, its great work also for AMD users (P4 too) and its needed also - that not my "problem".

I fear only a bit that they run in an "dead end" :huh: in AMD kernel dev deepness.

I hope really for AMD Fans that they get it also for AMD to work - no question about that.

So, for my understanding, the most of Mercurysquad & Teams hard work is for AMD?!

I dont know if its really an good time investion, because some things which may be a problem even for

Intel C2D users are upcoming at least with 10.6.

I would prefer more Teamwork on EFI V9, NATIT, chameleon, DSDT (ACPI-Table patch (cpu=1 problem) on the fly patch), ATI+NV drivers..

I like your work but at least for desktop users it may be much easier to switch from AMD Board to Intel to avoid most of those AMD special kernel work. Dont undertsand me wrong - i am also glad for you AMD users but the freetime of dev Mercurysquad & Co should NOT be hold by 95% AMD fixes.

 

Not everyone deals with the same areas. Bootloader guys don't really work on the kernel at all. So its not about working on specific areas, people do what they can for the expertise they have. The group working on this stuff isn't even that large. Its really been 3 people working on the kernel (i've tried to help coordinate and created an automated build scripts). There are 3 also working on the bootloader. 2 people working on kexts. We'd love to have more experience peopled but its very hard to add people to the group that have the experise necessary to do this stuff. Please people need breaks, they can't dedicated months to doing the same thing. We want this working just as much as you guys do (which is why we started it in the first place).

I appreciate that a small minority of Intel users do not appreciate the work being done to support other cpu's such as AMD.

 

However, you must realise that by supporting just one company you will end up with a monopoly, i.e Intel, which bascially owns PC's ATM.

 

As far as i can see, we are lucky to have anyone doing anything for us, so don't forget that.

 

Also how dare you try and stop the advancement to support others. This is extremely selfish.

 

Just out of intrest, which bugs are you waiting to be fixed? As far as i can see this thing is 99% there for intel users already.

 

Have a good weekend everyone! ;)

So, for my understanding, the most of Mercurysquad & Teams hard work is for AMD?!

I dont know if its really an good time investion, because some things which may be a problem even for

Intel C2D users are upcoming at least with 10.6.

I would prefer more Teamwork on EFI V9, NATIT, chameleon, DSDT (ACPI-Table patch (cpu=1 problem) on the fly patch), ATI+NV drivers..

I like your work but at least for desktop users it may be much easier to switch from AMD Board to Intel to avoid most of those AMD special kernel work. Dont undertsand me wrong - i am also glad for you AMD users but the freetime of dev Mercurysquad & Co should NOT be hold by 95% AMD fixes.

mitch_de and others:

 

It's great to hear suggestions on what we should work on, keep 'em coming. You're right, one might hit a dead-end going too deep into one area when other areas are ignored.

 

Now our rationale for the AMD focus: Intel work has been easy. The majority of the intel support comes from SSE3 emulator, and some cache/tsc code for family 15 and other intel CPUs. That's about it. When we announced AMD cpuid patching in the insanelymac article, we expected it to be ready for release in a few days. It turned out to be a bit more complicated. However, we had already decided on the checklist for final release, and didn't want to back out on it. Unlike most other open-source projects, I believe in a little bit more quality control because I've learnt from working on commercial projects that a little more formalized development is much better than the chaos-inducing linux/gpl-like development. This is also why despite being touted as an 'opensource' project, we've kept the source still closed and won't release it until the kernel is ready. We don't want chaos - we have a group of core developers who know what they're doing, and just need time to finish what we started. Since we had decided on features X,Y,Z - we have to finish X Y and Z (and not add feature W!) before final release. This is why AMD has been a focus after beta1. It is quite simply the most involved part which hadn't seen much love before, plus we have effectively ONE coder working on it, with support from 2 other people. It takes time.

 

I hope that is a satisfactory explanation. See the initial motivation came from giving better pentium M (and other non SSE3 cpu) support. Now that it's done, the focus has shifted. Once AMD is done, the focus will shift to other things too. But it is important that this kernel be truly universal so this is really the baseline.

 

Keep the discussion going though. Inputs are welcome!

@ "for desktop users it may be much easier to switch from AMD Board to Intel"

 

As a long-time AMD user, I'm not ready to spend hundreds of dollars converting to an Intel system. I'm extremely grateful to the entire Voodoo dev team for creating a kernel, which by its second beta has made leo as stable as vista for me. This has allowed me to really put leo through its paces.

 

Thank you to everyone who has worked on this!

After the kernel is done what will you aim at then ?

can't say about the entire team, but me personally: Writing drivers. Specially wireless and (maybe) audio, or enabler/injector-like mini kexts.

Perhaps work on bootloader also.

There's a ton of stuff we can still add to the kernel though so that's not gonna be 'done' for a while :rolleyes:

I wouldnt even read posts from people bashing work for AMD based machines, there should be some universal love here. I have the Intel based mach in my sig that was a move from a AMD based hack (that was cheaper to build than this one) just because of the lack of AMD support. My main rig is a AMD machine too, waiting on better support before i try to OSx86 it again. Your kernel did alot of good things for my Atom machine, gave me back my restart and sleep not to mention everything feels a bit more snappy. Keep up the good work and cant wait to see what else you guys come up with.

not to mention that the opcode patcher is the same that is used for sse3 emulation, every advancement benefits both tasks. also, the TSC code is usefull also on some intels with crappy bioses(DELLs for example).

×
×
  • Create New...