Intel Chipset Driver Problem

Cautiously Good news -- I have a workaround for the “Intel chipset drivers” problems that fixes the bad behavior I was seeing and might work for those of you who have problems seeing USB devices (like some HP printers) and/or running software that checks USB ports before running (like VMware Workstation). My WMware Workstation 6.5, which previously would not open a VM running from a USB drive, now DOES run. Also, USB ports are now enabled within the VM guest machine, and previously they were grayed out. Finally, the exclamation symbol on the Win7 icon in Devices and Printers window is gone!!!
I hope one of you will volunteer to try this workaround (someone with Windows XP in particular) and see if it clears up similar USB problems you have. Be careful, though (read more below).
I call it a workaround and not a “fix” because I think there is a problem with the Apple firmware. I had a good conversation with AppleCare and they confirmed that the messages we all saw about the inability to start the two USB Universal Host Controllers (with PCI device IDs 3B36 and 3B3B) is a problem that always results from a Boot Camp install. I was told it would definitely NOT help to wipe out the Windows partition and recreate it. The situation is acknowledged, but no promise that this will change soon. OK, so I work with what I have until Apple fixes it properly.
So (sorry for the long story), I went to learn what the USB controllers should be for my Macbook Pro 17” i7 (it has 3 USB exterbal ports). I read up on the USB specification, the Intel 3400 chipset specs, and I compared the hardware & software configuration as reported in OS X to that in Win7. Intel documents say I should see two EHCI (they are reported as UBS Enhanced Host Controllers in Device Manager) . Those I see, but also Universal Host Controllers with PCI device IDs (unique to Intel) of 3B34 and 3B3C. The USB spec says that each EHCI provides high speed USB functions and each has a built-in Root Hub (they show up in my Win 7 Device Manager). Each EHCI contains 4 virtual Host Controller Devices (those do NOT show up in Device Manager). So those 2 EHCI can control up to 8 USB ports. Sure enough, on the OS X system report, I see that 3B34 is controlling the iSight camera (High speed USB), the IR Receiver (Low speed), and two of the High Speed USB ports (middle one and the one next to the hinge). I see that 3B3C is controlling the third High Speed USB port, the High Speed ExpressCard that I put in to read SD cards, the Apple keyboard/Trackpad (Low Speed), and also goes to a Broadcom Hub that connects to a Bluetooth USB Host Controller. Any one of the ports branching out from the EHCI can be a Hub, so I can add Bluetooth devices to its Hub, for example. The spec says that “up to 127 devices (including Hubs, if present) can be run off a single host controller”.
So for host controllers, I expect to see at LEAST the two EHCIs listed in Win7 under Devices, but NOT NECESSARILY any of the USB Universal Host Controllers (UHCI). Those might or might not be implemented on the motherboard in order to help control Low speed and Full speed USB ports. OS X doesn’t list them, so I think they are not wired out. Even though the chipset can have up to 8 USB 2.0 ports, I think my Macbook Pro is using only the two EHCI, and they can control all 3 device speeds in the USB spec (through software). Seeing two misconfigured UHCI in the Win7 device list is not good, and trying just to remove them their drivers or re-installing the drivers cannot work. What DOES work is disabling the devices themselves!
But first you have to tell the Device Manager to “Show Hidden Devices” because for some reason Windows has decided to treat them as removed hardware. The Show Hidden Devices option is visible on Windows Professional versions, but I’m not sure it shows up on the menu in Home versions. If not, see http://www.techerator.com/2010/05/how-to-remove-hidden-duplicate-copies-of-usb-d evice-drivers-in-windows/ to get at the option. But DO NOT delete them – I’m not sure if that would be harmless or not, but for sure Windows would resurrect them on the next scan for new hardware and you’re back to the same old problem. Just disable them. AppleCare mentioned Show Hidden Devices in passing when I talked to them, and that’s when I got the idea to try unhiding and disabling the ghosts.
Once I Disabled the two ghost devices, the USB enumeration acts normally, correctly ignoring the “turned-off” items. First I verified VMware is now happy. Yes, now I can run the external drive VM at a USB port. Several restarts and reboots and all still OK. Then I went back to OS X and fired up VMware Fusion (I use the Mac flavor too) and verified that BootCamp Win 7 still runs OK from there. All USB ports and devices work in Boot Camp now (I haven’t tested iSight or IR, though). No bad behavior so far, and if needed I can always undo what I did and “re-enable” the 2 UHCI controllers (but why would I?).
I hope to see a true firmware fix for this some day – and Apple, while you’re at it, consider a firmware mod to allow Windows Vista and 7 users to run the high speed AHCI bus for SATA drives rather than the legacy IDE ATA that is implemented right now in Boot Camp. I know that is not easy to do when you don’t know what version of Windows the user is going to install -- WinXP doesn’t support AHCI out of the box. That’s another topic, but I did find that out in comparing how the hardware is run in OS X (supporting AHCI Version 1.3, set to 1.5Gbps) to how it is in Boot Camp (a bit slower, less capable with legacy bus). Getting an option to use the built-in graphics controller rather than NVIDIA (to save battery) would be nice too, but is probably too much to ask for. In spite of the problems I found so far (bought the machine in early August) I really really enjoy it. I plan on having a great OS X system (for home stuff) and a super system for Win 7 (work items).

Thanks for the workaround dawalters,

FYI, if you want to "enable" AHCI support, check out this forum:

http://www.insanelymac.com/forum/index.php?showtopic=126089&st=120&start=120

Apparently, Apple is deliberately killing AHCI support according to what I have read, the EFI on just about all Intel-based Macs is set up in a way that AHCI support (if any) is only enabled if you are booting into MacOS; if you are booting into any other OS, it puts it into legacy IDE mode. What this patch does it patch the BootCamp MBR to tell the EFI to put the SATA controller in AHCI mode.

I played with it but ended up reverting back as the BootCamp icon in system tray could not properly switch between Windows and OS X; I kept getting "Unable to find OS X partition" error although OS X booted just fine when holding the Option key on boot and then selecting OS X. Furthermore, I did the WEI benchmark and my HDD performance scored the same (5.8) either way.

Although I wish that Apple would just mod their EFI to support AHCI in Windows, especially given the fact that Microsoft is pulling support for XP, and Vista and 7 support AHCI out of the box.

Thanks. I have had all sorts of problems with the USB ports, mostly with plugging in two USB devices at once. Since I disabled the devices, I can use everything.

Thank you for your workaround for the Intel chipset driver problem. Your efforts are very much appreciated. Followed your advice re. disabling the two UHCI, and all is well on my MacBook Pro 17" i7 under Windows 7 Pro (32). USB ports appear to function normally, and the unpleasant little warning icon in Devices and Printers has slunk away.

As you say, early days, but so far so good.

Message was edited by: ianedwin

Hi Albert Trub -- regarding the AHCI workaround described on insanelymac.com: I agree with your conclusion that it is not worth meddling with the Master Boot Record just to turn the AHCI mode back on at boot time. It may be OK for the gamer guys, since they crave the speed and don't care (I guess) if this messes up their ability to go back and forth between OS X and Windows. Anyone who is not good at tinkering with MBR and fixing boot errors would have trouble reversing a mistake they make.

To djr57 and ianedwin: I'm happy I helped you out with your USB issues.

I don't know if everything is 100% fine even with the workaround, though -- I still have occasional problems in trying to "safely remove" a drive. That usually is not a big problem (if there is no delayed write to the drive) but even if my files are not corrupted, sometimes there are junk files left behind if I ignore the warning message and pull the drive anyway. The only other option, shutting down or restarting, is a hassle.

dawalters wrote:
I don't know if everything is 100% fine even with the workaround, though -- I still have occasional problems in trying to "safely remove" a drive. That usually is not a big problem (if there is no delayed write to the drive) but even if my files are not corrupted, sometimes there are junk files left behind if I ignore the warning message and pull the drive anyway. The only other option, shutting down or restarting, is a hassle.

The issue with "safely remove" on external storage can happen on native Windows systems just as much. Some app is probably leaving an open handle to the device, which is preventing it from being ejected. I'd suggest getting Process Explorer from Microsoft Sysinternals if you want to find what's leaving the open handle & keeping you from ejecting the device.

Thanks -- yes, I have the Systinternal tools and I also have the Zentimo xStorage manager, which replaces the Safely Remove Hardware icon on my icon tray. Zentimo (new software product) reports the details on what processes have a handle to the device. Most of the time it makes sense (clearly named program/process) but sometimes I see references that don't make sense to me. Same problem with or without Zentimo running, so I can't blame Zentimo for messing up -- it is just a middle-man and reporter. Maybe I can figure it out eventually...