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