Difference between revisions of "Problem with USB 2.0"
(→Mechanical Damage to Mainboard) |
m (→Solutions) |
||
| (8 intermediate revisions by 3 users not shown) | |||
| Line 14: | Line 14: | ||
there is a (small) risk that when plugging in or removing a USB device causes damage to the chip. Usually, the first symptom is broken USB 2.0, behaving in exactly the way you described (ie, works under Windows, but only after some waiting and as if it was connected to a USB 1.1 controller, not a USB 2.0 one, and not at all under Linux unless you unload the USB 2.0 driver). This tends to lead to a completely dead chipset a short time later, so better get it serviced NOW. | there is a (small) risk that when plugging in or removing a USB device causes damage to the chip. Usually, the first symptom is broken USB 2.0, behaving in exactly the way you described (ie, works under Windows, but only after some waiting and as if it was connected to a USB 1.1 controller, not a USB 2.0 one, and not at all under Linux unless you unload the USB 2.0 driver). This tends to lead to a completely dead chipset a short time later, so better get it serviced NOW. | ||
}} | }} | ||
| + | |||
| + | ====Models affected==== | ||
| + | * {{T40}}, {{T40p}}, {{T41}}, {{T41p}}, {{T42}}, {{T42p}} | ||
| + | * {{X40}} | ||
===Mechanical Damage to Mainboard=== | ===Mechanical Damage to Mainboard=== | ||
| Line 36: | Line 40: | ||
This seems to be a hardware problem with the USB controller on Intel's chip or related electronics. Sending the laptop in for service may help. | This seems to be a hardware problem with the USB controller on Intel's chip or related electronics. Sending the laptop in for service may help. | ||
| − | + | Before anything reflow the Southbridge chip. This may repair the damaged connection to the USB controller. | |
| − | + | If the Linux kernel refuses to register the USB device, you can try removing or disabling the ehci_hcd part. Doing this means that USB devices will run at USB 1.1 speeds, which is supported by pretty much every USB device for backwards compatibility. This is not a problem for USB Keyboards and Mice as they are typically USB 1.1 anyway, but for USB storage devices it can slow things down dramatically. | |
| + | ===removing ehci_hcd=== | ||
| + | If the {{path|ehci_hcd}} support in your distribution is built as a loadable module, you can simply unload it with {{cmdroot|modprobe -r ehci_hcd}}. | ||
| + | To unload it automatically on bootup, you can add the above command to {{path|/etc/rc.local}}. | ||
| + | |||
| + | Or alternatively to prevent the module from ever loading, add {{path|ehci_hcd}} to {{path|/etc/modprobe.d/blacklist.conf}} (or {{path|/etc/modprobe.d/blacklist}}). But note that adding it to the blacklist file might not be enough by itself as most distributions load the ehci_hcd module already during initrd, as such you might need to rebuild your initrd after adding it to the blacklist for it to have effect. | ||
| + | |||
| + | To rebuilt your initrd on a Red Hat/Fedora system, run the following command | ||
| + | mkinitrd -f /boot/initrd-$(uname -r).img $(uname -r) | ||
| + | |||
| + | ===disabling ehci_hcd=== | ||
| + | If your distribution (like Fedora 11) instead compiled the ehci_hcd support directly into the kernel, you cannot unload or blacklist it. | ||
| + | |||
| + | In such cases you can unbind it in sysfs, but first we need to find what the PCI device number of the EHCI controller is as follows; | ||
| + | lspci|grep -i ehci | ||
| + | |||
| + | On a ThinkPad {{T41}} this returns | ||
| + | 00:1d.7 USB Controller: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI Controller (rev 01) | ||
| + | |||
| + | To unbind the ehci_hcd support from the PCI device, run the following command (adjust PCI location, based on lspci result) | ||
| + | echo -n "0000:00:1d.7" > /sys/bus/pci/drivers/ehci_hcd/unbind | ||
| + | |||
| + | To automatically unload it on bootup, simply add the last command to {{path|/etc/rc.local}}. | ||
== See Also == | == See Also == | ||
[http://forums.cnet.com/5208-7586_102-0.html?forumID=68&threadID=151816 IBM X40 USB Problem] (fried USB on multiple {{X40}}s) | [http://forums.cnet.com/5208-7586_102-0.html?forumID=68&threadID=151816 IBM X40 USB Problem] (fried USB on multiple {{X40}}s) | ||
| + | |||
| + | [http://www.oneafrikan.com/2006/03/03/ibm-t42p-thinkpad-usb-ports-not-working/ T42 USB ports not working] | ||
Latest revision as of 20:41, 15 January 2011
Contents
Problem description
On various (early?) T40 models, USB 2.0 may not function, or may function only at USB 1.1 speeds. Symptoms include inability to connect to USB 2.0 devices at USB 2.0 speeds, the "This device can perform faster" pop-up in Windows XP, device ID assignment error messages from the Linux kernel, and frequent reboots of the USB bus and connected devices.
Possible Causes
So far, two possible causes have been suggested. In both cases, replacing the system board is the only solution.
Fried Southbridge USB controller
The Southbridge chip (containing the USB controller) may have been damaged by static electricity:
Short answer: your southbridge is about to die, get your system board replaced. Hopefully its still under warranty.
Long answer: a number of Intel chipsets for Pentium IV and Pentium M processors have a design flaw that makes the southbridge (which contains the USB host controllers) especially sensitive to static electricity. As a result there is a (small) risk that when plugging in or removing a USB device causes damage to the chip. Usually, the first symptom is broken USB 2.0, behaving in exactly the way you described (ie, works under Windows, but only after some waiting and as if it was connected to a USB 1.1 controller, not a USB 2.0 one, and not at all under Linux unless you unload the USB 2.0 driver). This tends to lead to a completely dead chipset a short time later, so better get it serviced NOW.
Models affected
Mechanical Damage to Mainboard
Mechanical damage (from bending, dropping or vibrating the laptop) can lead to components becoming desoldered from the mainboard and no longer having reliable electrical contact:
My T41 shows the same symptoms. USB 2.0 works if I (gently) push the USB plug, or if I slightly flex my thinkpad. For example, it works when I put a pencil under the harddrive on an otherwise flat desk, so that the thinkpad only makes contact with the desk at 3 points (I type on an external keyboard). If I flex the other way, USB 2.0 never works. USB 1.1 always works reliably, irregardless of flexing / pushing the plug.
The same behavior has also been observed on a T42, where the EHCI controller stopped working after structural damage to the laptop. Plugging in a USB 2.0 capable device will yield the following error in dmesg:
usb 4-4: new high speed USB device using ehci_hcd and address XX
hub 4-0:1.0: unable to enumerate USB device on port 4
hub 4-0:1.0: unable to enumerate USB device on port 4
hub 4-0:1.0: unable to enumerate USB device on port 4
Flexing the right palmrest area up will temporarily make the USB 2.0 recognizable again. Tightening the screws on the bottom and front edge of the laptop may also fix the problem.
Clearly, this is an electrical problem and not static electricity.
Solutions
This seems to be a hardware problem with the USB controller on Intel's chip or related electronics. Sending the laptop in for service may help.
Before anything reflow the Southbridge chip. This may repair the damaged connection to the USB controller.
If the Linux kernel refuses to register the USB device, you can try removing or disabling the ehci_hcd part. Doing this means that USB devices will run at USB 1.1 speeds, which is supported by pretty much every USB device for backwards compatibility. This is not a problem for USB Keyboards and Mice as they are typically USB 1.1 anyway, but for USB storage devices it can slow things down dramatically.
removing ehci_hcd
If the ehci_hcd support in your distribution is built as a loadable module, you can simply unload it with # modprobe -r ehci_hcd.
To unload it automatically on bootup, you can add the above command to /etc/rc.local.
Or alternatively to prevent the module from ever loading, add ehci_hcd to /etc/modprobe.d/blacklist.conf (or /etc/modprobe.d/blacklist). But note that adding it to the blacklist file might not be enough by itself as most distributions load the ehci_hcd module already during initrd, as such you might need to rebuild your initrd after adding it to the blacklist for it to have effect.
To rebuilt your initrd on a Red Hat/Fedora system, run the following command
mkinitrd -f /boot/initrd-$(uname -r).img $(uname -r)
disabling ehci_hcd
If your distribution (like Fedora 11) instead compiled the ehci_hcd support directly into the kernel, you cannot unload or blacklist it.
In such cases you can unbind it in sysfs, but first we need to find what the PCI device number of the EHCI controller is as follows;
lspci|grep -i ehci
On a ThinkPad T41 this returns
00:1d.7 USB Controller: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI Controller (rev 01)
To unbind the ehci_hcd support from the PCI device, run the following command (adjust PCI location, based on lspci result)
echo -n "0000:00:1d.7" > /sys/bus/pci/drivers/ehci_hcd/unbind
To automatically unload it on bootup, simply add the last command to /etc/rc.local.
See Also
IBM X40 USB Problem (fried USB on multiple X40s)
