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 -- -- 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]"
