On Mon, 16 Aug 2010, Chris Beauchamp wrote: > > These traces are very difficult to follow because they show multiple > > hubs with multiple devices attached to them. Can you provide the > > equivalent information for a single device with no hubs? > > > > Well, each box appears to be a couple of hubs and 8 dual serial port > adaptors. Tricky to separate without completely voiding the warranty > :) There is only one plugged in at a time. Is there a way to separate > in software - I guess I could go through and grep for each device and > separate into a file per device? Would that be helpful? I made some progress by concentrating on just one device. It appears that the problem is entirely in the io_ti.c driver; you can see by comparing these lines from the firstplug and secondplug kernel logs: [ 79.333294] /build/buildd/linux-2.6.32/drivers/usb/serial/io_ti.c: download_fw - >> FW Versions Device 4.80 Driver 0.0 [ 79.333299] /build/buildd/linux-2.6.32/drivers/usb/serial/io_ti.c: download_fw - Update I2C dld from 4.80 to 0.0 [ 227.167254] /build/buildd/linux-2.6.32/drivers/usb/serial/io_ti.c: download_fw - >> FW Versions Device 4.80 Driver 4.80 See the difference in the Driver values? The first time through the Driver version is uninitialized, hence equal to 0.0, which is different from the version 4.80 firmware in the device, so the driver tries to update the device firmware from 4.80 to 0.0! The Driver version doesn't get updated until the driver runs across a device with blank firmware and then loads the firmware file from disk. At that point it learns what the version number should be, and things start to work a little better. There are still problems though, because when the driver sends the firmware to the device, the device doesn't accept the final command to start running the new firmware (the command times out). That's probably why you need to unplug and replug it. That's in 2.6.27. Back in 2.6.24 the firmware was build into the driver, not a separate file, so there was no problem about the Driver version being uninitialized. Greg, I don't know the right way to fix this. Should io_ti.c:download_fw() simply assume that if download_new_ver is 0 then download_cur_ver is correct? Or should it always request the firmware file (that is, call build_i2c_fw_hdr()) during module initialization? I also don't know why the devices don't accept the command to run the new firmware. Any ideas? Alan Stern -- 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
