Hello,
I seem to have problems with the ark3116 driver from 2.6.18.8. This is a
USB-RS232 cable. Just opening the /dev/ttyUSB0 device
gives (this is the
debug output enabled by `modprobe ark3116 debug=1`).
The lines that look suspicious are
/serial/ark3116.c: 124 < 1 bytes [0xFFFFFFB0]
and
/serial/ark3116.c: ark3116_ioctl cmd 0x5401 not supported
I have also seen things like "id here < -62 [0x10]", which would
indicate that usb_control_msg() returned something very negative
(-ETIME!?).
Issuing a write() on an open fd to ttyUSB does not generate any further
debug output. Is the driver even complete/functional?
I do not know where to go from here, please advise.
Full output:
/serial/ark3116.c: ark3116_open - port 0
/serial/ark3116.c: 111 < 1 bytes [0x03]
/serial/ark3116.c: 112 > ok
/serial/ark3116.c: 113 > ok
/serial/ark3116.c: 114 > ok
/serial/ark3116.c: 115 > ok
/serial/ark3116.c: 116 < 1 bytes [0x03]
/serial/ark3116.c: 117 > ok
/serial/ark3116.c: 118 < 1 bytes [0x02]
/serial/ark3116.c: 119 > ok
/serial/ark3116.c: 120 < 1 bytes [0x00]
/serial/ark3116.c: 121 > ok
/serial/ark3116.c: 122 < 1 bytes [0x01]
/serial/ark3116.c: 123 > ok
/serial/ark3116.c: 124 < 1 bytes [0xFFFFFFB0]
/serial/ark3116.c: ark3116_set_termios - port 0
/serial/ark3116.c: setting CS8
/serial/ark3116.c: setting parity to NONE
/serial/ark3116.c: setting 1 stop bit
/serial/ark3116.c: 000 < 1 bytes [0x02]
/serial/ark3116.c: setting baudrate to 9600 (->reg=312)
/serial/ark3116.c: 147 > ok
/serial/ark3116.c: 148 > ok
/serial/ark3116.c: 149 > ok
/serial/ark3116.c: 150 > ok
/serial/ark3116.c: 151 < 1 bytes [0x03]
/serial/ark3116.c: 152 > ok
/serial/ark3116.c: updating bit count, stop bit or parity (cfg=0x03)
/serial/ark3116.c: 153 < 1 bytes [0x00]
/serial/ark3116.c: 154 > ok
/serial/ark3116.c: ark3116_ioctl cmd 0x5401 not supported
Jan
--
On Wed, May 16, 2007 at 06:04:45PM +0200, Jan Engelhardt wrote:
> Hello,
>
>
> I seem to have problems with the ark3116 driver from 2.6.18.8. This is a
> USB-RS232 cable. Just opening the /dev/ttyUSB0 device
> gives (this is the
> debug output enabled by `modprobe ark3116 debug=1`).
>
> The lines that look suspicious are
> /serial/ark3116.c: 124 < 1 bytes [0xFFFFFFB0]
> and
> /serial/ark3116.c: ark3116_ioctl cmd 0x5401 not supported
Why is this suspicious? We don't support all ioctls for all usb-serial
drivers, perhaps this one is just not really needed?
> I have also seen things like "id here < -62 [0x10]", which would
> indicate that usb_control_msg() returned something very negative
> (-ETIME!?).
But does the driver seem to work properly?
> Issuing a write() on an open fd to ttyUSB does not generate any further
> debug output. Is the driver even complete/functional?
Do you get data through the device properly?
thanks,
greg k-h
Hi Greg,
On May 17 2007 05:45, Greg KH wrote:
>>
>> I seem to have problems with the ark3116 driver from 2.6.18.8. This
>> is a USB-RS232 cable. Just opening the /dev/ttyUSB0 device gives
>> (this is the debug output enabled by `modprobe ark3116 debug=1`).
>>
>> The lines that look suspicious are
>> /serial/ark3116.c: 124 < 1 bytes [0xFFFFFFB0]
>> and
>> /serial/ark3116.c: ark3116_ioctl cmd 0x5401 not supported
>
>Why is this suspicious? We don't support all ioctls for all usb-serial
>drivers, perhaps this one is just not really needed?
ark3116 supports set_termios (0x5402), but does not get_termios
(0x5401). Not sure how that affects userspace, though.
The 0xFFFFFFB0 looks like a simple formatting error (ark3116.c line 66)
an explicit cast to (unsigned char)buf[0] or (unsigned int) seems
required.
>> I have also seen things like "id here < -62 [0x10]", which would
>> indicate that usb_control_msg() returned something very negative
>> (-ETIME!?).
The -62 only shows up when the cable is already connected when I
modprobe ark3116. Reinserting it - and no "-62" shows up.
Maybe this is something normal with USB?
>But does the driver seem to work properly?
>
>> Issuing a write() on an open fd to ttyUSB does not generate any further
>> debug output. Is the driver even complete/functional?
(I found that I already need to modprobe usbserial with debug=1,
since ark3116 uses usb_serial_generic_write)
>Do you get data through the device properly?
I would have to test with a real serial port. (I do not
have any real port right now, just two cables + adapters.)
What certainly does not work: Connecting two cables to each other, that is,
USB-RS232-GenderChanger-RS232-USB. (1) USB ends connected to the same machine
(2) USB ends connected to different machines. Both (1) and (2) do not work.
The write() seems to succeed, but read() blocks:
# klogconsole -l8 -r0
# ./sertest
[...]
Writing...
drivers/usb/serial/usb-serial.c: serial_write_room - port 0
drivers/usb/serial/generic.c: usb_serial_generic_write_room - port 0
drivers/usb/serial/generic.c: usb_serial_generic_write_room - returns 64
drivers/usb/serial/usb-serial.c: serial_write - port 0, 3 byte(s)
drivers/usb/serial/generic.c: usb_serial_generic_write - port 0
ark3116 ttyUSB0: usb_serial_generic_write - length = 3, data = 66 6f 6f
drivers/usb/serial/generic.c: usb_serial_generic_write_bulk_callback -
port 0
drivers/usb/serial/usb-serial.c: usb_serial_port_work - port 0
Reading...
(stops)
Source:
#include <sys/stat.h>
#include <sys/types.h>
#include <fcntl.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
int main(void)
{
char bar[4] = {};
int s0 = open("/dev/ttyUSB0", O_RDWR);
int s1 = open("/dev/ttyUSB1", O_RDWR);
if (s0 < 0 || s1 < 0)
abort();
printf("Writing...\n");
write(s0, "foo", 3);
printf("Reading...\n");
read(s1, bar, 3);
printf("Read: %s\n", bar);
return 0;
}
Jan
--
On May 17 2007 16:10, Jan Engelhardt wrote:
>Hi Greg,
>
>>But does the driver seem to work properly?
>>Do you get data through the device properly?
I have taken a voltmeter and an appropriate testcase program - and yes,
at least transmit works.
>USB-RS232-GenderChanger-RS232-USB.
A faulty setup that is. My bad.
Jan
--
On Thu, May 17, 2007 at 04:51:09PM +0200, Jan Engelhardt wrote:
>
> On May 17 2007 16:10, Jan Engelhardt wrote:
> >Hi Greg,
> >
> >>But does the driver seem to work properly?
> >>Do you get data through the device properly?
>
> I have taken a voltmeter and an appropriate testcase program - and yes,
> at least transmit works.
>
> >USB-RS232-GenderChanger-RS232-USB.
>
> A faulty setup that is. My bad.
You forgot the NULL modem inverter :)
thanks,
greg k-h
On May 17 2007 07:58, Greg KH wrote:
>On Thu, May 17, 2007 at 04:51:09PM +0200, Jan Engelhardt wrote:
>> On May 17 2007 16:10, Jan Engelhardt wrote:
>> >Hi Greg,
>> >
>> >>But does the driver seem to work properly?
>> >>Do you get data through the device properly?
>>
>> I have taken a voltmeter and an appropriate testcase program - and yes,
>> at least transmit works.
>>
>> >USB-RS232-GenderChanger-RS232-USB.
>>
>> A faulty setup that is. My bad.
>
>You forgot the NULL modem inverter :)
Yeah I figured. Screw this legacy tech... Anyway here is the patch
for that printk:
---
Subject: Fix debug output of ark3116
Fix debug output. Previously, it would output "0xFFFFFFB0" on 32-bit
archs (and probably "0xFFFFFFFFFFFFFFB0" on 64-bits), because buf is
taken as signed char, which is promoted to signed int, while %x always
expects an unsigned int.
Signed-off-by: Jan Engelhardt <[email protected]>
---
drivers/usb/serial/ark3116.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Index: linux-2.6/drivers/usb/serial/ark3116.c
===================================================================
--- linux-2.6.orig/drivers/usb/serial/ark3116.c
+++ linux-2.6/drivers/usb/serial/ark3116.c
@@ -63,7 +63,8 @@ static inline void ARK3116_RCV(struct us
request, requesttype, value, index,
buf, 0x0000001, 1000);
if (result)
- dbg("%03d < %d bytes [0x%02X]", seq, result, buf[0]);
+ dbg("%03d < %d bytes [0x%02X]", seq, result,
+ ((unsigned char *)buf)[0]);
else
dbg("%03d < 0 bytes", seq);
}