After installing a Xilinx design tool on a supported Linux operating system and then connecting a Xilinx USB cable, the STATUS LED on the cable does not illuminate, or it briefly illuminates and then extinguishes.
In either situation, the design tool cannot connect to or communicate with the cable.
In addition, error or timeout messages appear in the kernel log (/var/log/messages) when the cable is physically connected to the host.
For example, entries similar to the following appear in the log:
This is not a Xilinx USB cable specific issue.
The Linux USB website (http://www.linux-usb.org/) indicates that this problem has been observed with various USB peripherals on different Linux kernels and host system hardware configurations.
The Linux USB website provides several possible root causes and proposes a number of solutions for the problem.
For convenience, this information is reproduced here:
* High speed devices sometimes have problems with cables used to connect them. They are more sensitive to signal quality issues than older USB 1.1 full or low speed devices. If the device works OK at full speed on the same system, after you "rmmod ehci-hcd", this is likely the problem you are seeing. There are many things you can do to change signal quality.
- Use a different cable. Some are even marketed specifically for use with high speed devices. Most USB 1.1 cables work just fine at high speed, but the one you're using might be an exception (maybe it's been damaged).
- Switch to a different USB connector on your computer. Back panel connectors are often right on the motherboard, with much care taken to preserve signal quality. A front panel connector probably doesn't use cabling designed with USB in mind; and its cable could be damaged by bending, baking or something else even when it's not routed through the power supply.
- Use an external high speed hub. Those hubs have signal conditioning circuitry that may cover up certain flaws.
- Make sure your device is using its own external power supply, or that its battery is fully charged.
* You might be able to get the same device to work at high speed on a different machine.
* You might have some problem with your PCI setup that is preventing your USB host controller from getting hardware interrupts. (Current Linux 2.6 kernels will actually tell you when they notice this problem; see the "dmesg" output.) When Linux submits a request, but never hears back from the controller, this is the diagnostic you will see. To see if this is the problem, look at /proc/interrupts to see if the interrupt count for your host controller driver ever goes up. If it does not, this is the problem: either your BIOS is not telling the truth to Linux (ACPI sometimes confuses these things, or setting the expected OS to windows in your BIOS), or Linux does not understand what it is saying.
* Sometimes a BIOS fix will be available for your motherboard, and in other cases a more recent kernel will have a Linux fix. You might be able to work around this by passing the noapic boot option to your kernel, or (when you are using an add-in PCI card) moving the USB adapter to some other PCI slot. If you are using a current kernel and BIOS, report this problem to the Linux-kernel mailing list, with details about your motherboard and BIOS.