We are running the 2.6.28-15 kernel under Ubuntu 9.04 (I know... we are migrating now). We see the USB communication between the kernel driver and the USB device stop after what appears to be 0x7FFFFFFFF microseconds, and suspect it is a logic problem with an unsigned long rolling over. We cannot find the source for this kernel, but in looking at the linux USB driver code in later versions of the kernel and the firmware in our USB device, we are not using timers or incremental counters such that this would be the root cause. We monitored the USB bus when this failure occured with a software monitor tool and saw that URBs submitted at the linux driver level were being put out on the bus, but no response was received from the USB device. The USB device is a TI CC1111 part, hosted on a controller board attached to the system on a PCI slot. We are doing additional tests with the same board hosted on a cradle board that connects to a standard USB 2.0 port on the linux computer with a USB cable to see if the problem replicates that way. With the cradle board configuration, we saw a USB communication failure monitored with a Beagle board USB monitor where traffic was being exchanged bidirectionally on the bus between the linux driver and the CC1111 hosted driver, but the data was not making it to our kernel module that sends/receives URBS. We saw this failure when we disconnected the USB cable and reconnected it. Normally this works, it is not a hard failure, but we do intermittently see communication stop when this procedure is done. I am not sure what part on the linux computer is providing USB host controller services, but we are using the standard USB driver distributed in the kernel. We have ported our application and drivers to the 3.9.2 version of the kernel, hosted under Ubuntu 12.4. Unfortunately, this takes 25 days to reach the fail point so we can analyze the results. Anyone seen this problem or have ideas about what could cause the USB comm to stop consistently at this benchmark time. Is the unplug/reconnect failure a completely separate issue, or is it indicative of some handling problem that also manifests itself in the 0x7fffffff microsecond communication halt? As I indicated earlier, I do not see incremental timer or time calculations being done in the driver sources, so this communication halt that has been 100% predictable certainly seems timer or some increment calculation related, but I just do not see it in the code.-- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
