On 17 August 2010 23:15, Greg KH <greg@xxxxxxxxx> wrote: > On Tue, Aug 17, 2010 at 06:01:45PM -0400, Alan Stern wrote: >> 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? > > We should probably not allow the firmware to be downgraded, so a check > for < should probably be used instead. > > Chris, can you apply the patch below to see if that helps out any? > Promising - just applied it and rebooted and all 16 ports came up. I'll try to get a colleague to do a more substantive test in my absence, but I'm now offline until the weekend anyway, so won't be able to get any results until then. I'll let you know the results next week (hopefully) Thanks for the help so far! Chris -- 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
