From owner-freebsd-arm@freebsd.org Fri Dec 22 17:30:55 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 CC206EA603B for ; Fri, 22 Dec 2017 17:30:55 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [69.239.235.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 95B327FBF6 for ; Fri, 22 Dec 2017 17:30:55 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id vBMHUrB9024194 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 22 Dec 2017 09:30:54 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id vBMHUqdP024193; Fri, 22 Dec 2017 09:30:52 -0800 (PST) (envelope-from fbsd) Date: Fri, 22 Dec 2017 09:30:52 -0800 From: bob prohaska To: Hans Petter Selasky Cc: freebsd-arm@freebsd.org, bob prohaska Subject: Re: Disapearing pl2303 usb serial adapter on rpi2 Message-ID: <20171222173052.GA23984@www.zefox.net> References: <20171220170244.GA16029@www.zefox.net> <20171221161120.GA20324@www.zefox.net> <20171222041657.GA21799@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171222041657.GA21799@www.zefox.net> User-Agent: Mutt/1.5.24 (2015-08-30) 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: Fri, 22 Dec 2017 17:30:55 -0000 > > On Thu, Dec 21, 2017 at 05:29:05PM +0100, Hans Petter Selasky wrote: > > 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 > > > Tried it here, using usbconfig to power cycle the adapter. Console output follows. The pl2303 is at unit 0 address 5. Console output follows: [initial state is pl2303 stuck, no /dev/cuaU0 present, command is usbconfig -u 0 -a 5 power_off] uhub_read_port_status: port 3, wPortStatus=0x0100, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION uhub_read_port_status: port 5, wPortStatus=0x0101, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION usb_needs_explore: usb_bus_powerd: bus=0xd7e65000 uhub_explore: udev=0xd7daf000 addr=1 uhub_read_port_status: port 1, wPortStatus=0x0503, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION uhub_explore: udev=0xd7db0000 addr=2 uhub_read_port_status: port 1, wPortStatus=0x0503, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION uhub_read_port_status: port 2, wPortStatus=0x0503, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION uhub_read_port_status: port 3, wPortStatus=0x0100, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION uhub_read_port_status: port 4, wPortStatus=0x0103, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION uhub_explore: udev=0xd8cdb000 addr=6 uhub_read_port_status: port 1, wPortStatus=0x0103, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION uhub_read_port_status: port 2, wPortStatus=0x0303, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION uhub_read_port_status: port 3, wPortStatus=0x0100, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION uhub_read_port_status: port 5, wPortStatus=0x0101, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION uhub_explore_handle_re_enumerate: Unconfigure failed: USB_ERR_STALLED: Ignored. uhub_reset_tt_callback: TT buffer reset uhub_reset_tt_callback: TT buffer reset usbd_req_re_enumerate: addr=5, set address failed! (USB_ERR_IOERROR, ignored) uhub_reset_tt_callback: TT buffer reset uhub_reset_tt_callback: TT buffer reset usbd_setup_device_desc: getting device descriptor at addr 5 failed, USB_ERR_IOERROR uhub_reset_tt_callback: TT buffer reset uhub_reset_tt_callback: TT buffer reset usbd_req_re_enumerate: addr=5, set address failed! (USB_ERR_IOERROR, ignored) uhub_reset_tt_callback: TT buffer reset uhub_reset_tt_callback: TT buffer reset usbd_setup_device_desc: getting device descriptor at addr 5 failed, USB_ERR_IOERROR usb_needs_explore: usb_bus_powerd: bus=0xd7e65000 uhub_explore: udev=0xd7daf000 addr=1 uhub_read_port_status: port 1, wPortStatus=0x0503, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION uhub_explore: udev=0xd7db0000 addr=2 uhub_read_port_status: port 1, wPortStatus=0x0503, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION uhub_read_port_status: port 2, wPortStatus=0x0503, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION uhub_read_port_status: port 3, wPortStatus=0x0100, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION uhub_read_port_status: port 4, wPortStatus=0x0103, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION uhub_explore: udev=0xd8cdb000 addr=6 uhub_read_port_status: port 1, wPortStatus=0x0103, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION uhub_read_port_status: port 2, wPortStatus=0x0303, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION uhub_read_port_status: port 3, wPortStatu Couldn't establish the timing exactly, but the resets correspond to about the time of the power cycling. After power cycling there was no /dev/cuaU0 created. Curiously, the power cycling _didn't_ trigger the error messages I saw earlier on the controlling terminal; it appeared that the power cycling was successful, even though /dev/cuaU0 wasn't created. Again, unplugging and replugging the USB connector had no effect. Disconnecting the TX, RX and ground and _then_ unplugging/replugging the USB end produced a successful resest of the adapter. Singly disconnecting TX, RX _or_ ground did nothing. Disconnecting both ends completely caused USB recognition and restored normal operation. Thanks for reading, and any ideas! bob prohaska