USB-UART device from Exar Co. not working with cdc_acm but usbserial

[Sergio De León]

Hi, I've been trying to get this device work in linux Mint Qiana
(3.13.0-24-generic) without success.

The XR21V1414 is a multiport USB-UART device. (0x04e2:0x1414)
(The driver provided "Vizzini" causes system crash due a improper
initialization of tty_port)
http://www.exar.com/common/content/default.aspx?id=10296

The cdc_acm driver creates the proper ttyACMx but there's no
communication with the device.
The only way I could get functional devices was with
# rmmod cdc_acm
# modprobe usbserial vendor=0x04e2 product=0x1414

And there's where I got the message from dmesg that I should contact to
get a proper driver for my device.

Thank you for your hard work, I hope this help to more people like me in
the future.

This is the output from lsusb, tell me if you need more information

Bus 001 Device 015: ID 04e2:1414 Exar Corp.
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 239 Miscellaneous Device
bDeviceSubClass 2 ?
bDeviceProtocol 1 Interface Association
bMaxPacketSize0 64
idVendor 0x04e2 Exar Corp.
idProduct 0x1414
bcdDevice 0.03
iManufacturer 0
iProduct 0
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 273
bNumInterfaces 8
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xc0
Self Powered
MaxPower 94mA
Interface Association:
bLength 8
bDescriptorType 11
bFirstInterface 0
bInterfaceCount 2
bFunctionClass 2 Communications
bFunctionSubClass 2 Abstract (modem)
bFunctionProtocol 0 None
iFunction 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 2 Communications
bInterfaceSubClass 2 Abstract (modem)
bInterfaceProtocol 1 AT-commands (v.25ter)
iInterface 0
CDC Header:
bcdCDC 1.10
CDC ACM:
bmCapabilities 0x06
sends break
line coding and serial state
CDC Union:
bMasterInterface 0
bSlaveInterface 1
CDC Call Management:
bmCapabilities 0x01
call management
bDataInterface 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x85 EP 5 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 2
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 10 CDC Data
bInterfaceSubClass 0 Unused
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Interface Association:
bLength 8
bDescriptorType 11
bFirstInterface 2
bInterfaceCount 2
bFunctionClass 2 Communications
bFunctionSubClass 2 Abstract (modem)
bFunctionProtocol 0 None
iFunction 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 2 Communications
bInterfaceSubClass 2 Abstract (modem)
bInterfaceProtocol 1 AT-commands (v.25ter)
iInterface 0
CDC Header:
bcdCDC 1.10
CDC ACM:
bmCapabilities 0x06
sends break
line coding and serial state
CDC Union:
bMasterInterface 2
bSlaveInterface 3
CDC Call Management:
bmCapabilities 0x01
call management
bDataInterface 3
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x86 EP 6 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 2
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 3
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 10 CDC Data
bInterfaceSubClass 0 Unused
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Interface Association:
bLength 8
bDescriptorType 11
bFirstInterface 4
bInterfaceCount 2
bFunctionClass 2 Communications
bFunctionSubClass 2 Abstract (modem)
bFunctionProtocol 0 None
iFunction 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 4
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 2 Communications
bInterfaceSubClass 2 Abstract (modem)
bInterfaceProtocol 1 AT-commands (v.25ter)
iInterface 0
CDC Header:
bcdCDC 1.10
CDC ACM:
bmCapabilities 0x06
sends break
line coding and serial state
CDC Union:
bMasterInterface 4
bSlaveInterface 5
CDC Call Management:
bmCapabilities 0x01
call management
bDataInterface 5
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x87 EP 7 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 2
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 5
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 10 CDC Data
bInterfaceSubClass 0 Unused
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03 EP 3 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Interface Association:
bLength 8
bDescriptorType 11
bFirstInterface 6
bInterfaceCount 2
bFunctionClass 2 Communications
bFunctionSubClass 2 Abstract (modem)
bFunctionProtocol 0 None
iFunction 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 6
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 2 Communications
bInterfaceSubClass 2 Abstract (modem)
bInterfaceProtocol 1 AT-commands (v.25ter)
iInterface 0
CDC Header:
bcdCDC 1.10
CDC ACM:
bmCapabilities 0x06
sends break
line coding and serial state
CDC Union:
bMasterInterface 6
bSlaveInterface 7
CDC Call Management:
bmCapabilities 0x01
call management
bDataInterface 7
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x88 EP 8 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 2
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 7
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 10 CDC Data
bInterfaceSubClass 0 Unused
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x04 EP 4 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x84 EP 4 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Device Status: 0x0001
Self Powered

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Johan Hovold]

Hi, I've been trying to get this device work in linux Mint Qiana=20
(3.13.0-24-generic) without success.
=20
The XR21V1414 is a multiport USB-UART device. (0x04e2:0x1414)
(The driver provided "Vizzini" causes system crash due a improper=20
initialization of tty_port)
http://www.exar.com/common/content/default.aspx?id=3D10296
=20
The cdc_acm driver creates the proper ttyACMx but there's no=20
communication with the device.

What does the kernel log say when you plug the device in with the
cdc-acm driver loaded?

An what happens if you enable debugging for the driver and write
something to the device?

The manufacturer seems to claim compliance with CDC (although some
extra features would be missing) so the cdc-acm driver should work.

Johan
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Johan Hovold]

Post by Johan Hovold

Hi, I've been trying to get this device work in linux Mint Qiana=20
(3.13.0-24-generic) without success.
=20
The XR21V1414 is a multiport USB-UART device. (0x04e2:0x1414)
(The driver provided "Vizzini" causes system crash due a improper=20
initialization of tty_port)
http://www.exar.com/common/content/default.aspx?id=3D10296
=20
The cdc_acm driver creates the proper ttyACMx but there's no=20
communication with the device.

=20
What does the kernel log say when you plug the device in with the
cdc-acm driver loaded?
=20
An what happens if you enable debugging for the driver and write
something to the device?
=20
The manufacturer seems to claim compliance with CDC (although some
extra features would be missing) so the cdc-acm driver should work.

By the way, have you made sure this is not simply a flow control issue?
Depending on your configuration you may have hardware flow control
enabled with cdc-acm, but that wouldn't be the case with the generic
usb-serial driver.

Johan
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Sergio De León]

Sorry for my late reply,

I still haven't tried the debug mode for cdc-acm since I still have to=20
figure out the "proper way" to get and compile the source on Linux Mint=
=20
(it seems some documentation is old... but mostly I've been a little=20
busy to dig deeper).

About the hardware flow control, I remember tried every combination of=20
flow control and line endings (because the receiving end might only=20
accept one kind of line break) with minicom, but I'll try again.

I had some suspicions about what could be the problem with this device=20
since it's a 8 gsm modem pool interfaced with these chips and just one=20
usb port (Host -> integraded HUB -> XR21V1414) but after test it on=20
WinXP with putty and using the same settings on linux putty, I thought=20
that it might be a problem with the driver. That moment I went to=20
investigate the alternatives of cdc-acm and read about usbserial as=20
testing platform and the drivers included with.

I'm sorry if I take a while to get the logs you asked me, I hope to hav=
e=20
them around the weekend.

Sergio

Post by Johan Hovold

Post by Sergio De León
Hi, I've been trying to get this device work in linux Mint Qiana
(3.13.0-24-generic) without success.
The XR21V1414 is a multiport USB-UART device. (0x04e2:0x1414)
(The driver provided "Vizzini" causes system crash due a improper
initialization of tty_port)
http://www.exar.com/common/content/default.aspx?id=3D10296
The cdc_acm driver creates the proper ttyACMx but there's no
communication with the device.

What does the kernel log say when you plug the device in with the
cdc-acm driver loaded?
An what happens if you enable debugging for the driver and write
something to the device?
The manufacturer seems to claim compliance with CDC (although some
extra features would be missing) so the cdc-acm driver should work.

By the way, have you made sure this is not simply a flow control issu=

e?

Depending on your configuration you may have hardware flow control
enabled with cdc-acm, but that wouldn't be the case with the generic
usb-serial driver.
Johan

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Johan Hovold]

[ Please avoid top posting. ]

Post by Sergio De León
Sorry for my late reply,
=20
I still haven't tried the debug mode for cdc-acm since I still have t=

o=20

Post by Sergio De León
figure out the "proper way" to get and compile the source on Linux Mi=

nt=20

Post by Sergio De León
(it seems some documentation is old... but mostly I've been a little=20
busy to dig deeper).

That might not be necessary if your kernel is compiled with dynamic
debugging support:

zcat /proc/config.gz | grep CONFIG_DYNAMIC_DEBUG

Post by Sergio De León
About the hardware flow control, I remember tried every combination o=

f=20

Post by Sergio De León
flow control and line endings (because the receiving end might only=20
accept one kind of line break) with minicom, but I'll try again.

Note also that settings such as baud rate and stop bits would only have
an effect with the cdc-acm driver, whereas the generic usb-serial drive=
r
has no way of configuring these and hence the defaults would be used.

Post by Sergio De León
I had some suspicions about what could be the problem with this devic=

e=20

Post by Sergio De León
since it's a 8 gsm modem pool interfaced with these chips and just on=

e=20

Post by Sergio De León
usb port (Host -> integraded HUB -> XR21V1414) but after test it on=20
WinXP with putty and using the same settings on linux putty, I though=

t=20

Post by Sergio De León
that it might be a problem with the driver. That moment I went to=20
investigate the alternatives of cdc-acm and read about usbserial as=20
testing platform and the drivers included with.
=20
I'm sorry if I take a while to get the logs you asked me, I hope to h=

ave=20

Post by Sergio De León
them around the weekend.

Good luck,
Johan
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Sergio De León]

Hi Johan

Here are the debug logs you asked me

* dmesg output while connecting the device without dynamic debug
* dmesg output while connecting the device with dynamic debug
* .../dynamic_debug/control active rules for cdc_acm
* dmesg output with dyndbg while opening the port, writting to the port
and closing the port.

Regards

Sergio De León

Post by Johan Hovold
[ Please avoid top posting. ]

Post by Sergio De León
Sorry for my late reply,
I still haven't tried the debug mode for cdc-acm since I still have to
figure out the "proper way" to get and compile the source on Linux Mint
(it seems some documentation is old... but mostly I've been a little
busy to dig deeper).

That might not be necessary if your kernel is compiled with dynamic
zcat /proc/config.gz | grep CONFIG_DYNAMIC_DEBUG

Post by Sergio De León
About the hardware flow control, I remember tried every combination of
flow control and line endings (because the receiving end might only
accept one kind of line break) with minicom, but I'll try again.

Note also that settings such as baud rate and stop bits would only have
an effect with the cdc-acm driver, whereas the generic usb-serial driver
has no way of configuring these and hence the defaults would be used.

Post by Sergio De León
I had some suspicions about what could be the problem with this device
since it's a 8 gsm modem pool interfaced with these chips and just one
usb port (Host -> integraded HUB -> XR21V1414) but after test it on
WinXP with putty and using the same settings on linux putty, I thought
that it might be a problem with the driver. That moment I went to
investigate the alternatives of cdc-acm and read about usbserial as
testing platform and the drivers included with.
I'm sorry if I take a while to get the logs you asked me, I hope to have
them around the weekend.

Good luck,
Johan

[Johan Hovold]

Again, please do not top post.

https://en.wikipedia.org/wiki/Posting_style#Top-posting

Post by Sergio De León
Hi Johan
=20
Here are the debug logs you asked me
=20
* dmesg output while connecting the device without dynamic debug
* dmesg output while connecting the device with dynamic debug
* .../dynamic_debug/control active rules for cdc_acm
* dmesg output with dyndbg while opening the port, writting to the po=

rt=20

Post by Sergio De León
and closing the port.

I don't see anything obviously wrong in these logs.

Perhaps the device simply isn't cdc-compliant (some bits of the vendor
driver certainly indicates that) despite what the vendor claims.

Are you using the vendor driver or a generic cdc-acm driver on Windows?

I don't have time to look into this in a few days, but would you be abl=
e
to test patches that I send you? Possibly some diagnostic patches to
determine if cdc-acm can be used, and if not, a dedicated usb serial
driver?

If so, you could compile your own mainline (or stable 3.16) kernel in
the mean time so you have something to test the patches with.

Thanks,
Johan
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Sergio De León]

Post by Johan Hovold
Again, please do not top post.
https://en.wikipedia.org/wiki/Posting_style#Top-posting

Post by Sergio De León
Hi Johan
Here are the debug logs you asked me
* dmesg output while connecting the device without dynamic debug
* dmesg output while connecting the device with dynamic debug
* .../dynamic_debug/control active rules for cdc_acm
* dmesg output with dyndbg while opening the port, writting to the p=

ort

Post by Johan Hovold

Post by Sergio De León
and closing the port.

I don't see anything obviously wrong in these logs.
Perhaps the device simply isn't cdc-compliant (some bits of the vendo=

r

Post by Johan Hovold
driver certainly indicates that) despite what the vendor claims.
Are you using the vendor driver or a generic cdc-acm driver on Window=

s?

Post by Johan Hovold
I don't have time to look into this in a few days, but would you be a=

ble

Post by Johan Hovold
to test patches that I send you? Possibly some diagnostic patches to
determine if cdc-acm can be used, and if not, a dedicated usb serial
driver?
If so, you could compile your own mainline (or stable 3.16) kernel in
the mean time so you have something to test the patches with.
Thanks,
Johan

Oh thanks for the clarification about top-posting (actually I didn't se=
e=20
the message the first time).

I'm using the vendor driver on WinXP I'll test later the generic driver=
=20
of Win7 later (and if it has the WinXP). The vendor driver for linux=20
Vizzini (1) seems that it's quite buggy and some developers have alread=
y=20
given up trying to fix it (2) though there's people trying to patch it=20
(3) (I haven't tried this one, I've just found it).

Ok, I'll install the latest mainline (no RC) 3.16.1-031601-generic from=
=20
kernel.ubuntu.com. Then download the source to have some code to work=20
with and apply the patches.

Thank you for your time

Sergio



1. http://www.exar.com/common/content/default.aspx?id=3D10296
2. http://comments.gmane.org/gmane.linux.kernel.next/24133 it says he=20
was cleaning up the code, but I wonder if it would get rid of the kerne=
l=20
panic on runtime. This is a discussion about the pre ">=3D3.5" version=20
http://markmail.org/message/kvx4uiesrfpz472m.
3. https://github.com/ardje/vizzini
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Johan Hovold]

Post by Johan Hovold

Post by Sergio De León
Here are the debug logs you asked me
* dmesg output while connecting the device without dynamic debug
* dmesg output while connecting the device with dynamic debug
* .../dynamic_debug/control active rules for cdc_acm
* dmesg output with dyndbg while opening the port, writting to the=

port

Post by Johan Hovold

Post by Sergio De León
and closing the port.

I don't see anything obviously wrong in these logs.
Perhaps the device simply isn't cdc-compliant (some bits of the ven=

dor

Post by Johan Hovold
driver certainly indicates that) despite what the vendor claims.
Are you using the vendor driver or a generic cdc-acm driver on Wind=

ows?

Post by Johan Hovold
I don't have time to look into this in a few days, but would you be=

able

Post by Johan Hovold
to test patches that I send you? Possibly some diagnostic patches t=

o

Post by Johan Hovold
determine if cdc-acm can be used, and if not, a dedicated usb seria=

l

Post by Johan Hovold
driver?
If so, you could compile your own mainline (or stable 3.16) kernel =

in

Post by Johan Hovold
the mean time so you have something to test the patches with.

Oh thanks for the clarification about top-posting (actually I didn't =

see=20

the message the first time).
=20
I'm using the vendor driver on WinXP I'll test later the generic driv=

er=20

of Win7 later (and if it has the WinXP). The vendor driver for linux=20
Vizzini (1) seems that it's quite buggy and some developers have alre=

ady=20

given up trying to fix it (2) though there's people trying to patch i=

t=20

(3) (I haven't tried this one, I've just found it).

Did the generic Windows cdc-acm driver work?

Ok, I'll install the latest mainline (no RC) 3.16.1-031601-generic fr=

om=20

kernel.ubuntu.com. Then download the source to have some code to work=

=20

with and apply the patches.

Have you got a stable kernel you built yourself up an running (you
should be using a version from kernel.org not an ubuntu one)?

What have you got connected to the serial-port hub? Could you prepare a
minimal test setup where you connect the hub-port to a serial or
usb-serial port?

Try setting that up with a minicom session I both ends. Disable flow
control and make sure the port settings match.

Does anything get through? If not, try enabling DEBUG and VERBOSE_DEBUG
by defining them in the cdc-acm driver and submit the log from when
opening, writing and reading.

Thanks,
Johan
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html