Date: Thu, 21 Dec 2017 20:16:57 -0800 From: bob prohaska <fbsd@www.zefox.net> To: Hans Petter Selasky <hps@selasky.org> Cc: "Jukka A. Ukkonen" <jau789@gmail.com>, freebsd-arm@freebsd.org, bob prohaska <fbsd@www.zefox.net> Subject: Re: Disapearing pl2303 usb serial adapter on rpi2 Message-ID: <20171222041657.GA21799@www.zefox.net> In-Reply-To: <dfc17d98-a839-0ab9-2d1b-c47fe26be21e@selasky.org> References: <20171220170244.GA16029@www.zefox.net> <a312e6db-20ac-e12e-207e-1f0017cf8cad@gmail.com> <20171221161120.GA20324@www.zefox.net> <dfc17d98-a839-0ab9-2d1b-c47fe26be21e@selasky.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Hans, On Thu, Dec 21, 2017 at 05:29:05PM +0100, Hans Petter Selasky wrote: > 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. > I'll try it next time the pl2303 locks up. > 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 > I've turned that on, and the console is spitting out a lot of output. It'll make quite a haystack in which to find a needle 8-) Any hint what to look for? > 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. > Would changing the baudrate have any effect? A console certainly needn't run at 115200 baud. For present purposes 9600 or less is plenty. > I don't rule out some kind of "bug" in this external piece of hardware. > Many have said pl2303 devices are unreliable, but they seem well-behaved on a Mac and on an RPI3 running Raspbian. Whatever is wrong, it seems not deterministic, but cumulative, with a touch of random. > You might also try to set (my wild guess): > sysctl hw.usb.no_cs_fail=1 > Not sure I understand what this does; is there a description somewhere? > 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. > Some time ago I put a voltmeter on the Pi and the voltage stayed over five volts, but of course short spikes weren't visible in such a test. On average, however, the connector seemed to handle the load. > 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. > Wouldn't that sort of error lead to things not working at all? The problems observed develop after hours or sometimes days. Many thanks for your guidance! bob prohaska
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20171222041657.GA21799>