Date: Tue, 05 Feb 2013 10:24:34 -0600 From: Karl Denninger <karl@denninger.net> To: 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: <51113242.4060003@denninger.net> In-Reply-To: <bff299b8dda6a83befb45c67ad905944.authenticated@ultimatedns.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>
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. -- -- Karl Denninger /The Market Ticker ®/ <http://market-ticker.org>; Cuda Systems LLC
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?51113242.4060003>