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: >>> On Feb 4, 2013, at 5:00 PM, Ian Lepore wrote: >>> >>>> On Mon, 2013-02-04 at 16:31 -0500, Charles Sprickman wrote: >>>>> On Feb 4, 2013, at 4:13 PM, Ian Lepore wrote: >>>>> >>>>>> On Mon, 2013-02-04 at 14:58 -0600, Karl Denninger wrote: >>>>>>> On 2/4/2013 2:06 PM, Ian Lepore wrote: >>>>>>>> On Mon, 2013-02-04 at 12:57 -0600, Karl Denninger wrote: >>>>>>>>> ... and plug it into FreeBSD 9.1-Stable with the rev ID FreeBSD >>>>>>>>> 9.1-STABLE #16 r244942 >>>>>>>>> >>>>>>>>> and it returns.... >>>>>>>>> >>>>>>>>> ugen4.4: <vendor 0x0409> at usbus4 >>>>>>>>> uhub6: <vendor 0x0409 product 0x0050, class 9/0, rev 2.00/1.00, addr >>>>>>>>> 4> >>>>>>>>> on usbus4 >>>>>>>>> uhub_attach: port 1 power on failed, USB_ERR_STALLED >>>>>>>>> uhub_attach: port 2 power on failed, USB_ERR_STALLED >>>>>>>>> uhub_attach: port 3 power on failed, USB_ERR_STALLED >>>>>>>>> uhub_attach: port 4 power on failed, USB_ERR_STALLED >>>>>>>>> uhub_attach: port 5 power on failed, USB_ERR_STALLED >>>>>>>>> uhub_attach: port 6 power on failed, USB_ERR_STALLED >>>>>>>>> uhub_attach: port 7 power on failed, USB_ERR_STALLED >>>>>>>>> uhub6: 7 ports with 7 removable, self powered >>>>>>>>> >>>>>>>>> Yuck. >>>>>>>>> >>>>>>>>> The last time it was working was on a FreeBSD 7 box (yeah, I know, >>>>>>>>> rather old) but I never had problems there. And it appears that all >>>>>>>>> of >>>>>>>>> the device declarations that I used to have to put in the kernel as >>>>>>>>> non-standard stuff are now in GENERIC, so I would expect it to work. >>>>>>>>> >>>>>>>>> Ideas as to what may have gotten hosed up here? >>>>>>>>> >>>>>>>> Those messages all seem to be related to a hub. Vendor ID 0x0409 is >>>>>>>> NEC. >>>>>>>> >>>>>>>> FTDI's vendor ID is 0x0403, and FTDI stuff works fine in FreeBSD 9 and >>>>>>>> 10; I use it all the time. Sometimes aftermarket vendors who use >>>>>>>> FTDI's >>>>>>>> parts program different vendor/product info and IDs have to be added to >>>>>>>> code to recognize them, that's the only trouble one usually encounters. >>>>>>>> >>>>>>>> -- Ian >>>>>>> Well, that sorta kinda worked. >>>>>>> >>>>>>> Except that it still is identifying it as a hub too, and the two collide >>>>>>> and crash the stack. >>>>>>> >>>>>>> But I can't find anything that is looking at the PID (0x0050) or the >>>>>>> definition (HUB_0050) anywhere in the code. >>>>>>> >>>>>>> I'll go pull the NEC defs and set up something else instead of simply >>>>>>> adding it to the FTDI probe list. >>>>>>> >>>>>> It seems to me you have a problem with a hub (perhaps the root hub or a >>>>>> motherboard hub if you don't have an external one) and this has nothing >>>>>> to do with the ftdi device at all. >>>>> I assume we're talking about a multi-port usb to serial adapter, correct? >>>>> >>>>> If so, they generally do have a hub included in the device. >>>>> >>>>> Example: >>>>> >>>>> ugen1.3: <vendor 0x0409> at usbus1 >>>>> uhub4: <vendor 0x0409 product 0x0050, class 9/0, rev 2.00/1.00, addr 3> >>>>> on usbus1 >>>>> uhub4: 7 ports with 7 removable, self powered >>>>> >>>>> Then the individual ports look like this: >>>>> >>>>> ugen1.4: <FTDI> at usbus1 >>>>> uftdi0: <FT232R USB UART> on usbus1 >>>>> ugen1.5: <FTDI> at usbus1 >>>>> uftdi1: <FT232R USB UART> on usbus1 >>>>> (etc.) >>>>> >>>>> We use these for serial console ports, they're (relatively) cheap and >>>>> have generally been well supported. >>>>> >>>>> The above info is from an 8.3 box. >>>>> >>>>> Just wanted to clarify that there is likely a hub in the serial box Karl >>>>> is working with… >>>>> >>>>> Charles >>>> Oh, interesting. The biggest ftdi dongle I have is 4 ports, using the >>>> ftdi 4232 chip. I guess to get more ports than that, folks are now >>>> using an internal hub and multiple ftdi chips. >>> 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? -- -- Karl Denninger /The Market Ticker ®/ <http://market-ticker.org> Cuda Systems LLC _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[email protected]"
