Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 04 Feb 2013 22:42:24 -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:  <51108DB0.7050403@denninger.net>
In-Reply-To: <51107D82.8040605@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>

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?

-- 
-- 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?51108DB0.7050403>