Previous 1 2 3 4 5 Next 74 Replies Latest reply: Apr 27, 2013 4:39 PM by -groovatious- Go to original post
  • David A. Gatwood Level 3 Level 3 (580 points)

    That's probably a bad idea.  You could potentially break a future software update if you go editing system files like that.  If you want a temporary workaround (until Apple ships a real fix), you should instead create a codeless KEXT with a higher probe score for that device that forces it to match against the right driver.

     

    Basically, create an empty kext folder (owned by root) with a single Info.plist file, copy and paste the stuff here:

     

    https://developer.apple.com/library/mac/documentation/Darwin/Conceptual/KEXTConc ept/KEXTConceptAnatomy/kext_anatomy.html#//apple_ref/doc/uid/20002364-SW8

     

    and change all the class names and bundle identifiers appropriately.

  • hyderali91 Level 1 Level 1 (10 points)

    Commenting out a single device in a plist won't cause a system update to break the system... at worst, the plist will get replaced with an updated version and I'd have to comment it out again. I'm not sure the codeless kext would work anyway... how would you ensure the probe score is higher? Based on Apple's documentation, it seems the best case scenario would be that the codeless kext and the default kext will both have a probe score of 100000. So I don't know if that'd give the desired results or not.

     

    I also question if Apple would even deploy a proper fix. Technically nothing is broken - the issue is that Belkin released two very different devices with identical vendor/product ids. Presumably in the past OSX didn't have identify that bluetooth module, and now it does. That's not really Apple's problem

  • Jason Heiser Level 1 Level 1 (0 points)

    I followed hyderali91's instructions and commented out this device in this plist. After rebooting my MacBook Pro, I disconnected my Belkin USB hub and reconnected it. Alas, "bulk IN pipe open failed!" and my hub was dead again. I checked System Information to doublecheck that I have the same Belkin USB hub. I believe I do.

     

    USB 2.0 Hub [MTT]:

    Product ID: 0x0017

    Vendor ID: 0x050d  (Belkin Corporation)

    Version: 1.00

     

    Is there something else I need to do after editing the plist?

  • David A. Gatwood Level 3 Level 3 (580 points)

    Commenting out a single device in a plist won't cause a system update to break the system... at worst, the plist will get replaced with an updated version and I'd have to comment it out again. I'm not sure the codeless kext would work anyway... how would you ensure the probe score is higher? Based on Apple's documentation, it seems the best case scenario would be that the codeless kext and the default kext will both have a probe score of 100000. So I don't know if that'd give the desired results or not.

     

    You can only ensure that the probe score is higher than it currently is in the Bluetooth KEXT.  You can't ensure that they won't ever crank the probe score higher.  Given that those files don't change often, though, I doubt that's an issue.  And because there's no probe score specified, I think any probe score other than zero should match with a higher priority.  That said, I could be misremembering the way static probing works.  (Where's Nik when you need him?)

     

    And while it is true that the plist should get replaced with the updated version if it gets updated, I seem to recall that some updates ship (or shipped?) in a smaller version that patched binaries.  If I'm remembering correctly, then there's always some risk that the OS won't correctly notice the modified file and will try to use the smaller, binary-patching version of the update (assuming those still exist), in which case things could break.

     

    There's also the fact that you said to use TextEdit, which could destroy ownership and permissions and thus render the entire KEXT unloadable.  Heck, TextEdit shouldn't even be able to write the file unless you use "sudo open TextEdit"....

     

     

    I also question if Apple would even deploy a proper fix. Technically nothing is broken - the issue is that Belkin released two very different devices with identical vendor/product ids. Presumably in the past OSX didn't have identify that bluetooth module, and now it does. That's not really Apple's problem

     

    I apparently gave Belkin too much credit by assuming that the Bluetooth driver was matching on device class/subclass/PID rather than an actual reuse of a VID/PID pair.  *sigh*  Still, it's a behavior regression from the previous OS, and it's roughly a two-line fix in the driver itself to immediately return false from the Bluetooth driver's probe() routine if the matching device's class is 0x09 (USB hub) or whatever.

     

    Obviously I can't say what will or won't be in future OS updates, but I've filed the bug, and it's an easy fix, so I wouldn't spend too much time messing around with this problem.  Just saying.

     

    Oh, one more thing.  Please don't edit kexts in TextEdit.  TextEdit wasn't really meant to be run as root, and you run the risk of screwing up the permissions or ownership of the file.  The OS is very picky about that, and will refuse to load any kext with invalid permissions or ownership, for obvious security reasons.  If you've already broken your driver, do this:

    cd /System/Library/Extensions/IOBluetoothFamily.kext/

    cd Contents/PlugIns/

    cd BroadcomBluetoothHCIControllerUSBTransport.kext/Contents/

    sudo chown root:wheel Info.plist

    sudo chmod u=rw,g=r,o=r root:wheel Info.plist

    sudo touch /System/Library/Extensions

     

    Split into multiple lines because this discussion board's editor can't be stretched wider.  Speaking of bugs to file....

     

    That last line forces the KEXT caches to get rebuilt.  Otherwise, your changes will have no effect on systems that have an actual Broadcom Bluetooth chip in them... until the user installs an OS update.  And then, if the user hasn't done the above steps, and if that OS update doesn't happen to replace that file with a copy that has correct permissions, that user will lose all Bluetooth functionality.  (Did I mention that editing kext files yourself is quite risky?  This is why.)

  • hyderali91 Level 1 Level 1 (10 points)

    I assume "chown -R root:wheel *path to kext*" and "chmod -R 755 *path to kext*" would accomplish the same thing"? That's what I typically do whenever messing with kexts. Typically also just repair permissions for good measure. As far as rebuilding the kext caches... My system seems to have a broadcom BT chip onboard, but the changes still worked.

     

    I know the BT file doesn't have a probe score specified, but my understanding was that the OS calculates a probe score depending on how much information is defined in the kext. In fact, Apple specifically mentions that you shouldn't manually assign a probe score.

     

    Anyway - I also tried your way. I restored the original kext (I'm not completely careless, I do make backups of anything I modify), made a codeless kext, set the permissions/ownership appropriately. Seems to work - so I guess the codeless kext does indeed hav a higher probe score. I did *not* manually specify a score. But whenever I plug/unplug it, it gets picked right up, as it should.

     

    Here's the plist I made. Much of it can be customized to your liking. The important bits are in the IOKitPersonalities section. I made a directory named BelkinUSBHub.kext (can be named whatever you want), inside there I made another directory called Contents, and then I made a plist with the text below.

     

    <?xml version="1.0" encoding="UTF-8"?>

    <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">

    <plist version="1.0">

    <dict>

              <key>BuildMachineOSBuild</key>

              <string>12B19</string>

              <key>CFBundleDevelopmentRegion</key>

              <string>English</string>

              <key>CFBundleIdentifier</key>

              <string>com.belkin.iokit.VendorSpecificDriver</string>

              <key>CFBundleInfoDictionaryVersion</key>

              <string>6.0</string>

              <key>CFBundleName</key>

              <string></string>

              <key>CFBundlePackageType</key>

              <string>KEXT</string>

              <key>CFBundleSignature</key>

              <string>????</string>

              <key>CFBundleVersion</key>

              <string>1.0.0</string>

              <key>IOKitPersonalities</key>

    <dict>

        <key>Belkin USB Hub</key>

        <dict>

            <key>CFBundleIdentifier</key>

            <string>com.apple.driver.AppleUSBHub</string>

            <key>IOClass</key>

            <string>AppleUSBHub</string>

            <key>IOProviderClass</key>

            <string>IOUSBDevice</string>

            <key>idProduct</key>

            <integer>23</integer>

            <key>idVendor</key>

            <integer>1293</integer>

        </dict>

    </dict>          </dict>

    </plist>

     

    After that just set the permissions properly, reboot, and everything should just work. Or at least it does on my system.

  • David A. Gatwood Level 3 Level 3 (580 points)

     

    I know the BT file doesn't have a probe score specified, but my understanding was that the OS calculates a probe score depending on how much information is defined in the kext. In fact, Apple specifically mentions that you shouldn't manually assign a probe score.

     

     

    Apple says that mainly to avoid an arms race between third-party kexts and Apple kexts.  IMO, it's okay to use them as a temporary workaround, but it isn't something you should do in a shipping product because as you said, there's no guarantee it will permanently solve the problem if the kext you're trying to displace ends up with a higher probe score for some reason (whether due to changes in OS rules for determining the probe score, or whatever.  :-)

     

    I may have been wrong before about anything above zero working—I was thinking it was additive rather than a replacement for the computed value (and maybe it is—I really am fuzzy on that, since it isn't encouraged behavior).  It might need to be above 90,000 (the match level for vid + pid in the absence of a bcdDevice version).

     

    What's interesting is that your override kext works and isn't nondeterministic as I would expect it to be given that the score should match that of the Bluetooth kext.  *shrugs*  Maybe because the driver is already loaded as part of the boot cache, so its probe routine might always be the first to run.  Dunno.

     

    Either way, as I said, the right fix is to modify the Broadcom kext to check the device class and return NULL for that VID/PID pair if the device says that it is a hub.

  • jack-s Level 1 Level 1 (0 points)

    hyderali91 wrote:

     

    I assume "chown -R root:wheel *path to kext*" and "chmod -R 755 *path to kext*" would accomplish the same thing"?

     

    ...

     

    I made a directory named BelkinUSBHub.kext (can be named whatever you want), inside there I made another directory called Contents, and then I made a plist with the text below.

     

    <?xml version="1.0" encoding="UTF-8"?>

    <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">

    <plist version="1.0">

    <dict>

              <key>BuildMachineOSBuild</key>

              <string>12B19</string>

              <key>CFBundleDevelopmentRegion</key>

              <string>English</string>

              <key>CFBundleIdentifier</key>

              <string>com.belkin.iokit.VendorSpecificDriver</string>

              <key>CFBundleInfoDictionaryVersion</key>

              <string>6.0</string>

              <key>CFBundleName</key>

              <string></string>

              <key>CFBundlePackageType</key>

              <string>KEXT</string>

              <key>CFBundleSignature</key>

              <string>????</string>

              <key>CFBundleVersion</key>

              <string>1.0.0</string>

              <key>IOKitPersonalities</key>

    <dict>

        <key>Belkin USB Hub</key>

        <dict>

            <key>CFBundleIdentifier</key>

            <string>com.apple.driver.AppleUSBHub</string>

            <key>IOClass</key>

            <string>AppleUSBHub</string>

            <key>IOProviderClass</key>

            <string>IOUSBDevice</string>

            <key>idProduct</key>

            <integer>23</integer>

            <key>idVendor</key>

            <integer>1293</integer>

        </dict>

    </dict>          </dict>

    </plist>

     

    After that just set the permissions properly, reboot, and everything should just work. Or at least it does on my system.

     

    Just stumbled on this thread looking for help with my Belkin F4U017 hub, these intructions worked great and it's now woring perfectly. Thanks!

  • Jason Heiser Level 1 Level 1 (0 points)

    My Belkin hub is now working again, just like it did prior to upgrading to Mountain Lion. Apparently it just took a while before the edited plist had an effect on my setup. Cheers to Messrs hyderali91 and Gatwood for their good work here.

  • Steve Palm Level 2 Level 2 (180 points)

    Funny thing is, I have this same problem.....

     

    Belkin USB hub (7 ports I believe) works just fine...until I unplug it and put my MacBook on battery.  If I then come back and put the laptop on AC power and plug in the USB hub...I have to then restart for the the USB hub to work again

     

    Even when not using a Belkin hub...   was using another third party hub, but I ditched that and just plugged my Apple keyboard (A1243) in, and have the same problem in that it works great until I sleep and put it on battery, and then when I wake up again and plug in the keyboard the USB port goes dead.  I can't find anything in Console.app showing errors, but the port remains unresponsive to anything else until a shut down.  Also, if I try to launch "USB Profiler" from the developer tools at this point it just hangs and never loads.

     

    I think there is a deeper issue with Mountain Lion and USB hubs/devices, it isn't just Belkin's fault.

  • David A. Gatwood Level 3 Level 3 (580 points)

    If it works at all, ever, it almost certainly isn't the same bug that affects the Belkin four-port hubs (which really isn't a bug, per se—reusing VID/PID pairs is a very bad idea).

     

    I have that model of keyboard sitting right in front of me, and I'm not seeing any problems with it (on multiple Macs) after sleep.  Could you provide more details?  In particular, what model of computer are you using?  What steps cause the problem to occur for you?  Be specific—for example:

     

    1.  Plug A1243 keyboard into frontmost port on the left side of [insert model and year] laptop.

    2.  Unplug power.

    3.  Put machine to sleep.

    4.  Unplug keyboard.

    5.  Wake up.

    6.  Plug keyboard back into the same port.

     

    or whatever.

     

    BTW, given that this is a port failure after a sleep/wake cycle, it is possible that your power management hardware has gotten confused somehow, in which case an SMC reset *might* fix the problem.  Worth a try, anyway.

  • StevenPalm Level 1 Level 1 (0 points)

    MacBook Pro Early 2011, This problem started with 10.8 including up to the latest 10.8.2 dev seed...

     

    Plug in the A1243 keyboard into either port

    It will work fine

    Remove the keyboard

    Put the laptop to sleep

    remove AC power

    wake the laptop, use it on battery

    Put it to sleep.

    Wake it up, either with power attached or attaching power after wake up

    Plug the keyboard in.

    The keyboard does not function, the USB port is dead until reboot, and USB Prober will not launch (hangs).

    Also can not use Reboot or Shut Down from Apple Menu at this point, have to reboot from terminal

     

    Using an old Apple Keybaord (from an old G4 system) does not have this problem.

     

    The only reason I am using the A1243 keyboard is becuase the Apple BlueTooth keyboard (original model) started having random disconnects from Lion forward, still not fixed either...  And it is the only bluetooth device in the area.

     

    If Apple can't make their own products work reliably, what hope is there?

     

    SMC/PRAM resets tried many times, no joy.  As long as I don't reconnect the keyboard (and only the keyboard, no other devices are inline with it) the port functions fine through this cycle.  Yes, one may say it is the keyboard, but it only started the day I installed Mountain Lion, and even sleeping and waking the computer does not cause a problem as long as I don't remove the AC power and run it on battery.

  • explicitdt Level 1 Level 1 (0 points)

    I've been having this problem too with my F4U017, so from reading the above the only way this is to be fixed without editing system files/ create a codeless KEXTs etc. is to wait for the software updates from Apple? Can Belkin do anything in the mean time?

     

    Does anyone have any indications of when the update will be?

  • itsryley Level 1 Level 1 (0 points)

    Steve Palm wrote:

     

    I think there is a deeper issue with Mountain Lion and USB hubs/devices, it isn't just Belkin's fault.


    Sorry to charm in with a 'me too' but I've been having the exact same problems with my MPB 15-inch, Early 2011 OSX 10.7.6 and now with 10.8. First it was my NI Audio 8 soundcard, My Belkin hub has just added to the list of stuff...

     

    Massive troubles!

  • David A. Gatwood Level 3 Level 3 (580 points)

    Please download 10.8.2.  It should resolve the Belkin problem.

  • David A. Gatwood Level 3 Level 3 (580 points)

    Oh, and if you've hacked your extensions to work around the problem, now would be a good time to roll back those changes.