On Thu, Jan 04, 2018 at 07:38:26PM +0100, Max Schulze wrote: > Hello, > > I need some advice how to debug a device, that under Windows presents 2 > virtual com ports. Windows .sys. file mentions a "Jungo CDC ACM OBEX > Driver". > > > I get the following dmesg output > > > [ 1700.263981] usb 1-1.4: new full-speed USB device number 10 using > > ehci-pci > > [ 1700.378186] usb 1-1.4: New USB device found, idVendor=0cad, > > idProduct=9011 > > [ 1700.378187] usb 1-1.4: New USB device strings: Mfr=1, Product=2, > > SerialNumber=0 > > [ 1700.378188] usb 1-1.4: Product: Motorola Solutions TETRA PEI interface > > [ 1700.378188] usb 1-1.4: Manufacturer: Motorola Solutions Inc. > > [ 1745.845550] cdc_acm 1-1.4:1.0: Zero length descriptor references > > [ 1745.845555] cdc_acm: probe of 1-1.4:1.0 failed with error -22 > > [ 1745.845560] cdc_acm 1-1.4:1.1: Zero length descriptor references > > [ 1745.845561] cdc_acm: probe of 1-1.4:1.1 failed with error -22 > > Adding the device ids and a quirk to cdc_acm.c > > > .driver_info = NO_UNION_NORMAL, > > does only suppress the "Zero length" message. Do you then get a ttyACMn device? Or some other error? > What can I do? > > Details: > > > T: Bus=01 Lev=02 Prnt=02 Port=03 Cnt=03 Dev#= 10 Spd=12 MxCh= 0 > > > > D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 > > P: Vendor=0cad ProdID=9011 Rev=24.16 > > S: Manufacturer=Motorola Solutions Inc. > > S: Product=Motorola Solutions TETRA PEI interface > > C: #Ifs= 2 Cfg#= 1 Atr=80 MxPwr=500mA > > I: If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none) > > I: If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none) Thus doesn't look like a CDC device. Can you post the full output of "lsusb -v"? > Alternative with usbserial > > # echo '0cad 9011' > /sys/bus/usb-serial/drivers/generic/new_id > > > [ 2234.761068] usbserial_generic 1-1.4:1.0: The "generic" usb-serial > > driver is only for testing and one-off prototypes. > > [ 2234.761069] usbserial_generic 1-1.4:1.0: Tell > > linux-usb@xxxxxxxxxxxxxxx to add your device to a proper driver. > > [ 2234.761070] usbserial_generic 1-1.4:1.0: generic converter detected > > [ 2234.761236] usb 1-1.4: generic converter now attached to ttyUSB0 > > [ 2234.761249] usbserial_generic 1-1.4:1.1: The "generic" usb-serial > > driver is only for testing and one-off prototypes. > > [ 2234.761250] usbserial_generic 1-1.4:1.1: Tell > > linux-usb@xxxxxxxxxxxxxxx to add your device to a proper driver. > > [ 2234.761250] usbserial_generic 1-1.4:1.1: generic converter detected > > [ 2234.761293] usb 1-1.4: generic converter now attached to ttyUSB1 > > however: > > $ miniterm.py /dev/ttyUSB1 > Traceback (most recent call last): > File "/usr/bin/miniterm.py", line 878, in <module> > main() > File "/usr/bin/miniterm.py", line 834, in main > serial_instance.open() > File > "/home/max/.local/lib/python2.7/site-packages/serial/serialposix.py", > line 311, in open > self._update_dtr_state() > File > "/home/max/.local/lib/python2.7/site-packages/serial/serialposix.py", > line 605, in _update_dtr_state > fcntl.ioctl(self.fd, TIOCMBIS, TIOCM_DTR_str) > IOError: [Errno 22] Invalid argument Yeah, this is expected since you will not be able to do modem control when using the generic driver. Looks like we have another Motorola device with that vendor id managed by the ipaq, which may work better for you, although you still wouldn't be able to use TIOCMBIS. Why is your script doing that in the first place? This would already have been taken care of by the tty layer (and driver) as part of open() if the driver supports it. Johan -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
