Re: Ports and WITH_LIBCPLUSPLUS

[Volodymyr Kostyrko]

03.02.2013 15:28, Dimitry Andric:

Thanks for trying this out.  Is there also a list of ports that *do*
compile (and hopefully run) successfully? :-)


I already switched to libc++ on my unstable STABLE-9 machines. Currently 
I'm using this config:


*: CXXFLAGS= -stdlib=libc++ -std=c++11 | LDFLAGS= -stdlib=libc++

audio/flac databases/db5 devel/binutils devel/doxygen devel/qt4-designer 
devel/qt4-qt3support devel/qt4-script devel/yasm graphics/libopenraw 
graphics/tesseract lang/gcc multimedia/phonon-gstreamer 
net-p2p/transmission-cli net-p2p/transmission-daemon 
sysutils/smartmontools textproc/hunspell www/qt4-webkit 
x11/nvidia-driver x11/qt4-opengl: !CXXFLAGS | !LDFLAGS


databases/mariadb-client emulators/pearpc www/libxul 
x11-toolkits/qt4-gui: USE_GCC=4.6+ | !CXXFLAGS | !LDFLAGS


www/squid32: USE_GCC=any | !CXXFLAGS | !LDFLAGS

Currently I have working seamonkey and slim built this way.

> ldd `which seamonkey`
/usr/local/bin/seamonkey:
libm.so.5 => /lib/libm.so.5 (0x800846000)
libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x800a65000)
libc++.so.1 => /usr/lib/libc++.so.1 (0x800c7e000)
libthr.so.3 => /lib/libthr.so.3 (0x800f34000)
libc.so.7 => /lib/libc.so.7 (0x801156000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x8014a5000)

I can post whole list of packages if anyone is interested. Everything 
looks even better then when clang was introduced to ports - almost any 
package works, the ones that doesn't just have a complicated 
build/install process. No painful glitches yet.


--
Sphinx of black quartz, judge my vow.
___
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"

Re: stable/9: Force ada1 to UDMA-33

[Oliver Fromme]

Ian Lepore wrote:
 > On Fri, 2013-02-01 at 19:52 +0100, Oliver Fromme wrote:
 > > What is the proper way with ATA_CAM and ada(4) to force a
 > > P-ATA disk to a lower UDMA mode?
 > 
 > You probably want one of these...
 > 
 > hint.ata.X.devX.mode
 >  limits initial ATA mode for specified device on specified channel.
 > 
 >  hint.ata.X.mode
 >  limits initial ATA mode for every device on specified channel.
 > 
 > These are from ata(4) manpage, there are some others there as well.

Thank you!

It's embarassing I didn't check ata(4) ...  I looked at
ada(4), atacontrol, camcontrol and a few others, even
Google didn't reveal anything.

Best regards
   Oliver

-- 
Oliver Fromme,  secnetix GmbH & Co. KG,  Marktplatz 29, 85567 Grafing
Handelsregister:  Amtsgericht Muenchen, HRA 74606, Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsreg.: Amtsgericht München,
HRB 125758, Geschäftsführer:  Maik Bachmann,  Olaf Erb,  Ralf Gebhart

FreeBSD-Dienstleistungen/-Produkte + mehr: http://www.secnetix.de/bsd

"C++ is to C as Lung Cancer is to Lung."
-- Thomas Funke
___
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"

re(4) problems with GA-H77N-WIFI

[Oliver Fromme]

Hello,

I need some advice how to debug this issue ...

Recently I got a new mainboard for a router, it's a
Gigabyte GA-H77N-WIFI with two onboard re(4) NICs.

The problem is that re0 works fine and re1 doesn't:
It doesn't receive any packets.  Tcpdump displays all
outgoing packets, but no incoming ones on re1.
Ifconfig shows the link correctly (100 or 1000 Mbit,
depending on where I plug the cable in).
I also swapped cables just to be sure, but it made no
difference.

I'm running a recent stable/9 (about 14 days old).
What's the best way to debug this problem?  At the
moment I'm not even sure if it's the hardware, or if
it's FreeBSD's fault (or my fault) ...

Best regards
   Oliver

PS:  dmesg ...

pcib2:  irq 16 at device 28.4 on pci0
pci2:  on pcib2
re0:  port 
0xe000-0xe0ff mem 0xf0104000-0xf0104fff,0xf010-0xf0103fff irq 16 at device 
0.0 on pci2
re0: Using 1 MSI-X message
re0: Chip rev. 0x2c80
re0: MAC rev. 0x
miibus0:  on re0
rgephy0:  PHY 1 on miibus0
rgephy0:  none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 
100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 
1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, 
auto-flow
re0: Ethernet address: 90:2b:34:5f:bd:21
pcib3:  irq 17 at device 28.5 on pci0
pci3:  on pcib3
re1:  port 
0xd000-0xd0ff mem 0xf0004000-0xf0004fff,0xf000-0xf0003fff irq 17 at device 
0.0 on pci3
re1: Using 1 MSI-X message
re1: Chip rev. 0x2c80
re1: MAC rev. 0x
miibus1:  on re1
rgephy1:  PHY 1 on miibus1
rgephy1:  none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 
100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 
1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, 
auto-flow
re1: Ethernet address: 90:2b:34:5f:bd:11

ifconfig ...

re0: flags=8843 metric 0 mtu 1500

options=8209b
ether 90:2b:34:5f:bd:21
inet ...
nd6 options=21
media: Ethernet autoselect (1000baseT )
status: active
re1: flags=8843 metric 0 mtu 1500

options=8209b
ether 90:2b:34:5f:bd:11
inet ...
nd6 options=21
media: Ethernet autoselect (100baseTX )
status: active



-- 
Oliver Fromme,  secnetix GmbH & Co. KG,  Marktplatz 29, 85567 Grafing
Handelsregister:  Amtsgericht Muenchen, HRA 74606, Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsreg.: Amtsgericht München,
HRB 125758, Geschäftsführer:  Maik Bachmann,  Olaf Erb,  Ralf Gebhart

FreeBSD-Dienstleistungen/-Produkte + mehr: http://www.secnetix.de/bsd

"That's what I love about GUIs: They make simple tasks easier,
and complex tasks impossible."
-- John William Chambless
___
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"

Re: re(4) problems with GA-H77N-WIFI

[John-Mark Gurney]

Oliver Fromme wrote this message on Mon, Feb 04, 2013 at 19:15 +0100:
> I'm running a recent stable/9 (about 14 days old).
> What's the best way to debug this problem?  At the
> moment I'm not even sure if it's the hardware, or if
> it's FreeBSD's fault (or my fault) ...

Have you tried to disable msi and msix?

hw.pci.enable_msix: 1
hw.pci.enable_msi: 1

It could be your motherboard doesn't handle MSI and/or MSI-X properly...

[...]

> re0: Using 1 MSI-X message

[...]

> re1: Using 1 MSI-X message

-- 
  John-Mark Gurney  Voice: +1 415 225 5579

 "All that I will do, has been done, All that I have, has not."
___
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"

So I whip out a FTDI-based multiport Serial USB Adapter....

[Karl Denninger]

... and plug it into FreeBSD 9.1-Stable with the rev ID FreeBSD
9.1-STABLE #16 r244942

and it returns

ugen4.4:  at usbus4
uhub6: 
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?

-- 
-- Karl Denninger
/The Market Ticker ®/ 
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-unsubscr...@freebsd.org"

Re: So I whip out a FTDI-based multiport Serial USB Adapter....

[Ian Lepore]

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:  at usbus4
> uhub6: 
> 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


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

Re: So I whip out a FTDI-based multiport Serial USB Adapter....

[Karl Denninger]

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:  at usbus4
>> uhub6: 
>> 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

It appears there is no declaration in any of the NEC constants in any of
the source or header files (other than usbdevs) in the
/usr/src/sys/dev/usb tree, so I'm unsure where it's getting the "7"
ports it is trying to attach, since there are 8 in the box and I can't
find a use of the tuple that it IDs under from the usbdevs declarations.

Am I correct that if I was to add this pair to the serial/uftdi.c file
where the structure is set up it should (might?) recognize it?

There's no way to do this on a runtime basis, yes?

-- 
-- Karl Denninger
/The Market Ticker ®/ 
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-unsubscr...@freebsd.org"

Re: So I whip out a FTDI-based multiport Serial USB Adapter....

[Karl Denninger]

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:  at usbus4
>> uhub6: 
>> 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.

-- 
-- Karl Denninger
/The Market Ticker ®/ 
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-unsubscr...@freebsd.org"

Re: So I whip out a FTDI-based multiport Serial USB Adapter....

[CeDeROM]

On Mon, Feb 4, 2013 at 9:06 PM, Ian Lepore  wrote:
> 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.

I also want to use my KT-LINK multipurpose low-level embedded access
multitool based on FT2232H with RS232 port and I was worried there is
no driver - right now I will add the PID and recompile sources to see
if it works - happy to catch this thread :-)

Some questions as you Ian seem to already have experience with this devices:
1. Is it possible to compile only uftdi driver and load it into
existing kernel that have this driver compiled-in so I don't have to
recompile whole kernel and all of the modules?
2. Is it possible to pass VID/PID and/or RS232 channel as kernel
loadable option? This would again spare some build/runtime time for me
:-)
3. Do you know a good method on kernel module testing other than
rebuilding/rebooting all the time? VirtualBox + USB Attach?

Any hints appreciated! :-)
Tomek

-- 
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
___
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"

Re: So I whip out a FTDI-based multiport Serial USB Adapter....

[Ian Lepore]

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:  at usbus4
> >> uhub6: 
> >> 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.  Or the usb serial device is damaged
somehow so that the vendor and product ID are reading as garbage and
being mistaken for a hub.

Have you tried the ftdi adapter on another port/hub/computer?  Have you
tried plugging something else into the port you're trying to use for the
ftdi adapter, like a thumb drive or something?

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

Re: So I whip out a FTDI-based multiport Serial USB Adapter....

[Ian Lepore]

On Mon, 2013-02-04 at 22:05 +0100, CeDeROM wrote:
> On Mon, Feb 4, 2013 at 9:06 PM, Ian Lepore  wrote:
> > 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.
> 
> I also want to use my KT-LINK multipurpose low-level embedded access
> multitool based on FT2232H with RS232 port and I was worried there is
> no driver - right now I will add the PID and recompile sources to see
> if it works - happy to catch this thread :-)
> 
> Some questions as you Ian seem to already have experience with this devices:
> 1. Is it possible to compile only uftdi driver and load it into
> existing kernel that have this driver compiled-in so I don't have to
> recompile whole kernel and all of the modules?
> 2. Is it possible to pass VID/PID and/or RS232 channel as kernel
> loadable option? This would again spare some build/runtime time for me
> :-)
> 3. Do you know a good method on kernel module testing other than
> rebuilding/rebooting all the time? VirtualBox + USB Attach?
> 
> Any hints appreciated! :-)
> Tomek
> 

If you don't already have the right devices compiled in, just build the
usb/ucom and usb/uftdi modules and kldload uftdi and you should be good
to go.

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

Re: So I whip out a FTDI-based multiport Serial USB Adapter....

[Karl Denninger]

On 2/4/2013 3: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:  at usbus4
 uhub6: 
 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.  Or the usb serial device is damaged
> somehow so that the vendor and product ID are reading as garbage and
> being mistaken for a hub.
>
> Have you tried the ftdi adapter on another port/hub/computer?  Have you
> tried plugging something else into the port you're trying to use for the
> ftdi adapter, like a thumb drive or something?
>
> -- Ian

The machine is fine.  The adapter is fine too -- I powered up the old
machine and it works too, and recognizes the adapter immediately (on
FreeBSD-Stable 7.)  No problems with either.

I get identical behavior on multiple ports on the back of the machine
and the machine itself is known to be ok and has a USB KVM attached to
it which is working, along with a USB-communicating UPS which is also
working.

When I added the definition it picked it up as an 8-port adapter with 8
FTDI ports on it, but then it ALSO tried to attach it as a 7-port hub
(which is what usbdevs says it is) -- although I cannot find ANYWHERE in
the code under that directory that references that VID/PID tuple.   The
second attachment attempt blew up the first (which makes sense.)

Since the code obviously does know how to find hubs, there has to be
something else going on -- digging through it now to see if I can
isolate how it determines something is a "hub" without having a
structure with all the hubs defined in it, which I cannot find.

-- 
-- Karl Denninger
/The Market Ticker ®/ 
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-unsubscr...@freebsd.org"

Re: So I whip out a FTDI-based multiport Serial USB Adapter....

[CeDeROM]

On Mon, Feb 4, 2013 at 10:20 PM, Karl Denninger  wrote:
> The machine is fine.  The adapter is fine too -- I powered up the old
> machine and it works too, and recognizes the adapter immediately (on
> FreeBSD-Stable 7.)  No problems with either.

Hello Karl :-) Is VID/PID the same after attach to both machines? Does
"usbconfig dump_all_config_desc" returns the same values on both
machines for this adapter? Are you sure that adapter does not contain
any hub inside? FTDI should have VID 0x0403...

-- 
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
___
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"

Re: So I whip out a FTDI-based multiport Serial USB Adapter....

[Ian Lepore]

On Mon, 2013-02-04 at 15:20 -0600, Karl Denninger wrote:
> On 2/4/2013 3: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:  at usbus4
>  uhub6: 
>  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.  Or the usb serial device is damaged
> > somehow so that the vendor and product ID are reading as garbage and
> > being mistaken for a hub.
> >
> > Have you tried the ftdi adapter on another port/hub/computer?  Have you
> > tried plugging something else into the port you're trying to use for the
> > ftdi adapter, like a thumb drive or something?
> >
> > -- Ian
> 
> The machine is fine.  The adapter is fine too -- I powered up the old
> machine and it works too, and recognizes the adapter immediately (on
> FreeBSD-Stable 7.)  No problems with either.
> 
> I get identical behavior on multiple ports on the back of the machine
> and the machine itself is known to be ok and has a USB KVM attached to
> it which is working, along with a USB-communicating UPS which is also
> working.
> 
> When I added the definition it picked it up as an 8-port adapter with 8
> FTDI ports on it, but then it ALSO tried to attach it as a 7-port hub
> (which is what usbdevs says it is) -- although I cannot find ANYWHERE in
> the code under that directory that references that VID/PID tuple.   The
> second attachment attempt blew up the first (which makes sense.)
> 
> Since the code obviously does know how to find hubs, there has to be
> something else going on -- digging through it now to see if I can
> isolate how it determines something is a "hub" without having a
> structure with all the hubs defined in it, which I cannot find.
> 

Ahh, I misunderstood what you said earlier.  

This is where HPS normally shows up and starts asking for usbconfig
output using usbconfig options I have no idea how to use.  :)

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

Re: So I whip out a FTDI-based multiport Serial USB Adapter....

[Charles Sprickman]

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:  at usbus4
 uhub6: 
 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:  at usbus1
uhub4:  on 
usbus1
uhub4: 7 ports with 7 removable, self powered

Then the individual ports look like this:

ugen1.4:  at usbus1
uftdi0:  on usbus1
ugen1.5:  at usbus1
uftdi1:  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

>  Or the usb serial device is damaged
> somehow so that the vendor and product ID are reading as garbage and
> being mistaken for a hub.
> 
> Have you tried the ftdi adapter on another port/hub/computer?  Have you
> tried plugging something else into the port you're trying to use for the
> ftdi adapter, like a thumb drive or something?
> 
> -- 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"

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

Re: So I whip out a FTDI-based multiport Serial USB Adapter....

[Ian Lepore]

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:  at usbus4
>  uhub6: 
>  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:  at usbus1
> uhub4:  on 
> usbus1
> uhub4: 7 ports with 7 removable, self powered
> 
> Then the individual ports look like this:
> 
> ugen1.4:  at usbus1
> uftdi0:  on usbus1
> ugen1.5:  at usbus1
> uftdi1:  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"

Re: re(4) problems with GA-H77N-WIFI

[Oliver Fromme]

John-Mark Gurney wrote:
 > Oliver Fromme wrote this message on Mon, Feb 04, 2013 at 19:15 +0100:
 > > I'm running a recent stable/9 (about 14 days old).
 > > What's the best way to debug this problem?  At the
 > > moment I'm not even sure if it's the hardware, or if
 > > it's FreeBSD's fault (or my fault) ...
 > 
 > Have you tried to disable msi and msix?
 > 
 > hw.pci.enable_msix: 1
 > hw.pci.enable_msi: 1

I tried these entries in /boot/loader.conf, according to
the re(4) manual page:

hw.re.msi_disable="1"
hw.re.msix_disable="1"

Unfortunately it didn't make a difference.

Best regards
   Oliver



-- 
Oliver Fromme,  secnetix GmbH & Co. KG,  Marktplatz 29, 85567 Grafing
Handelsregister:  Amtsgericht Muenchen, HRA 74606, Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsreg.: Amtsgericht München,
HRB 125758, Geschäftsführer:  Maik Bachmann,  Olaf Erb,  Ralf Gebhart

FreeBSD-Dienstleistungen/-Produkte + mehr: http://www.secnetix.de/bsd

"The scanf() function is a large and complex beast that often does
something almost but not quite entirely unlike what you desired."
-- Chris Torek
___
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"

Re: re(4) problems with GA-H77N-WIFI

[John-Mark Gurney]

Oliver Fromme wrote this message on Mon, Feb 04, 2013 at 23:04 +0100:
> John-Mark Gurney wrote:
>  > Oliver Fromme wrote this message on Mon, Feb 04, 2013 at 19:15 +0100:
>  > > I'm running a recent stable/9 (about 14 days old).
>  > > What's the best way to debug this problem?  At the
>  > > moment I'm not even sure if it's the hardware, or if
>  > > it's FreeBSD's fault (or my fault) ...
>  > 
>  > Have you tried to disable msi and msix?
>  > 
>  > hw.pci.enable_msix: 1
>  > hw.pci.enable_msi: 1
> 
> I tried these entries in /boot/loader.conf, according to
> the re(4) manual page:
> 
> hw.re.msi_disable="1"
> hw.re.msix_disable="1"
> 
> Unfortunately it didn't make a difference.

Did you try in loader.conf:
hw.pci.enable_msix="0"
hw.pci.enable_msi="0"

To disable MSI for the whole system?

-- 
  John-Mark Gurney  Voice: +1 415 225 5579

 "All that I will do, has been done, All that I have, has not."
___
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"

Re: So I whip out a FTDI-based multiport Serial USB Adapter....

[Karl Denninger]

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:  at usbus4
>> uhub6: 
>> 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:  at usbus1
>> uhub4:  on 
>> usbus1
>> uhub4: 7 ports with 7 removable, self powered
>>
>> Then the individual ports look like this:
>>
>> ugen1.4:  at usbus1
>> uftdi0:  on usbus1
>> ugen1.5:  at usbus1
>> uftdi1:  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 ®/ 
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-unsubscr...@freebsd.org"

Re: So I whip out a FTDI-based multiport Serial USB Adapter....

[Charles Sprickman]

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:  at usbus4
>> uhub6: 
>> 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:  at usbus1
>> uhub4:  on 
>> usbus1
>> uhub4: 7 ports with 7 removable, self powered
>> 
>> Then the individual ports look like this:
>> 
>> ugen1.4:  at usbus1
>> uftdi0:  on usbus1
>> ugen1.5:  at usbus1
>> uftdi1:  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

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

Re: stable/9 r245439 breaks security/pam_ssh_agent_auth on stable/9 (WAS: CLANG 3.2 breaks security/pam_ssh_agent_auth on stable/9)

[Kimmo Paasiala]

On Sun, Feb 3, 2013 at 7:22 PM, Chris Rees  wrote:
> On 3 February 2013 17:15, Stefan Bethke  wrote:
>>
>> Am 03.02.2013 um 10:57 schrieb Chris Rees :
>>
>>> On 3 February 2013 03:55, Kimmo Paasiala  wrote:

 There is no PR yet with my fix and therefor no commit to ports tree
 that would fix the problem. I'll file a PR soon (TM).
>>>
>>> The problem was in base, and is fixed there.
>>
>> Huh? With -current r246283, I still get a segfault from sudo unless I have 
>> Kimmo's patch.
>>
>> Is there some confusion about which problem is addressed by Kimmo's patch?
>>
>
> Hm, perhaps it might be necessary then.
>
> Kimmo, please would you submit the patch you had as a PR?  I'm sure
> Wesley would appreciate the hint.
>
> Chris

I'll file a PR when I have recovered from a nasty flu. Right now I'm
not fit for thinking...

I changed the title of this thread to a better one.

-Kimmo
___
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"

[releng_9 tinderbox] failure on ia64/ia64

[FreeBSD Tinderbox]

TB --- 2013-02-04 23:59:00 - tinderbox 2.10 running on freebsd-stable.sentex.ca
TB --- 2013-02-04 23:59:00 - FreeBSD freebsd-stable.sentex.ca 8.3-STABLE 
FreeBSD 8.3-STABLE #0: Tue Oct 16 17:37:58 UTC 2012 
mdtan...@freebsd-stable.sentex.ca:/usr/obj/usr/src/sys/server  amd64
TB --- 2013-02-04 23:59:00 - starting RELENG_9 tinderbox run for ia64/ia64
TB --- 2013-02-04 23:59:00 - cleaning the object tree
TB --- 2013-02-04 23:59:00 - checking out /src from 
svn://svn.freebsd.org/base/stable/9
TB --- 2013-02-04 23:59:00 - cd /tinderbox/RELENG_9/ia64/ia64
TB --- 2013-02-04 23:59:00 - /usr/local/bin/svn cleanup /src
TB --- 2013-02-05 00:00:13 - /usr/local/bin/svn update /src
TB --- 2013-02-05 00:00:21 - building world
TB --- 2013-02-05 00:00:21 - CROSS_BUILD_TESTING=YES
TB --- 2013-02-05 00:00:21 - MAKEOBJDIRPREFIX=/obj
TB --- 2013-02-05 00:00:21 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2013-02-05 00:00:21 - SRCCONF=/dev/null
TB --- 2013-02-05 00:00:21 - TARGET=ia64
TB --- 2013-02-05 00:00:21 - TARGET_ARCH=ia64
TB --- 2013-02-05 00:00:21 - TZ=UTC
TB --- 2013-02-05 00:00:21 - __MAKE_CONF=/dev/null
TB --- 2013-02-05 00:00:21 - cd /src
TB --- 2013-02-05 00:00:21 - /usr/bin/make -B buildworld
>>> World build started on Tue Feb  5 00:00:22 UTC 2013
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3: cross tools
>>> stage 4.1: building includes
>>> stage 4.2: building libraries
>>> stage 4.3: make dependencies
>>> stage 4.4: building everything
>>> World build completed on Tue Feb  5 01:53:19 UTC 2013
TB --- 2013-02-05 01:53:19 - generating LINT kernel config
TB --- 2013-02-05 01:53:19 - cd /src/sys/ia64/conf
TB --- 2013-02-05 01:53:19 - /usr/bin/make -B LINT
TB --- 2013-02-05 01:53:19 - cd /src/sys/ia64/conf
TB --- 2013-02-05 01:53:19 - /usr/sbin/config -m LINT
TB --- 2013-02-05 01:53:19 - building LINT kernel
TB --- 2013-02-05 01:53:19 - CROSS_BUILD_TESTING=YES
TB --- 2013-02-05 01:53:19 - MAKEOBJDIRPREFIX=/obj
TB --- 2013-02-05 01:53:19 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2013-02-05 01:53:19 - SRCCONF=/dev/null
TB --- 2013-02-05 01:53:19 - TARGET=ia64
TB --- 2013-02-05 01:53:19 - TARGET_ARCH=ia64
TB --- 2013-02-05 01:53:19 - TZ=UTC
TB --- 2013-02-05 01:53:19 - __MAKE_CONF=/dev/null
TB --- 2013-02-05 01:53:19 - cd /src
TB --- 2013-02-05 01:53:19 - /usr/bin/make -B buildkernel KERNCONF=LINT
>>> Kernel build for LINT started on Tue Feb  5 01:53:20 UTC 2013
>>> stage 1: configuring the kernel
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3.1: making dependencies
>>> stage 3.2: building everything
>>> Kernel build for LINT completed on Tue Feb  5 02:37:05 UTC 2013
TB --- 2013-02-05 02:37:05 - cd /src/sys/ia64/conf
TB --- 2013-02-05 02:37:05 - /usr/sbin/config -m GENERIC
TB --- 2013-02-05 02:37:05 - building GENERIC kernel
TB --- 2013-02-05 02:37:05 - CROSS_BUILD_TESTING=YES
TB --- 2013-02-05 02:37:05 - MAKEOBJDIRPREFIX=/obj
TB --- 2013-02-05 02:37:05 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2013-02-05 02:37:05 - SRCCONF=/dev/null
TB --- 2013-02-05 02:37:05 - TARGET=ia64
TB --- 2013-02-05 02:37:05 - TARGET_ARCH=ia64
TB --- 2013-02-05 02:37:05 - TZ=UTC
TB --- 2013-02-05 02:37:05 - __MAKE_CONF=/dev/null
TB --- 2013-02-05 02:37:05 - cd /src
TB --- 2013-02-05 02:37:05 - /usr/bin/make -B buildkernel KERNCONF=GENERIC
>>> Kernel build for GENERIC started on Tue Feb  5 02:37:05 UTC 2013
>>> stage 1: configuring the kernel
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3.1: making dependencies
>>> stage 3.2: building everything
[...]
/src/sys/dev/firewire/if_fwip.c:499: undefined reference to 
`crom_add_simple_text'
/src/sys/dev/firewire/if_fwip.c:500: undefined reference to `crom_add_entry'
/src/sys/dev/firewire/if_fwip.c:501: undefined reference to 
`crom_add_simple_text'
if_fwip.o: In function `fwip_stream_input':
/src/sys/dev/firewire/if_fwip.c:840: undefined reference to 
`fw_noderesolve_nodeid'
if_fwip.o: In function `fwip_unicast_input':
/src/sys/dev/firewire/if_fwip.c:939: undefined reference to 
`fw_noderesolve_nodeid'
if_fwip.o:(.data.rel+0x80): undefined reference to 
`sysctl__hw_firewire_children'
*** Error code 1

Stop in /obj/ia64.ia64/src/sys/GENERIC.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2013-02-05 02:47:22 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2013-02-05 02:47:22 - ERROR: failed to build GENERIC kernel
TB --- 2013-02-05 02:47:22 - 7168.30 user 858.03 system 10102.42 real


http://tinderbox.freebsd.org/tinderbox-releng_9-RELENG_9-ia64-ia64.full
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send an

Re: So I whip out a FTDI-based multiport Serial USB Adapter....

[Karl Denninger]

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:  at usbus4
>>> uhub6: 
>>> 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:  at usbus1
>>> uhub4:  on 
>>> usbus1
>>> uhub4: 7 ports with 7 removable, self powered
>>>
>>> Then the individual ports look like this:
>>>
>>> ugen1.4:  at usbus1
>>> uftdi0:  on usbus1
>>> ugen1.5:  at usbus1
>>> uftdi1:  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.

-- 
-- Karl Denninger
/The Market Ticker ®/ 
Cuda Systems LLC
___
freebsd-stable@freebsd.org mailing list
http://lists.fre

Re: So I whip out a FTDI-based multiport Serial USB Adapter....

[Karl Denninger]

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:  at usbus4
 uhub6: 
 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:  at usbus1
 uhub4:  on 
 usbus1
 uhub4: 7 ports with 7 removable, self powered

 Then the individual ports look like this:

 ugen1.4:  at usbus1
 uftdi0:  on usbus1
 ugen1.5:  at usbus1
 uftdi1:  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 bac

Re: So I whip out a FTDI-based multiport Serial USB Adapter....

[Karl Denninger]

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:  at usbus4
> uhub6:  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:  at usbus1
> uhub4:  
> on usbus1
> uhub4: 7 ports with 7 removable, self powered
>
> Then the individual ports look like this:
>
> ugen1.4:  at usbus1
> uftdi0:  on usbus1
> ugen1.5:  at usbus1
> uftdi1:  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 l