Date: Sat, 06 Jun 2020 18:54:17 +0100 From: Luke Ross <luke@lukeross.name> To: freebsd-arm@freebsd.org Subject: Re: Problems with cdce/cdceem as a USB-device on R-Pi Message-ID: <ece0dc9f51f80d158d840a4ea18cbb8114848ecc.camel@lukeross.name> In-Reply-To: <e88dbae2-0f00-1e10-576b-54e7f021f53e@selasky.org> References: <75a918d07625de979e9995b3f01662c9deb0a9c1.camel@lukeross.name> <e88dbae2-0f00-1e10-576b-54e7f021f53e@selasky.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, On Wed, 2020-06-03 at 20:13 +0200, Hans Petter Selasky wrote: > On 2020-06-03 19:51, Luke Ross wrote: > > cdceem0: WARNING: cdceem_bulk_read_callback: USB_ST_ERROR: > > USB_ERR_STALLED > > Try to have a look at the USB traffic using: > > usbdump -i usbusX -f Y -s 65536 > > At both client and server side. Might be a controller driver bug, or > the > chip is out of available endpoints, I.E. that you can only have > either > ethernet or serial, but not both. Thanks for the suggestion. I gave it a try, but unfortunately my knowledge of USB isn't enough to really understand what's going on; I'm rather out of my depth here. In cdce mode (no network traffic), when I start the ping there's a brief moment of USB activity at both ends, and no usbdump errors logged. After that, the USB activity completely stops at both ends (empty log) even though the ping is still running. In cdceem mode (network traffic passes, but regular stalls/timeouts) you can see the stalls in the usbdump logs on the host, but it doesn't seem to consistently affect one endpoint - several endpoints seem to be used during the cdceem communication and the stall typically affects more than one (at different times). There's no sign of errors in the dump on the device. One weird observation in cdceem mode - if I ssh into the device, the ssh process will eventually timeout when negotiating the connection (the login never completes). However if I leave a ping to the device running in the background, the USB stalls still happen but the ssh session works as normal (albeit with spikes in latency) - suggesting the extra traffic is able to somehow "unstall". Many thanks, Luke
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ece0dc9f51f80d158d840a4ea18cbb8114848ecc.camel>