Date: Mon, 04 Feb 2013 16:29:41 -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.... Message-ID: <51103655.2080300@denninger.net> In-Reply-To: <1360015226.93359.502.camel@revolution.hippie.lan> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2/4/2013 4: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. > > 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. > > -- Ian > Ah, well then yuck. Will put things back where they were and play some more -- I'll probe this with the other box and see if I can find the difference. -- -- 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?51103655.2080300>