Jump to content
Welcome to InsanelyMac.com - No more ads! And some exciting news... Read more... ×


  • Content Count

  • Joined

  • Last visited

About diamondsw

  • Rank
    InsanelyMac Protégé
  1. diamondsw

    10.6.3 Support for Atom again?

    Hey guys, figured I'd drop in here and make sure it shows up for folks searching. Updating to Mac OS X 10.6.3 on Atom-based netbooks: (think that will get Google's attention?) The kernel still does not support Atom processors. This can be remedied either by using a patched kernel or by loading the version of Chameleon included with NetBookInstaller 0.8.4rc1. The screen will black out on waking from sleep and trackpad will be nonfunctional. Both of these can be resolved by replacing the new AppleIntegratedFramebuffer (1.6.10 in 10.6.3) with the previous one (1.6.6 in 10.6.2). AppleSMBIOS has been updated to version 1.5. If you're using Andy Vandijck's excellent kext, you'll need to update the version number in its Info.plist to > 1.5. Be sure to use valid version numbers of the form x.y.z or the kext won't load (always run kextutil on it afterwards to check for any loading issues). And of course, update your SleepEnabler.kext to match your kernel version. NetBookInstaller's fork of Chameleon is a bit of a mixed bag. It adds support for the Atom and also 1024x600 video in Chameleon (no more stretched boot themes), but it's also forked from one of the earlier releases (e.g. no support for hiding partitions from the boot menu). You'll have to decide which is more "standard" - a forked Chameleon or a patched kernel. VFR_Pilot: Given how much changed between 10.6.2 and 10.6.3, I'd personally be a bit wary of continuing to use a 10.6.1 kernel, but if it's working I can't argue too hard against it. Just keep that in the back of your mind as a possible cause if you run into any problems.
  2. I'm trying to get to the point where my system properly halts/restarts, but using currently developed and "supported" extensions. What are other folks using? What I have today is simple and works: VoodooBattery from 1/7/2010 (version 1.0 (after all of those releases?)) VoodooPower from 5/28/2009 (version "©2008 Superhai") System details: Snow Leopard 10.6.2 Vanilla 10.6.2 kernel, with netkas's Atom binpatch All non-vanilla items in /Extra (com.apple.boot.plist, smbios.plist, Extensions, etc) All extra kernel extensions are in /Extra/Extensions, with some Apple ones copied in for dependency resolution. As you can see, it's a very vanilla setup. My questions: How have others solved the halt/shutdown problem, where shutdown completes but power is not cut, or the system does not restart? OpenHaltRestart worked in Leopard, and VoodooPower works today, but it's not supported. What exactly is it that's needed for many of these systems to halt/restart properly, and what current extension will provide it? OpenHaltRestart did, and the old VoodooPower did. As far as I can tell, the new kexts do not. Here's the background, if it's useful. Long ago before the Voodoo kexts, I used Psystar's OpenHaltRestart to allow proper power down and restart. Otherwise the system would finish shutting down, but never hand control back to the BIOS to cut power or reset. I switched to the Voodoo kexts as they were being maintained and provided better battery information than my old solutions. Today I was trying to move off of the old VoodooPower.kext, as I understand that was designed for Leopard only, and my only hope for having a vaguely supported system would be to move to one of the Snow Leopard kexts. Thus I started experimenting: VoodooBattery + VoodooPower + OpenHaltRestart = success VoodooBattery + VoodooPower = success VoodooBattery + OpenHaltRestart = cannot halt/restart successfully VoodooBattery = cannot halt/restart successfully VoodooBattery + VoodooPowerMini = kernel panic at boot VoodooPowerMini = kernel panic at boot VoodooBattery + VoodooPowerAcpi = cannot halt/restart successfully From this I've determined that: OpenHaltRestart is no longer functional, and removed it. VoodooBattery is required for any battery support (somewhat obvious). VoodooPowerACPI does nothing on my system. VoodooPowerMini kernel panics at boot. VoodooPower (5/28/2009) is the only one that allows my computer to halt/restart, and it's seemingly no longer supported. Something in addition to just VoodooBattery is required, or my system will not shut down. Whatever this code is, it was previously supplied by OpenHaltRestart, and is now supplied only by the obsolete VoodooPower. Vinnie881 reported this same issue.
  3. diamondsw

    Asus Eee 901 - Card Reader supported

    FYI, you can remove the question mark. It works just fine. About the only issue is it wakes up from sleep slightly late for OS X's taste, causing the Mac to briefly complain about an improperly ejected device. Personally, I wish Apple would just handle drive hotplugging better. It's a pain to eject USB keys and flash cards before pulling them out. Also, feel free to pull from my blog on setting up Mac OS X on the Eee 901. I currently have 10.6.2 running perfectly with a Chameleon, /Extra, vanilla setup.
  4. diamondsw

    10.5.8 deep sleep problem?

    Odd - SleepEnabler shouldn't do anything in that setup - and yet, when i tried AppleCPUIPM on my machine it locked immediately on the gray Apple. Still, whatever works.
  5. diamondsw

    10.5.8 deep sleep problem?

    Because they don't as far as I can tell. VoodooPower provides SpeedStep and other power management routines that would normally be provided by AppleIntelCPUPowerManagement; SleepEnabler prevents hangs when trying to go to sleep, and OpenHaltRestart allows the computer to properly restart or shutdown rather than hanging with a dark screen. I'm especially curious why AppleIntelCPUPowerManagement suddenly worked properly on 10.5.8 - and then quit working afterwards (and now we need SleepEnabler, etc). It would seem to me if a small patch or tweak could be applied to simply use the Apple-provided power management that this would be much easier than reinventing the wheel in four other kexts. I don't have much background on the issues involved - I'd just like the system to be easier to maintain, and the fragility of SleepEnabler in particular worries me.
  6. diamondsw

    10.5.8 deep sleep problem?

    This fix worked great for me - but only once I noticed to grab the Snow Leopard one instead of the Leopard one. Pardon my ignorance, but isn't there a better solution for power/sleep/restart/shutdown management than we have now? On my system I have the following: Disabler.kext OpenHaltRestart.kext SleepEnabler.kext VoodooPower.kext VoodooBattery.kext The more kexts are installed, to me the more things that can go wrong - or fall out of support and development. What worries me most though, is how SleepEnabler has to be so tightly tied to the kernel - that just can't be good long term, and wasn't required before 10.5.8. It's going to make applying OS updates very tricky indeed. What's strange is that on 10.5.8 - and 10.5.8 only - I could use Apple's power management kext without issue - no Disabler, OpenHaltRestart, or SleepEnabler, and everything worked perfectly. I was quite sad to see Snow Leopard required them all again. Please don't mistake this for not being appreciative! I'm deeply thankful for all of the work various folks have put into this; I'm just wondering if some of this can't be cleaned up and consolidated.
  7. Just your standard "Me too!" post. So far the Google Tech Database has failed me. I'm thinking it traces back to SMBIOS issues, as none of the custom SMBIOS kexts (whether patched Apple or separate ones like SMBIOSEFI) work under 10.5.7. So far no luck with SMBIOS.plist's either.
  8. It may not be the kext - my Mac Mini also kernel panics regularly when downloading torrents with Transmission or Azureus (seems like more with Transmission, but it may be my imagination). I don't know that it's the bandwidth either - seems more like the number of connections triggers it.
  9. Odd, I had this working on my Eee 901 under 10.5.6, but it's not working under 10.5.7. Even more disturbing is my lspci no longer shows the same info it used to - now it's: 04:00.0 Ethernet controller: Attansic Technology Corp. Unknown device 1026 (rev b0) Any ideas?
  10. diamondsw

    iDeneb 1.4 (10.5.6) issues

    tldr Seriously, someone must have run into the sleep and bootloader issues.
  11. diamondsw

    Modified boot-132 Bootloader

    (I apologize for not reading the whole thread, but I get the feeling a fair amount has changed over time, especially as it relates to the bootloader.) Currently I have an iDeneb system running with a vanilla kernel and a vanilla Boot.plist, and using Chameleon 1.0.12 and a patched DSDT. I'd like to move to a cleaner, more easily supported Boot-132 system. I've identified the various kernel extensions I need (both from experience and from essentially running a diff between my hackintosh and a real Mac) and created a working Boot-132 ISO for my hardware (damn, but that "hit ESC twice" thing tripped me up as well). The kexts are as follows: AppleACPIBatteryManager.kext AppleACPIPS2Nub.kext AppleIntelGMA950.kext AppleIntelIntegratedFramebuffer.kext AppleIntelPIIXATA.kext ApplePS2Controller.kext AppleSMBIOS.kext ClamshellDisplay.kext dsmos.kext IntelCPUPMDisabler.kext lspcidrv.kext OpenHaltRestart.kext RealtekR1000.kext SMBIOSEnabler.kext Although I have yet to actually install Leopard (that comes tomorrow when my new SSD arrives), I assume that much will work fine. My big question is this - given the support present in Chameleon 1.0.12 and my very vanilla system, can I simply do the following? Boot from Boot-132 CD; install Leopard from retail DVD Copy my Extensions.mkext from the ISO to /Extra/Extensions Create my DSDT patch Install Chameleon 1.0.12 Install Mac OS X 10.5.6 Combo Is that it? Really? I also assume that I can migrate to the EFI partition when support is built into Chameleon for using files located there.
  12. diamondsw

    10.5.6 Released!

    And you want to mention where the latest version is?
  13. diamondsw

    10.5.6 Released!

    Having a VERY bad time over here. I went off and foolishly updated without checking here first (given how painless the 10.5.5 update was), and things aren't looking good. I did not apply any updates to Chameleon (or the new PC_EFI), but my BIOS has been patched previously for the DSDT issues. I'm on an Asus Eee 901, which all but requires those updates. On first boot post-update the following problems were present: - Non-accelerated, 800x600 video only - Keyboard/Mouse is not recognized Attempting to reinstall the video drivers from my 10.5.5 install (AppleIntelIntegratedFramebuffer and AppleIntelGMA950) caused it to hang on the blue screen prior to login. Thank goodness for SSH, so I could reinstall the backup kexts and get back in. Also thank goodness for VNC, or I'd have no keyboard and mouse! Attempting to reinstall ApplePS2Controller.kext did nothing. So... do these sound like familiar problems to the community here? Some really basic noobish thing I'm missing? EDIT: Even worse! Tried to create the DSDT patch (fine) and install the new PC_EFI_v9 boot file (fine), and on reboot, it freezes at the spinny wheel. Dead as a doornail.
  14. diamondsw

    Looking for Taruga and SkippyRetard

    Assuming Taruga's wiki comes back up, someone please make a dump of its contents. It would be a shame to lose all of that information forever (and I've seen it happen FAR too many times). Personally, I'm just hoping to one day get my ALC269 to work. HDAPatcher rejects the codec dump as unsupported.
  15. In a nutshell, Psystar is going to have a hell of an uphill battle here. Apple makes the software, they determine how you use it. Pretty much every piece of software has a EULA, even if all it says is don't use this in critical scenarios (air traffic control, nuclear plants) and limitation of liability. Meanwhile, Psystar blatantly breaks the EULA before challenging it in court, takes the work done here without any attribution or permission, and we're supposed to go "rah rah"? I don't think so.