Date: Tue, 5 Feb 2013 08:28:40 -0800 (PST) From: "Chris H" <chris#@1command.com> To: "Karl Denninger" <karl@denninger.net> Cc: freebsd-stable@freebsd.org Subject: Re: So I whip out a FTDI-based multiport Serial USB Adapter.... [SB QUAR: Tue Feb 5 10:15:47 2013] Message-ID: <d53b22c7663468baa3df789c9bb4716a.authenticated@ultimatedns.net> In-Reply-To: <51113242.4060003@denninger.net> References: <511004AA.3060201@denninger.net> <1360008362.93359.485.camel@revolution.hippie.lan> <511020DB.3050302@denninger.net> <1360012382.93359.489.camel@revolution.hippie.lan> <66CBAB45-621B-47F8-AC67-64F816AFE837@bway.net> <1360015226.93359.502.camel@revolution.hippie.lan> <DF3A3AF5-6B74-4D01-9B2E-A1C900540722@bway.net> <51107662.8050708@denninger.net> <51107D82.8040605@denninger.net> <51108DB0.7050403@denninger.net> <bff299b8dda6a83befb45c67ad905944.authenticated@ultimatedns.net> <51113242.4060003@denninger.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> > On 2/5/2013 10:15 AM, Chris H wrote: >>> On 2/4/2013 9:33 PM, Karl Denninger wrote: >>>> On 2/4/2013 9:02 PM, Karl Denninger wrote: >>>>> On 2/4/2013 4:32 PM, Charles Sprickman wrote: >>>>>> These multiport things have been around for a long time. Someone at ISC recommended >>>>>> them when we were looking to replace some unsupported RocketPort cards. Not >>>>>> affiliated >>>>>> with this place, but it's the largest collection of USB to serial stuff I've ever seen >>>>>> (and they document for the most part what chips are involved): >>>>>> >>>>>> http://usbgear.com/USB-Serial.html >>>>>> >>>>>> Our first 16 ports are on one of these: >>>>>> >>>>>> http://usbgear.com/computer_cable_details.cfm?sku=USB-16COM-RM&cats=199&catid=493%2C494%2C474%2C199%2C461%2C106%2C1009%2C601 >>>>>> (the tx/rx blinky lights are handy in troubleshooting) >>>>>> >>>>>> Then the rest on this cheaper model: >>>>>> >>>>>> http://usbgear.com/computer_cable_details.cfm?sku=USBG-8COM-M&cats=199&catid=494%2C199%2C474%2C2345%2C1009 >>>>>> >>>>>>> So for some reason there's a problem with the hub, and that's probably >>>>>>> preventing it from getting as far as seeing the ftdi parts that are >>>>>>> downstream of that. >>>>>> My dmesg snippet is from the latter box. Note that the vendor and product ID are the >>>>>> same as Karl's. Perhaps there is a regression, as I am running 8.3 and have had no >>>>>> issues there (previously it was on a 4.11 box). >>>>>> >>>>>> Charles >>>>>> >>>>> That's the EXACT box. >>>>> >>>>> I've used them for a VERY long time on FreeBSD and they have always >>>>> worked perfectly well, but never on 9.x until now -- and it doesn't work >>>>> on 9.x. >>>>> >>>>> Had to run out for a while -- continuing testing. >>>> OK, with the kernel back the way it was, this is what I got: >>>> >>>> I plug in and get: >>>> >>>> Feb 4 21:17:46 FS kernel: uhub6: <vendor 0x0409 product 0x0050, class >>>> 9/0, rev 2.00/1.00, addr 4> on usbus4 >>>> Feb 4 21:17:46 FS kernel: uhub_attach: port 1 power on failed, >>>> USB_ERR_STALLED >>>> Feb 4 21:17:46 FS kernel: uhub_attach: port 2 power on failed, >>>> USB_ERR_STALLED >>>> Feb 4 21:17:46 FS kernel: uhub_attach: port 3 power on failed, >>>> USB_ERR_STALLED >>>> Feb 4 21:17:46 FS kernel: uhub_attach: port 4 power on failed, >>>> USB_ERR_STALLED >>>> Feb 4 21:17:46 FS kernel: uhub_attach: port 5 power on failed, >>>> USB_ERR_STALLED >>>> Feb 4 21:17:47 FS kernel: uhub_attach: port 6 power on failed, >>>> USB_ERR_STALLED >>>> Feb 4 21:17:47 FS kernel: uhub_attach: port 7 power on failed, >>>> USB_ERR_STALLED >>>> Feb 4 21:17:47 FS kernel: uhub6: 7 ports with 7 removable, self powered >>>> >>>> FS/karl:/disk/karl> usbconfig -u 4 -a 4 dump_device_desc >>>> ugen4.4: <product 0x0050 vendor 0x0409> at usbus4, cfg=0 md=HOST >>>> spd=HIGH (480Mbps) pwr=SAVE >>>> >>>> bLength = 0x0012 >>>> bDescriptorType = 0x0001 >>>> bcdUSB = 0x0200 >>>> bDeviceClass = 0x0009 >>>> bDeviceSubClass = 0x0000 >>>> bDeviceProtocol = 0x0001 >>>> bMaxPacketSize0 = 0x0040 >>>> idVendor = 0x0409 >>>> idProduct = 0x0050 >>>> bcdDevice = 0x0100 >>>> iManufacturer = 0x0000 <no string> >>>> iProduct = 0x0000 <no string> >>>> iSerialNumber = 0x0000 <no string> >>>> bNumConfigurations = 0x0001 >>>> >>>> I then issue and get: >>>> FS/karl:/disk/karl> usbconfig -u 4 -a 4 power_on >>>> FS/karl:/disk/karl> usbconfig -u 4 -a 4 dump_device_desc >>>> ugen4.4: <product 0x0050 vendor 0x0409> at usbus4, cfg=0 md=HOST >>>> spd=HIGH (480Mbps) pwr=ON >>>> >>>> bLength = 0x0012 >>>> bDescriptorType = 0x0001 >>>> bcdUSB = 0x0200 >>>> bDeviceClass = 0x0009 >>>> bDeviceSubClass = 0x0000 >>>> bDeviceProtocol = 0x0001 >>>> bMaxPacketSize0 = 0x0040 >>>> idVendor = 0x0409 >>>> idProduct = 0x0050 >>>> bcdDevice = 0x0100 >>>> iManufacturer = 0x0000 <no string> >>>> iProduct = 0x0000 <no string> >>>> iSerialNumber = 0x0000 <no string> >>>> bNumConfigurations = 0x0001 >>>> >>>> And if I turn it off and back on (power_off then power_on) the cycle >>>> repeats. An attempt to reset is also futile, although the command is >>>> accepted. >>>> >>>> If I turn on hw.usb.uhub.debug I get a never-ending string of these: >>>> >>>> Feb 4 21:29:12 FS kernel: usb_needs_explore: >>>> Feb 4 21:29:12 FS kernel: usb_bus_powerd: bus=0xc646ac78 >>>> Feb 4 21:29:12 FS kernel: usb_needs_explore: >>>> Feb 4 21:29:12 FS kernel: usb_bus_powerd: bus=0xc646ac78 >>>> Feb 4 21:29:12 FS kernel: usb_needs_explore: >>>> Feb 4 21:29:12 FS kernel: usb_bus_powerd: bus=0xc646ac78 >>>> Feb 4 21:29:12 FS kernel: usb_needs_explore: >>>> Feb 4 21:29:12 FS kernel: usb_bus_powerd: bus=0xc646ac78 >>>> Feb 4 21:29:12 FS kernel: usb_needs_explore: >>>> Feb 4 21:29:12 FS kernel: usb_bus_powerd: bus=0xc646ac78 >>>> Feb 4 21:29:13 FS kernel: usb_needs_explore: >>>> Feb 4 21:29:13 FS kernel: usb_bus_powerd: bus=0xc646ac78 >>>> Feb 4 21:29:13 FS kernel: usb_needs_explore: >>>> Feb 4 21:29:13 FS kernel: usb_bus_powerd: bus=0xc646ac78 >>>> Feb 4 21:29:13 FS kernel: usb_needs_explore: >>>> Feb 4 21:29:13 FS kernel: usb_bus_powerd: bus=0xc646ac78 >>>> Feb 4 21:29:13 FS kernel: usb_needs_explore: >>>> Feb 4 21:29:13 FS kernel: usb_bus_powerd: bus=0xc646ac78 >>>> >>>> Until the power is turned off on the device (with "usbconfig -u 4 -a 4 >>>> power_off"), when it settles down to this once in a while: >>>> >>>> Feb 4 21:29:26 FS kernel: usb_needs_explore: >>>> Feb 4 21:29:26 FS kernel: usb_bus_powerd: bus=0xc6429cf0 >>>> Feb 4 21:29:26 FS kernel: usb_bus_powerd: Recomputing power masks >>>> Feb 4 21:29:26 FS kernel: usb_bus_powerd: Recomputing power masks >>>> Feb 4 21:29:26 FS kernel: usb_needs_explore: >>>> Feb 4 21:29:26 FS kernel: usb_bus_powerd: bus=0xc6440cf0 >>>> Feb 4 21:29:26 FS kernel: usb_bus_powerd: Recomputing power masks >>>> Feb 4 21:29:26 FS kernel: usb_bus_powerd: bus=0xc6451cf0 >>>> Feb 4 21:29:26 FS kernel: usb_bus_powerd: Recomputing power masks >>>> >>> Ok, bizarro-land update. >>> >>> The KVM (which talks to the box over USB for keyboard and mouse) >>> interferes with the FTDI adapter! >>> >>> I have absolutely NO idea why, but if it's not plugged in the FTDI >>> adapter comes up instantly. Of course then I can't KVM into the box, >>> which creates its own set of problems. >>> >>> ARGH. >>> >>> Ok, now to figure out how to run this down. There has to be a way..... >>> ideas? >> Smells like power supply, to me. Consider trying a different one, or better; >> use one with a higher output rating. :) >> >> --Chris > Uh, definitely not. > > Confirmed on multiple boxes now, all running 9.1-Stable. The KVM, if > connected, zorches the FTDI box. Understood. I was referring to the _computers_ power supply. :) --Chris P.S. sorry for the duplicate, I used the wrong _from_address in the other. :/ > > -- > -- Karl Denninger > /The Market Ticker ®/ <http://market-ticker.org>; > Cuda Systems LLC > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?d53b22c7663468baa3df789c9bb4716a.authenticated>