Jump to content
InsanelyMac Forum


Retired Developers
  • Content count

  • Joined

  • Last visited

About mercurysquad

  • Rank
    InsanelyMac Sage

Contact Methods

  • Website URL

Profile Information

  • Gender
  • Location
  1. Not being able to connect to any network is a known problem. I'm working on it and hopefully very soon all these issues will be fixed, once the net80211 port is completed.
  2. ›› Voodoo XNU Kernel is now Released

    alpha 1 is up
  3. ›› Voodoo XNU Kernel is now Released

    Voodoo 2.0 for Intel alpha tests start Friday. Get your testing machines ready and update to 10.5.7 if you've not already done so. Yeah it's possible to download all the archives, put them in cache/ folder and the voodoobuild.sh will work. The site structure changed as you said, and it's great that no login id/pw are needed now!
  4. ›› Voodoo XNU Kernel is now Released

    Guys please keep an eye on http://code.google.com/p/xnu-dev/wiki/NewsArchive for updates. It's probably against the rules to post links to external sites on this forum, but just wanted to mention that I do not have time to post updates on every forum, so please check the official News Archive instead of cluttering this thread. Thanks
  5. ›› Voodoo XNU Kernel is now Released

    That's nice, but I've had disagreements about how Andy's "port" is made and he's been silent about all my concerns. So I cannot comment further on this. I'm aiming for a fresh/clean port from the ground up, and that requires more than a 3-way merge between the sources.
  6. GMA 900 and 10.5.7

    Working well for me. You need to use AppleIntelIntegratedFramebuffer.kext from 10.4.4. The 10.5.7 update overwrites it, and the elliott kext doesn't help with the framebuffer kext - only the 950 kexts.
  7. ›› Voodoo XNU Kernel is now Released

    Yes it will but showing correct cache info for this processor will NOT be fixed!
  8. ›› Voodoo XNU Kernel is now Released

    No, I have just been really busy with other stuff. 10.5.7 is here already though. I've resumed porting Voodoo to 10.5.7 now, it should be backported to 10.5.6 also. Let's see how long it takes to finish this. I'm trying for an alpha version by next week.
  9. There is an issue

    You should downgrade to 1.4.0 which is currently the latest stable version. It should fix your problem.
  10. How can I delete this kext using the Leopard CD?

    Two tips for people who might get into the same problem -- — Always load the kext manually from some regular location (not /S/L/E) using kextload, and make sure it works, before you install it in your Extensions folder. — If you do get stuck anyway, you can simply boot using -s option (single-user) and delete it. The kext does not load in single-user mode for precisely trouble-shooting reasons.
  11. AnV XNU Kernel V1.4

    It's because the Voodoo kernel installer changes your Boot.plist to boot voodoo by default. Just change it back to mach_kernel. Use bt(0,0)/mach_kerne.xnu (if I remember correctly). Use the uuid of your OS X install.
  12. You're a bit misguided, so I hope this info helps you rechannel your effort: The 2200 driver from iwidarwin does get recognized as 3rd party airport, because it derives from IO80211Controller. No mystery with that. Changing the devID made 3945 get recognized as that too. In the VERY early stages when I was writing the FakeAirport driver, I put in the dev ID of the firewire port so the kext would load up with a PCI device as its provider. It was recognized as 3rd party airport too. A FIREWIRE device. That kext had absolutely no code related to any wifi card in it either.
  13. I'm not looking for any contributors. iwidarwin source is open and is at a MUCH advanced stage. If people want to help, they should start with jalavoui's code. The guy ran a one-man-show for 3 effing years and no one really contributed anything significant. It's not respectful to recommend HIM to work with someone when it should be the other way round. Talk is cheap; show us the code.
  14. ›› Voodoo XNU Kernel is now Released

    Those crashes do not seem like they're because of TSC init code. It looks like your setup has other issues. The kernel should boot up without any bootflags even on VMware now. If it really doesn't, you should try busratio=145 for 14.5 (ie. omit the decimal). The FSB should be autodetected, but if you want to specify that as well, fsb=203000000. Lastly, to check that the kernel is reading the proper fsb, busratio and clock frequency, add a -tscpanic to the bootflags to induce an artificial panic with some debug info, and post.