On Wed, 9 Dec 2009, Andreas Mohr wrote: > Now I've been doing quite a bit more analysis of the driver, found a couple > issues and endianness bugs (irrelevant on my device though), > have (rather too) many ideas for changes. > > I'm currently leaning towards chip lockup (causing USB malfunction, > as evidenced by lsusb descriptor timeouts) somehow triggered by > serial handshake setup problems. That would mean that the chip has > its USB/serial operation not fully isolated, thus an overrun due to > handshake issues (when communicating with the custom-made PIC on the > user side of things) would be able to kill the USB side of the equation. > An interesting detail in this regard is that one was actually able to > read back some bytes, when first loading the driver and _then_ plugging, > thus we ended up with a fresh device without any buffers filled > (although ftdi_sio does submit reset requests to the chip on startup, > so I don't quite see why that might be a problem...). > > NOTE that my device has DTR/DSR wired!! (and RTS/CTS is unsoldered!). > And the DTR/DSR setup in the driver is quite quirky (somewhat > understandable given that Linux even lacks DTR/DSR configuration on the > software side): > One, ftdi_sio keeps sending redundant handshake _configuration_ (a possible > source of chip confusion / USB bus contention, which might be a problem > given internet reports of FTDI lockup in case of concurrent > communication) instead of caching the current settings on the driver side, > two, it doesn't assert DTR, thus possibly confusing the chip management > (or user-device PIC!) about availability of the DTE. > > Given this information I now have some quite frugal next debug attempts > to make, fortunately. > (plus maybe even cleanly separating the hookup to alternatively try > an RTS/CTS setup for further insights) > > > Following are port-specific usbmon logs (isolated from a 0u log), > just for reference > (I'm not really sure whether it's useful to go through them now, > given that on my side I should first triage handshake setup some more, > and the setup on netbook/router was too asymmetric). > For device-specific requests shown below (bytes 40 0x), see ftdi_sio.h > (FTDI_SIO_RESET etc.). > NOTE that timing on the router log is _much_ more aggressive, most certainly > due to not plugging directly into a HC port with OHCI full-speed > config, but via transaction translation on a high-speed-configured > HC port on the router (crap, another asymmetric "feature" of the usbmon > logs below, sorry). I know extremely little about the operation of FTDI chips, so you'll have to figure the rest of this out by yourself. In particular, I don't know what's significanct in the usbmon data. But at least now you are started off in a productive direction. 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
