Quote from: LaserHorse on July 02, 2013, 09:22:45 AM

Quote from: BkkCoins on July 02, 2013, 07:58:16 AM

I'm going to look at USB errors now as some of the HW errors seem to be secondary effects of those. I may move to fixed data records as USBLIB calls don't make it easy to deal with variable length data. You have to know the length in advance or deal with timeout errors, and then it's common to see double records that get truncated.

fwiw - I rolled back to USB-serial based cgminer 3.1.1 due to an abundance of USB errors in newer versions. However this was on an RPi running Raspbian/Debian.

I'm actually using cgminer 3.1.1 anyway. Not for any reason other than that's what was current when I cloned it. I wonder if it's a good idea to update everything to the current version. I've edited many files that contain driver related definitions so I'd have to do some sort of merge if I want to get a new version. I should set it up as a proper fork anyway but just have avoided spending time on that.

With usbread in this version if you give it a read count it will timeout if less bytes are available/read. I'm ignoring timeouts for polling reply data because some replies are of different lengths. If I move to a fixed 16 byte record length even when less is needed then every usbread is for the fixed length and it always returns immediately when data is pending, and presumably if two packets come in succession they won't pile up as they do now. What I'd ideally like is a callback function for each packet received with no polling. For now it's a second thread that just repeatedly polls with usbread for any replies and queues them for other threads to use.

Anyway, watching data with usbmon I see that sometimes for no visible (logged) reason it will just decide to do a control sequence to re-init the device. I don't know why it's doing that. It seems to happen after a nonce is read and a -84 code where normally there is a -115 code logged. But so far I haven't found a reference to what those codes mean. Whatever -84 means seems to cause a device re-init, but as doesn't appear to be related to a bad nonce value. Sometimes it happens even when an accepted good nonce is found.