From owner-freebsd-arm@freebsd.org Thu Dec 21 16:31:58 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9FF31EA235C for ; Thu, 21 Dec 2017 16:31:58 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [88.99.82.50]) (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 6800F6D0E8 for ; Thu, 21 Dec 2017 16:31:58 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [62.141.128.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 56882260362; Thu, 21 Dec 2017 17:31:54 +0100 (CET) Subject: Re: Disapearing pl2303 usb serial adapter on rpi2 To: bob prohaska , "Jukka A. Ukkonen" Cc: freebsd-arm@freebsd.org References: <20171220170244.GA16029@www.zefox.net> <20171221161120.GA20324@www.zefox.net> From: Hans Petter Selasky Message-ID: Date: Thu, 21 Dec 2017 17:29:05 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <20171221161120.GA20324@www.zefox.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Dec 2017 16:31:58 -0000 On 12/21/17 17:11, bob prohaska wrote: > On Wed, Dec 20, 2017 at 09:13:12PM +0200, Jukka A. Ukkonen wrote: >> On 12/20/17 19:02, bob prohaska wrote: >>> On an RPI2 at r326951 a pl2303 usb-serial adapter seems to be locking up >>> after a few hours. In the past this could be rectified by using usbconfig >>> to power cycle it, but now even that doesn't work. Apart from the serial >>> device file vanishing from /dev there seems to be no other ill effect. >>> Rebooting fixes the problem for minutes to hours. >>> >>> There is no explict error report in dmesg, but when usbconfig tries to power >>> cycle the adapter the console reports: >>> >>> uhub_explore_handle_re_enumerate: Could not unconfigure device (ignored) >>> usbd_req_re_enumerate: addr=9, set address failed! (USB_ERR_IOERROR, ignored) >>> usbd_setup_device_desc: getting device descriptor at addr 9 failed, USB_ERR_IOERROR >>> usbd_req_re_enumerate: addr=9, set address failed! (USB_ERR_STALLED, ignored) >>> usbd_setup_device_desc: getting device descriptor at addr 9 failed, USB_ERR_STALLED >>> >>> >>> A second RPI2 running r326747 is subject to the same lockup, but the adapter >>> can be unstuck using usbconfig to power cycle it. Hi, You might want to run "usbdump" with the appropriate arguments to capture all USB traffic during such a cycle. Further, you might want to only enable USB HUB debug messages to figure out why the USB stack thinks the device is going away: sysctl hw.usb.uhub.debug=17 From what I know, the RPI series of cards have a small external USB HUB on the board. All USB traffic goes through this High-Speed HUB. When you are using LOW and FULL speed, all traffic is translated from High-Speed USB into LOW and FULL speed USB. I don't rule out some kind of "bug" in this external piece of hardware. You might also try to set (my wild guess): sysctl hw.usb.no_cs_fail=1 Like already mentioned in this thread, the micro USB power input connecter on the RPI is not supposed to handle more than 500mA, regardless of how strong your power supply is. Then you need to subtract the mA's used by the CPU and other chips like ethernet. I wouldn't be surprised if ethernet functionality alone required 150mA at +5V. USB LOW/HIGH/FULL speed all use some kind of pull-UP or pull-DOWN on the data lines. This resistors are typically wired to +5V or GND (0V) on the board and transients in the voltage may be seen as a disconnect by the host or device. Regarding the DTB's. Make sure the USB data pins are correctly configured with regards to pullup/pulldown and not used as GPIOs. --HPS