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 _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
