Alan, On Thu, Mar 13, 2014 at 11:12 AM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > Okay. Maybe this would have been easier to see if you had been writing > actual data instead of just a lot of zeros; the errors would have shown > up when you checked the received data (incorrect checksum or something > like that). Perhaps. The error obviously doesn't happen very easily as otherwise it'd have failed much earlier. I'll be waiting to hear from MAXIM and to try out rev 0x13 before spending time on understanding what triggers the error. >> The work-around for now is to write outgoing packets twice, so that >> both FIFOs contain the same data. With that workaround, we have been >> able to dd 5MB blocks of data repeatedly without any issues (dd >> if=/dev/zero of=/dev/sda1 count=5000 bs=1024). > > That sounds like you would sacrifice a lot of speed, because you are > effectively using single buffering instead of double buffering. The double-buffering is really only useful for isochronous transactions (which we don't have a need for and which the driver doesn't support), since only those can be > 64 bytes. The way the double-buffering is implemented doesn't let us overlap transactions in any way, so the "only" loss is added CPU overhead and SPI-bus time. --david -- eGauge Systems LLC, http://egauge.net/, 1.877-EGAUGE1, fax 720.545.9768 -- 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
