Asmedia USB 3.0 still a problem

Here is what I’ve concluded regarding the Asmedia USB 3.0 problem.

The NEC/Rensas USB 3.0 driver that is included in MultiBeast is causing the “shutdown” problem on the SH67H3/7.

So, we still need an Asmedia USB 3.0 driver for Mac, for all to work perfectly.

Right now, here are your choices:
1) Working USB 3.0 ports, with a shutdown problem
2) Don’t install the NEC/Renasas driver, no USB 3.0 ports working, but hackintosh shuts down properly

As I’ve stated before, I have access to the source code for the Linux Asmedia USB 3.0 driver, but need someone to convert it to Mac. If anyone has the ability to do this, please let us know, so we can all experience some JOY here.

32 Responses to Asmedia USB 3.0 still a problem

  1. John says:

    I’ve still got both of those kexts installed on mine. Not sure what else to suggest. I’m happy to send a list of the kexts installed on my system if that helps.

    • cinlortech says:

      Hey John did you see the Native USB 3.0 kext, I’m going to do a fresh install without my DSDT and try that one. It could be the DSDT is causing the problem.

      • John says:

        Yeah, I haven’t given it a try, but I did see it. I read somewhere that as Apple isn’t using an Asmedia controller it may not work, but if it does even better.

        Also, I’m not using a DSDT, so that could be the difference and the cause of your KP.

      • cinlortech says:

        The board they installed it on has the Asmedia 3.0 USB, so its worth a try.

      • John says:

        Cool, let me know how you go. I may give it a try a little later and if I have any luck I’ll let you know.

      • cinlortech says:

        Oh btw, are you running 10.7.3 or .4?

      • John says:

        I just tried the native USB 3.0 kexts on one of my backup partitions and it didn’t work. My USB 3.0 ports didn’t even show up in System Preferences, much less work. So it looks like for now I’ll be sticking with the other kext. But if you find something different do let me know.

        I’m using 10.7.4

      • John says:

        btw, I should mention I don’t actually have any USB 3.0 peripherals, so I can’t confirm whether the increased speeds work or not, just that they can now be used as at least USB 2.0 ports.

  2. John says:

    So I just found this kext http://www.osx86.net/downloads.php?do=file&id=2810 which manages to solve the shutdown problems and USB 3.0 is working. I had to remove NullCPUPowerManagement.kext to get it to boot, but as of now I’ve got sleep and shutdown and USB 3.0 working as they should!

    • cinlortech says:

      Hey John – This sounds promising, but the link gives me an “invalid file id”. Can you give us another link that might work.

      • cinlortech says:

        I finally got to the download. I installed the driver pkg, but won’t boot up, getting a kernel panic. What else did you do besides remove the NullCPUPowerManagement kext? It won’t boot in safe mode or verbose. Did you delete these kexts also: CallDigitFastIO.kext
        CallDigitUSBxHCI.kext?

  3. Martin says:

    Gotta love Safari’s autocorrection, the above entry should read _macman_ and not ‘‘madman’’. 😉

  4. Martin says:

    Let me know how it goes. As I’ve tried all the VoodooHDA revisions, as well as ‘madman’s ALC888 drivers (none of which have worked) and experiencing the same behavior, I am not too sure if the problem lies with the audio driver.

    Also tried replacing the network driver (RealtekRTL81xx) with AppleRTL8169Ethernet (which does work for the 8111E, but for some curious reason sometimes gives kernel panics _after_ finishing a Skype audio call!)

    Again, the kernel panics are erratic, and the system can run for days playing videos, transcoding using HandBrake and general web stuff without having a problem.

    However, there is something amiss as the system will often KP on boot. Booting verbosely does not give a clear indication of where the problem is though (often referring to just ‘kernel_task’ etc.)

    If you do get it stable the output of ‘kextstat | grep -v apple’ would prove useful. 🙂

    Really wish there was a way to harvest some information about what exactly is wrong instead of that idiotic ‘you need to reboot your computer message’ when running in a graphical mode.

    Frankly, sometimes I think Apple is serving up these kernel panics randomly just because it detects the system OS X is running on is not ‘genuine’ Apple hardware. 😉

    • cinlortech says:

      Mine does the same thing, random KPs at boot up. Have you seen the edited ALC888 AppleHDA kext by toledo? I was hoping this might work, here is the link. Have a look and see what you think.

      • Martin says:

        Tried toleda’s AppleHDA today but no luck so far (as I’m sure you’ve already found out yourself)

        Also tried a couple of DSDTs (by Peter Haas) specifically for the SH67H3/7, but they all cause instant kernel panics (‘‘MCA Error’’ / ‘‘Processor context corrupt’’ / ‘‘Panic […] Machine check’’ during boot.

        Any other Shuttle owners out there that have a DSDT which is working? The ALC888 support in AppleHDA requires a modified HDEF section.

        Maybe I’ll try one of the ‘‘generic’’ Gigabyte H67-based DSDTs.

        Still need to get HDMI video and audio working as well. There is output on the HDMI port, but it is all garbled.

    • John says:

      I found that the VoodooHDA kext was actually the culprit for the random kernel panics. I’ve been using a cheap usb audio card I bought off ebay (which is annoying because I’d really just like to have the built-in audio working) and the second I removed the VoodooHDA kext my random kernel panics on boot stopped and I haven’t had them since–it has been months since I’ve had any.

      • cinlortech says:

        I’ve been testing a couple of the other ALC888 kexts, but no success so far. The edited ALC888 AppleHDA kext didn’t work but, I think there maybe some additional edits that need to be done.

        I also read that a couple of people with the H3 have used the VoodooHDA 2.7.3 and the AppleHDA rollback with Lion and made it stable. I did try that also but still got a panic on boot up.

        I’m still working on it and will advise when I have success.

      • Martin says:

        It is likely that the VoodooHDA is responsible for the random kernel panics on my system as well. As mentioned they occur during boot, but once the system is up it will work for days and even weeks w/o issue. Last time I had a KP was yesterday when the system had been running for ~6 days.

        I did try some DSDT hacking (can’t say I love it as it seems rather messy) in order to give the patched AppleHDA another try.

        However, it requires a modified HDEF section but there is none in my DSDT extract (neither is AZAL/AZALIA or HDAC, AZAD as suggested by ‘‘DSDTSE’’).

        Any suggestions? Seems curious that it should be this hard to get it running properly (considering I did get two other ‘‘very-unsupported’’ systems working without random KPs; but not the one I specifically bought in order to run OS X on!)

      • cinlortech says:

        Hey Martin – I did try the AppleHDA kext with no success. There are a few extra edits that need to be done.
        There is a fix for the KPs in VoodooHDA I came across, but I know we all want the Realtek driver to work instead.

      • Martin says:

        I would indeed be interested in knowing what potential fixes would solve the VoodooHDA KPs. Right now I am simply inserting the kernel module after booting, so as to prevent hangs during startup. 0.2.62 does work quite well (with the obvious exception of it crapping during the boot processes).

        I frequently use it to send the audio optically to my amp in order to play my FLAC files.

        If you have any DSDT edits (or links to such) I could test those as well–all my own DSDT editing have not really borne any fruit.

        Obviously I want the the sound support as ‘‘native’’ as possible, but it is always nice to have a few alternatives (especially considering no-one has verified that the AppleHDA driver actually does work 100% on the Shuttle)

        Really do want this Shuttle to work 100%. It’s a great and extremely powerful little system.

      • cinlortech says:

        I haven’t tried this yet, but here is the link:

        It’s suppose to stop the KPs at boot up when using VoodooHDA.

        Let me know how it works.

      • Martin says:

        Thanks for the link. Been running with kext cache / UseKernelCache=Yes since the system was installed, though.
        Actually thinking of removing that option to see if that has an effect. The system boots in a couple of seconds anyway.

        On the Dell Dimension 9200 system that I set up VoodooHDA (0.2.1) caused random kernel panics on boot, and moving the kext from /Extra to /S/L/E — however _without_ using UseKernelCache — resolved the issue. Kernel caches never worked on that system at all due to AHCI not being activated.

        The way OS X boots and loads kernel drivers is frankly beyond me. If it works one time it should work the second and the n-nth time as well. Simply rebooting a second time without changing anything at all should not be a temporary fix!

        Wonder what happened to the people developing the VoodooHDA driver (the one hosted on Google code, not the hacked-to-pieces projectosx-branch). I’m sure there’s an easy fix for all this.

        Nevertheless, I am hoping the audio can be made to run with the native AppleHDA driver. But for that we obviously need a custom DSDT (unless someone makes a custom enabler), and it appears the ones I have available is incompatible (different CPU/BIOS version/gfx etc.)

      • cinlortech says:

        I’m wondering if the pinconfig is different on the H3/7.
        I’m going to try to get a DSDT made for this system.

      • Martin says:

        That’s what I’m thinking as well. During verbose boot it usually hangs when probing the pin config.

        Output from VoodooHDA (0.2.62) when it works:

        Apr 4 17:45:31 localhost kernel[0]: VoodooHDADevice[0xffffff8333426000]::init
        Apr 4 17:45:31 localhost kernel[0]: Enabling output audio routing switching at node 20:
        Apr 4 17:45:31 localhost kernel[0]: Enabling output audio routing switching at node 21:
        Apr 4 17:45:31 localhost kernel[0]: Enabling output audio routing switching at node 22:
        Apr 4 17:45:31 localhost kernel[0]: Enabling output audio routing switching at node 23:
        Apr 4 17:45:31 localhost kernel[0]: Pin sense: cad 2 nid=20 res=1
        Apr 4 17:45:31 localhost kernel[0]: setDesc change description Line-out (Green Rear) channel 0 assoc 0
        Apr 4 17:45:31 localhost kernel[0]: Pin sense: cad 2 nid=21 res=0
        Apr 4 17:45:31 localhost kernel[0]: Pin sense: cad 2 nid=22 res=0
        Apr 4 17:45:31 localhost kernel[0]: Pin sense: cad 2 nid=23 res=0

        The other VoodooHDA versions tend to crash the system when setting the format to 44.1/48KHz 16bit in Audio/MIDI setup for the S/Pdif or HDMI ports.

        OS X defaults to 192000Hz/24-bit after a clean boot (which is incompatible with most TOSlink outputs). It is supposed to store the settings, but this has never happened (even when the system boots cleanly)

      • cinlortech says:

        I’m not exactly sure how to check it. I think I can get the pin config from Windows. I’ll investigate further and let you know.

  5. Martin says:

    Hey there,

    Just wanted to post a quick update as I notice you have been busy testing another Shuttle model (this information is really quite helpful!). Don’t know of a better place to post it, so I am adding it to this thread. Hopefully you are still using the SH67H3/7. 🙂

    I did get the S/PDIF port on the ALC888 working. It took some time to realize that basically all the recent VoodooHDA versions are utter crap! (even after doing the workaround to fix the background noise)

    None of the 2.7.x versions offer any functioning digital optical output, and I also noticed that the volume levels on these versions are indeed boosted way too high (try playing a movie in VLC or MPlayerX, for instance. You’ll get clipping and sound distortion)

    In case you are interested in getting proper digital output on the S/PDIF the version that worked is 0.2.62-with the plist modified to set iGain to ‘0’ and iMix to ‘100.’ This is for 2-channel output–the newer VoodooHDA’s do detect 4ch but–again–they do not actually output anything apart from a very occasional crackle! 😉

    I have not investigated the USB3.0 issue very thoroughly yet, as I do not have any USB3-hardware. I did look for relevant kexts in the Mountain Lion DP1 build, though, but did not locate any standalone drivers for it. Also haven’t installed Linux on my spare partition yet.

    I have however been trying to get the SH67H7 system up and running as stable as I could, but there are still issues with stability and random kernel panics (especially during boot)

    I have been unable to pinpoint the problem, and was therefore wondering if you have any pointers on this? Specifically, what are the versions of the non-standard kexts you are using?

    The ones that are in use on my main 10.7.3 install are as follows:

    Index Refs Address Size Wired Name (Version)
    11 0 0xffffff7f80917000 0x2000 0x2000 org.tgwbd.driver.NullCPUPowerManagement (1.0.0d2)
    12 0 0xffffff7f8084b000 0x2000 0x2000 sk.triaxis.kext.SleepEnabler (1.0.0)
    27 0 0xffffff7f80f45000 0x7000 0x7000 org.netkas.FakeSMC (3.1.0)
    36 0 0xffffff7f8088d000 0x34000 0x34000 com.lnx2mac.driver.RealtekRTL81xx (0.0.90)
    72 0 0xffffff7f807de000 0x5000 0x5000 com.Cycling74.driver.Soundflower (1.6.2)
    74 0 0xffffff7f807b3000 0x20000 0x20000 org.voodoo.driver.VoodooHDA (0.2.62)
    82 0 0xffffff7f81695000 0x3000 0x3000 com.bresink.driver.BRESINKx86Monitoring (8.0)

    btw, the bresinkx86monitoring kext is just for the CPU temp. monitoring and the ‘SoundFlower’ is a pseudo-sound-output driver. The problems started before these two kexts were introduced, so I am pretty sure they are not the cause of it.

    I have also tried to eliminate the NullCPUPowerManagement kext, but have found that the system does not boot without it.

    AFAIK there still isn’t a working DSDT for this system, although I do have one I haven’t tested yet.

    • cinlortech says:

      Hi Martin,

      I have had the SH67H3 on the back burner, working on the XH61. The XH61 is running pretty stable now, so I’m going back to work on the H3. There is a new Audio driver out now for the ALC888. I’m going to try it out and advise, after I install Lion.
      As for the occasional KPs on the H3, I’m not sure if it’s the VoodooHDA driver that causes that. I guess we’ll find out if I can get the Realtek Audio driver working.
      Unfortunately, I haven’t found an Asmedia USB 3 driver as of yet.
      When I finish installing Lion, I’ll let you know what kexts I had to install.

  6. Martin says:

    Thanks for the quick reply! Good to hear that the VoodooHDA driver works. Is it the 2.7.3 version you’re using, and with/without the AppleHDA rollback?

    Personally I am using VoodooHDA myself–although it’s an older version (0.2.1)–on both my laptop OS X Lion install (Fujitsu-Siemens Lifebook E8410) and a stationary (Dell Dimension 9200). It has worked pretty well.

    I am unsure if I am going to use the Reneas driver (which it indeed is called; I don’t really use MultiBeast all that much ;), as it apparently requires the firmware to be flashed from within W*ndows (which I do not use anywhere).

    I’m going to try the ports from Linux and do some firmware checking first. USB3 support came pretty early in the 2.6 kernel, so surely there must be a way to get it working from within OS X or another *nix. As for native OS X support I guess it depends on which chipset Apple eventually chooses.

    The non-shutdown thing bothers me more than having USB3, frankly. I have this problem on the laptop (in addition to not being able to use the internal LVDS display), and it is quite cumbersome to force the power off every time. Help around various forums seems to be scarce, unfortunately, regarding DSDT editing and such.

    btw., my choice stood between this SH67H7 Shuttle model and the recently-announced SZ68R5. However, from reading various user experiences of Intel’s Z68 (especially on tonymacx86.com) it seems that particular chipset perhaps wasn’t the best alternative currently.

  7. Martin says:

    Interesting bits of info on the Shuttle SH67H3/7! I am strongly considering this system myself for OS X Lion.

    How did you fare with the audio, btw.? I’ve read reports of background noise and other issues with the ALC888, which the SH67 uses.

    Also, have you tried modifying the DSDT in order to get shutdown working with the ASMedia USB 3.0 drivers?

    • cinlortech says:

      Audio – I didn’t use the Realtek Audio driver, due to the background noise. I used the VoodooHDA driver which works just fine.

      Shutdown Problem – There is no Asmedia USB 3.0 driver available. In MultiBeast there is a Renesas/NEC USB 3.0 driver, which is the one causing the shutdown problem. I have not tried editing the DSDT of the Renesas driver to fix the shutdown issue. If you do intend to build and install Mac Lion, there is a firmware update you must install along with the Rensas/NEC driver for the ports to work. I have posted a link to the firmware update.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: