Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 21 Dec 2017 17:29:05 +0100
From:      Hans Petter Selasky <hps@selasky.org>
To:        bob prohaska <fbsd@www.zefox.net>, "Jukka A. Ukkonen" <jau789@gmail.com>
Cc:        freebsd-arm@freebsd.org
Subject:   Re: Disapearing pl2303 usb serial adapter on rpi2
Message-ID:  <dfc17d98-a839-0ab9-2d1b-c47fe26be21e@selasky.org>
In-Reply-To: <20171221161120.GA20324@www.zefox.net>
References:  <20171220170244.GA16029@www.zefox.net> <a312e6db-20ac-e12e-207e-1f0017cf8cad@gmail.com> <20171221161120.GA20324@www.zefox.net>

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?dfc17d98-a839-0ab9-2d1b-c47fe26be21e>