Date: Tue, 5 Feb 2013 08:15:30 -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.... Message-ID: <bff299b8dda6a83befb45c67ad905944.authenticated@ultimatedns.net> In-Reply-To: <51108DB0.7050403@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>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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? Smells like power supply, to me. Consider trying a different one, or better; use one with a higher output rating. :) --Chris > > -- > -- 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?bff299b8dda6a83befb45c67ad905944.authenticated>