Em Sat, 15 Apr 2017 20:28:20 +0200 Anders Eriksson <aeriksson2@xxxxxxxxx> escreveu: > Hi Mauro, > > I've two devices using this driver, and whenever I have them both in > use I eventually (between 10K and 100K secs uptime) i2c write errors > such as in the log below. If only have one of the devices in use, the > machine is stable. > > The machine never recovers from the error. > > All help apreciated. > -Anders > > > > [ 0.000000] Booting Linux on physical CPU 0xf00 > [ 0.000000] Initializing cgroup subsys cpuset > [ 0.000000] Initializing cgroup subsys cpu > [ 0.000000] Initializing cgroup subsys cpuacct > [ 0.000000] Linux version 4.4.15-v7+ (dc4@dc4-XPS13-9333) (gcc > version 4.9.3 (crosstool-NG crosstool-ng-1.22.0-88-g8460611) ) #897 > SMP Tue Jul 12 18:42:55 BST 2016 > [ 0.000000] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d > [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing > instruction cache > [ 0.000000] Machine model: Raspberry Pi 2 Model B Rev 1.1 Hmm.. RPi2... that explains a lot ;) I've seen similar behaviors on some arm devices with just one device. That's likely due to some problem with isochronous transfers at the USB host driver. The thing is that ISOC transfers are heavily used by USB cameras: they require that the USB chip would provide a steady throughput that can eat up to 60% of the USB maximum bitrate, with just one video stream. My experience says that several USB drivers can't sustain such bit rates for a long time. The RPi tree uses an out-of-tree driver for the USB host driver (otgdwc - I guess). Upstream uses a different driver (dwc2). My recent experiences with upstream(dwc2) and USB cameras is even worse: it doesn't work, if the camera supports only ISOC frames. I'll eventually try to fix the upstream driver if I find spare time for it, but I won't touch at the proprietary driver that is shipped with the downstream Kernel. Thanks, Mauro
