From owner-freebsd-arm@freebsd.org Sat Jun 6 17:54:21 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 8B6DF33A709 for ; Sat, 6 Jun 2020 17:54:21 +0000 (UTC) (envelope-from luke@lukeross.name) Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [217.70.183.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49fRwX2tsBz4SrB for ; Sat, 6 Jun 2020 17:54:20 +0000 (UTC) (envelope-from luke@lukeross.name) X-Originating-IP: 84.45.129.34 Received: from clara.lan (unknown [84.45.129.34]) (Authenticated sender: luke@lukeross.name) by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id 377D31C0005 for ; Sat, 6 Jun 2020 17:54:18 +0000 (UTC) Message-ID: Subject: Re: Problems with cdce/cdceem as a USB-device on R-Pi From: Luke Ross To: freebsd-arm@freebsd.org Date: Sat, 06 Jun 2020 18:54:17 +0100 In-Reply-To: References: <75a918d07625de979e9995b3f01662c9deb0a9c1.camel@lukeross.name> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.36.2-0ubuntu1 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 49fRwX2tsBz4SrB X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of luke@lukeross.name designates 217.70.183.197 as permitted sender) smtp.mailfrom=luke@lukeross.name X-Spamd-Result: default: False [-2.42 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; HAS_XOIP(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-0.88)[-0.883]; RWL_MAILSPIKE_POSSIBLE(0.00)[217.70.183.197:from]; DMARC_NA(0.00)[lukeross.name]; R_SPF_ALLOW(-0.20)[+ip4:217.70.183.192/28]; NEURAL_HAM_SHORT(-0.22)[-0.224]; NEURAL_HAM_MEDIUM(-0.91)[-0.912]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:29169, ipnet:217.70.176.0/20, country:FR]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[217.70.183.197:from] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jun 2020 17:54:21 -0000 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