linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* belkin usb serial converter (mct_u232), break not working
@ 2004-10-20 18:46 Thomas Stewart
  2004-10-20 20:48 ` Paul Fulghum
  2004-10-20 21:22 ` Paul Fulghum
  0 siblings, 2 replies; 14+ messages in thread
From: Thomas Stewart @ 2004-10-20 18:46 UTC (permalink / raw)
  To: linux-kernel

Hi,

I'm having trouble with a Belkin USB serial adapter, I can't get it to send a 
break down the serial cable to a console.

I made a quick program to send a break to a port (mostly ripped off from 
minicom). 

porttest.c:
#include <sys/fcntl.h>
#include <sys/ioctl.h>
main () {
        int fd = open("/dev/ttyS0", O_RDWR|O_NOCTTY);
        ioctl(fd, TCSBRK, 0);
        close(fd);
}

Both minicom and my program send a break fine to a regular pc serial port (eg 
ttyS0). In this case it drops my sun box to an "ok" prompt.

However if I use the usb serial adapter both minicom and my program are unable 
to send breaks, they just seem to get ignored.

I loaded the modules with debugging information turned on:-
modprobe usbserial debug=1
modprobe mct_u232 debug=1

$ sudo tail -f /var/log/syslog &
$ ./porttest
Oct 20 15:45:42 hydra kernel: drivers/usb/serial/usb-serial.c: serial_open
Oct 20 15:45:42 hydra kernel: drivers/usb/serial/mct_u232.c: mct_u232_open 
port 1
Oct 20 15:45:42 hydra kernel: drivers/usb/serial/mct_u232.c: set_modem_ctrl: 
state=0x6 ==> mcr=0xb
Oct 20 15:45:42 hydra kernel: drivers/usb/serial/mct_u232.c: set_line_ctrl: 
0x3
Oct 20 15:45:42 hydra kernel: drivers/usb/serial/mct_u232.c: get_modem_stat: 
0x30
Oct 20 15:45:42 hydra kernel: drivers/usb/serial/mct_u232.c: msr_to_state: 
msr=0x30 ==> state=0x126
Oct 20 15:45:42 hydra kernel: drivers/usb/serial/usb-serial.c: 
serial_chars_in_buffer = port 1
Oct 20 15:45:42 hydra kernel: drivers/usb/serial/generic.c: 
usb_serial_generic_chars_in_buffer - port 1
Oct 20 15:45:42 hydra kernel: drivers/usb/serial/generic.c: 
usb_serial_generic_chars_in_buffer - returns 0
Oct 20 15:45:42 hydra kernel: drivers/usb/serial/usb-serial.c: serial_break - 
port 1
Oct 20 15:45:42 hydra kernel: drivers/usb/serial/mct_u232.c: 
mct_u232_break_ctlstate=-1
Oct 20 15:45:42 hydra kernel: drivers/usb/serial/mct_u232.c: set_line_ctrl: 
0x43
Oct 20 15:45:42 hydra kernel: drivers/usb/serial/usb-serial.c: serial_break - 
port 1
Oct 20 15:45:42 hydra kernel: drivers/usb/serial/mct_u232.c: 
mct_u232_break_ctlstate=0
Oct 20 15:45:42 hydra kernel: drivers/usb/serial/mct_u232.c: set_line_ctrl: 
0x3
Oct 20 15:45:42 hydra kernel: drivers/usb/serial/usb-serial.c: serial_close - 
port 1
Oct 20 15:45:42 hydra kernel: drivers/usb/serial/mct_u232.c: mct_u232_close 
port 1
Oct 20 15:45:42 hydra kernel: drivers/usb/serial/mct_u232.c: 
mct_u232_read_int_callback - port 1
Oct 20 15:45:42 hydra kernel: drivers/usb/serial/mct_u232.c: 
mct_u232_read_int_callback - urb shutting down with status: -2
Oct 20 15:45:42 hydra kernel: drivers/usb/serial/mct_u232.c: 
mct_u232_read_int_callback - port 1
Oct 20 15:45:42 hydra kernel: drivers/usb/serial/mct_u232.c: 
mct_u232_read_int_callback - urb shutting down with status: -2

set_line_ctrl gets changed from 0x3 to 0x43 and back to 0x3. According to 
mct_u232.h the 6th bit of the line control register is the "set break" bit. 
So It looks like it thinks its sending a break, but as far as I can tell it 
is not actually sending it (because my sun box is not dropped to an ok 
prompt)

Anyone got any ideas about how to get it to work? (Or an alternative?)

(Can replies be CC'ed to me as I'm not subscribed. Thanks)

Regards
-- 
Tom

PGP Fingerprint [DCCD 7DCB A74A 3E3B 60D5  DF4C FC1D 1ECA 68A7 0C48]
PGP Publickey   [http://www.stewarts.org.uk/public-key.asc]
PGP ID  [0x68A70C48]

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: belkin usb serial converter (mct_u232), break not working
  2004-10-20 18:46 belkin usb serial converter (mct_u232), break not working Thomas Stewart
@ 2004-10-20 20:48 ` Paul Fulghum
  2004-10-20 21:22 ` Paul Fulghum
  1 sibling, 0 replies; 14+ messages in thread
From: Paul Fulghum @ 2004-10-20 20:48 UTC (permalink / raw)
  To: Thomas Stewart; +Cc: linux-kernel

On Wed, 2004-10-20 at 13:46, Thomas Stewart wrote:
> Hi,
> 
> I'm having trouble with a Belkin USB serial adapter, I can't get it to send a 
> break down the serial cable to a console.
> 
> I made a quick program to send a break to a port (mostly ripped off from 
> minicom). 
> 
> porttest.c:
> #include <sys/fcntl.h>
> #include <sys/ioctl.h>
> main () {
>         int fd = open("/dev/ttyS0", O_RDWR|O_NOCTTY);
>         ioctl(fd, TCSBRK, 0);
>         close(fd);
> }
> 
> Both minicom and my program send a break fine to a regular pc serial port (eg 
> ttyS0). In this case it drops my sun box to an "ok" prompt.
> 
> However if I use the usb serial adapter both minicom and my program are unable 
> to send breaks, they just seem to get ignored.

Could this be a simple matter of timing?

The Sun box may require a break for a certain period
which by chance is met on a standard UART but not
the USB serial adapter.

Try adding a sleep() after the ioctl call to delay
before clearing the break condition.

-- 
Paul Fulghum
paulkf@microgate.com


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: belkin usb serial converter (mct_u232), break not working
  2004-10-20 18:46 belkin usb serial converter (mct_u232), break not working Thomas Stewart
  2004-10-20 20:48 ` Paul Fulghum
@ 2004-10-20 21:22 ` Paul Fulghum
  2004-10-20 22:08   ` Thomas Stewart
  1 sibling, 1 reply; 14+ messages in thread
From: Paul Fulghum @ 2004-10-20 21:22 UTC (permalink / raw)
  To: Thomas Stewart; +Cc: linux-kernel

On Wed, 2004-10-20 at 13:46, Thomas Stewart wrote:
> I'm having trouble with a Belkin USB serial adapter, I can't get it to send a 
> break down the serial cable to a console.
> 
> I made a quick program to send a break to a port (mostly ripped off from 
> minicom). 
> 
> porttest.c:
> #include <sys/fcntl.h>
> #include <sys/ioctl.h>
> main () {
>         int fd = open("/dev/ttyS0", O_RDWR|O_NOCTTY);
>         ioctl(fd, TCSBRK, 0);
>         close(fd);
> }
> 
> Both minicom and my program send a break fine to a regular pc serial port (eg 
> ttyS0). In this case it drops my sun box to an "ok" prompt.
> 
> However if I use the usb serial adapter both minicom and my program are unable 
> to send breaks, they just seem to get ignored.

I was too quick (and wrong!) on my previous response.
I was thinking of TIOCSBRK (turn on break and leave on),
not TCSBRK (turn on break for ~250ms).

My suggestion about timing may still be valid.

Try replacing ioctl(fd, TCSBRK, 0) with
ioctl(fd, TCSBRKP, duration)
duration is in 100ms units, so try 10 or 20.

Or you can use tcsendbreak(fd, duration);
I'm not sure of the units for this function on Linux
manpage says 'implementation defined',
a book I have says 250ms units in Linux.

-- 
Paul Fulghum
paulkf@microgate.com


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: belkin usb serial converter (mct_u232), break not working
  2004-10-20 21:22 ` Paul Fulghum
@ 2004-10-20 22:08   ` Thomas Stewart
  2004-10-20 22:15     ` Paul Fulghum
                       ` (2 more replies)
  0 siblings, 3 replies; 14+ messages in thread
From: Thomas Stewart @ 2004-10-20 22:08 UTC (permalink / raw)
  To: Paul Fulghum; +Cc: linux-kernel

On Wednesday 20 October 2004 22:22, you wrote:
> Try replacing ioctl(fd, TCSBRK, 0) with
> ioctl(fd, TCSBRKP, duration)
> duration is in 100ms units, so try 10 or 20.
>
> Or you can use tcsendbreak(fd, duration);
> I'm not sure of the units for this function on Linux
> manpage says 'implementation defined',
> a book I have says 250ms units in Linux.

I've tyred various combinations of ioctl(fd, TCSBRKP, x) and tcsendbreak(fd, 
x), where x is 2, 5, 10, 20 and 200.

One thing I did notice is that no mater what the value I use, it always 
finishes very quickly, there does not appear to be any duration.

take porttest.c:
#include <sys/fcntl.h>
#include <sys/ioctl.h>
main(int argc, char ** argv) {
        int fd = open(argv[1], O_RDWR|O_NOCTTY);
        ioctl(fd, TCSBRKP, 20);
        close(fd);
}

$ time ./porttest /dev/ttyS0
real    0m2.001s
user    0m0.001s
sys     0m0.000s

A standard serial port with a 2 second break (20*100ms), takes as expected 
just over 2 seconds.

$ time ./porttest /dev/ttyUSB1
real    0m0.004s
user    0m0.000s
sys     0m0.001s

However with the USB converter instead, it takes 5 ms to complete. Much 
shorter than expected.

Is it a driver issue?

Regards
-- 
Tom

PGP Fingerprint [DCCD 7DCB A74A 3E3B 60D5  DF4C FC1D 1ECA 68A7 0C48]
PGP Publickey   [http://www.stewarts.org.uk/public-key.asc]
PGP ID  [0x68A70C48]

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: belkin usb serial converter (mct_u232), break not working
  2004-10-20 22:08   ` Thomas Stewart
@ 2004-10-20 22:15     ` Paul Fulghum
  2004-10-20 22:21     ` Paul Fulghum
  2004-10-20 22:27     ` Paul Fulghum
  2 siblings, 0 replies; 14+ messages in thread
From: Paul Fulghum @ 2004-10-20 22:15 UTC (permalink / raw)
  To: Thomas Stewart; +Cc: linux-kernel

Thomas Stewart wrote:

>I've tyred various combinations of ioctl(fd, TCSBRKP, x) and tcsendbreak(fd, 
>x), where x is 2, 5, 10, 20 and 200.
>
>One thing I did notice is that no mater what the value I use, it always 
>finishes very quickly, there does not appear to be any duration.
>
>take porttest.c:
>#include <sys/fcntl.h>
>#include <sys/ioctl.h>
>main(int argc, char ** argv) {
>        int fd = open(argv[1], O_RDWR|O_NOCTTY);
>        ioctl(fd, TCSBRKP, 20);
>        close(fd);
>}
>
>$ time ./porttest /dev/ttyS0
>real    0m2.001s
>user    0m0.001s
>sys     0m0.000s
>
>A standard serial port with a 2 second break (20*100ms), takes as expected 
>just over 2 seconds.
>
>$ time ./porttest /dev/ttyUSB1
>real    0m0.004s
>user    0m0.000s
>sys     0m0.001s
>
>However with the USB converter instead, it takes 5 ms to complete. Much 
>shorter than expected.
>
>Is it a driver issue?
>  
>
Could be.
That test gives me more information.
I will look closer at the code and see if anything pops out.

Thanks,
Paul

--
Paul Fulghum
paulkf@microgate.com



^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: belkin usb serial converter (mct_u232), break not working
  2004-10-20 22:08   ` Thomas Stewart
  2004-10-20 22:15     ` Paul Fulghum
@ 2004-10-20 22:21     ` Paul Fulghum
  2004-10-20 22:27     ` Paul Fulghum
  2 siblings, 0 replies; 14+ messages in thread
From: Paul Fulghum @ 2004-10-20 22:21 UTC (permalink / raw)
  To: Thomas Stewart; +Cc: Linux Kernel list

On Wed, 2004-10-20 at 17:08, Thomas Stewart wrote:
> Is it a driver issue?

What kernel version are you running?

-- 
Paul Fulghum
paulkf@microgate.com



^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: belkin usb serial converter (mct_u232), break not working
  2004-10-20 22:08   ` Thomas Stewart
  2004-10-20 22:15     ` Paul Fulghum
  2004-10-20 22:21     ` Paul Fulghum
@ 2004-10-20 22:27     ` Paul Fulghum
  2004-10-20 23:04       ` Thomas Stewart
  2 siblings, 1 reply; 14+ messages in thread
From: Paul Fulghum @ 2004-10-20 22:27 UTC (permalink / raw)
  To: Thomas Stewart; +Cc: Linux Kernel list

On Wed, 2004-10-20 at 17:08, Thomas Stewart wrote:

> take porttest.c:
> #include <sys/fcntl.h>
> #include <sys/ioctl.h>
> main(int argc, char ** argv) {
>         int fd = open(argv[1], O_RDWR|O_NOCTTY);
>         ioctl(fd, TCSBRKP, 20);
>         close(fd);
> }
> 
> $ time ./porttest /dev/ttyS0
> real    0m2.001s
> user    0m0.001s
> sys     0m0.000s
> 
> A standard serial port with a 2 second break (20*100ms), takes as expected 
> just over 2 seconds.
> 
> $ time ./porttest /dev/ttyUSB1
> real    0m0.004s
> user    0m0.000s
> sys     0m0.001s
> 
> However with the USB converter instead, it takes 5 ms to complete. Much 
> shorter than expected.
> 
> Is it a driver issue?

Can you record and display the return code from the ioctl()?

Thanks

-- 
Paul Fulghum
paulkf@microgate.com



^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: belkin usb serial converter (mct_u232), break not working
  2004-10-20 22:27     ` Paul Fulghum
@ 2004-10-20 23:04       ` Thomas Stewart
  2004-10-21  2:37         ` Paul Fulghum
  0 siblings, 1 reply; 14+ messages in thread
From: Thomas Stewart @ 2004-10-20 23:04 UTC (permalink / raw)
  To: Paul Fulghum; +Cc: Linux Kernel list

On Wednesday 20 October 2004 23:21, you wrote:
> What kernel version are you running?

2.6.8.1

Well, a stock debian one out of sarge, kernel-image-2.6.8-1-686-smp, configs 
at http://www.stewarts.org.uk/stuff/config-2.6.8-1-686. There is not much 
difference between a stock 2.6.8.1 and the debian 2.6.8:-
http://www.stewarts.org.uk/stuff/debian.2.6.8.patch

On Wednesday 20 October 2004 23:27, you wrote:
> Can you record and display the return code from the ioctl()?

porttest.c:
#include <sys/fcntl.h>
#include <sys/ioctl.h>
main(int argc, char ** argv) {
        int r, fd = open(argv[1], O_RDWR|O_NOCTTY);
        r=ioctl(fd, TCSBRKP, 20);
        printf("%d\n", r);
        close(fd);
}

$ ./porttest /dev/ttyS0
0
$ ./porttest /dev/ttyUSB0
0

Regards
-- 
Tom

PGP Fingerprint [DCCD 7DCB A74A 3E3B 60D5  DF4C FC1D 1ECA 68A7 0C48]
PGP Publickey   [http://www.stewarts.org.uk/public-key.asc]
PGP ID  [0x68A70C48]

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: belkin usb serial converter (mct_u232), break not working
  2004-10-20 23:04       ` Thomas Stewart
@ 2004-10-21  2:37         ` Paul Fulghum
  2004-10-21 10:06           ` Thomas Stewart
  0 siblings, 1 reply; 14+ messages in thread
From: Paul Fulghum @ 2004-10-21  2:37 UTC (permalink / raw)
  To: Thomas Stewart; +Cc: Linux Kernel list

On Wed, 2004-10-20 at 18:04, Thomas Stewart wrote:
> porttest.c:
> #include <sys/fcntl.h>
> #include <sys/ioctl.h>
> main(int argc, char ** argv) {
>         int r, fd = open(argv[1], O_RDWR|O_NOCTTY);
>         r=ioctl(fd, TCSBRKP, 20);
>         printf("%d\n", r);
>         close(fd);
> }
> 
> $ ./porttest /dev/ttyS0
> 0
> $ ./porttest /dev/ttyUSB0
> 0

OK, this is a kernel problem with send_break() in tty_io.c

Original:

static int send_break(struct tty_struct *tty, int duration)
{
	set_current_state(TASK_INTERRUPTIBLE);

	tty->driver->break_ctl(tty, -1);
	if (!signal_pending(current))
		schedule_timeout(duration);
	tty->driver->break_ctl(tty, 0);
	if (signal_pending(current))
		return -EINTR;
	return 0;
}

The USB serial driver break_ctl() sends a URB which does
a sleep and wakeup changing the task state back to TASK_RUNNING.
Because of this, schedule_timeout() above gets short circuited
and the break condition is not maintained long enough.

The normal serial driver break_ctl() leaves the task state
as TASK_INTERRUPTIBLE so you get the proper delay.

Thomas: try the patch below and let me know the results.

-- 
Paul Fulghum
paulkf@microgate.com

--- linux-2.6.8/drivers/char/tty_io.c	2004-08-14 00:37:15.000000000 -0500
+++ b/drivers/char/tty_io.c	2004-10-20 21:31:55.000000000 -0500
@@ -1703,11 +1703,11 @@ static int tiocsetd(struct tty_struct *t
 
 static int send_break(struct tty_struct *tty, int duration)
 {
-	set_current_state(TASK_INTERRUPTIBLE);
-
 	tty->driver->break_ctl(tty, -1);
-	if (!signal_pending(current))
+	if (!signal_pending(current)) {
+		set_current_state(TASK_INTERRUPTIBLE);
 		schedule_timeout(duration);
+	}
 	tty->driver->break_ctl(tty, 0);
 	if (signal_pending(current))
 		return -EINTR;



^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: belkin usb serial converter (mct_u232), break not working
  2004-10-21  2:37         ` Paul Fulghum
@ 2004-10-21 10:06           ` Thomas Stewart
  2004-10-21 12:41             ` Paul Fulghum
  0 siblings, 1 reply; 14+ messages in thread
From: Thomas Stewart @ 2004-10-21 10:06 UTC (permalink / raw)
  To: Paul Fulghum; +Cc: Linux Kernel list

On Wed, Oct 20, 2004 at 09:37:58PM -0500, Paul Fulghum wrote:
> static int send_break(struct tty_struct *tty, int duration)
> {
> 	set_current_state(TASK_INTERRUPTIBLE);
> 
> 	tty->driver->break_ctl(tty, -1);
> 	if (!signal_pending(current))
> 		schedule_timeout(duration);
> 	tty->driver->break_ctl(tty, 0);
> 	if (signal_pending(current))
> 		return -EINTR;
> 	return 0;
> }
> 
> The USB serial driver break_ctl() sends a URB which does
> a sleep and wakeup changing the task state back to TASK_RUNNING.
> Because of this, schedule_timeout() above gets short circuited
> and the break condition is not maintained long enough.
> 
> The normal serial driver break_ctl() leaves the task state
> as TASK_INTERRUPTIBLE so you get the proper delay.
> 
> Thomas: try the patch below and let me know the results.

I tryed again with your patch applyed, with both minicom and porttest

porttest.c:
#include <sys/fcntl.h>
#include <sys/ioctl.h>
main(int argc, char ** argv) {
        int r, fd = open(argv[1], O_RDWR|O_NOCTTY);
        r=ioctl(fd, TCSBRKP, 20);
        printf("%d\n", r);
        close(fd);
}

$ time ./porttest /dev/ttyS0
0

real    0m2.001s
user    0m0.000s
sys     0m0.001s
$ time ./porttest /dev/ttyUSB0
0

real    0m2.003s
user    0m0.000s
sys     0m0.001s

As you can see, this time there is the correct pause. However
it still does not send the break.

To add the mix, I dug about and found a differnt type of USB serial
converter, a no-brand one that uses the pl2303 module. Both minicom
and porttest with either stock 2.6.8.1 or 2.6.8.1 with your patch
send the break fine with this different converter.

This makes me think it is a problem with the mct_u232 driver?

Regards
-- 
Tom

PGP Fingerprint [DCCD 7DCB A74A 3E3B 60D5  DF4C FC1D 1ECA 68A7 0C48]
PGP Publickey   [http://www.stewarts.org.uk/public-key.asc]
PGP ID		[0x68A70C48]

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: belkin usb serial converter (mct_u232), break not working
  2004-10-21 10:06           ` Thomas Stewart
@ 2004-10-21 12:41             ` Paul Fulghum
  2004-10-21 19:44               ` Paul Fulghum
  0 siblings, 1 reply; 14+ messages in thread
From: Paul Fulghum @ 2004-10-21 12:41 UTC (permalink / raw)
  To: Thomas Stewart; +Cc: Linux Kernel list

On Thu, 2004-10-21 at 05:06, Thomas Stewart wrote:
> I tryed again with your patch applyed, with both minicom and porttest
> 
> porttest.c:
> #include <sys/fcntl.h>
> #include <sys/ioctl.h>
> main(int argc, char ** argv) {
>         int r, fd = open(argv[1], O_RDWR|O_NOCTTY);
>         r=ioctl(fd, TCSBRKP, 20);
>         printf("%d\n", r);
>         close(fd);
> }
> 
> $ time ./porttest /dev/ttyS0
> 0
> 
> real    0m2.001s
> user    0m0.000s
> sys     0m0.001s
> $ time ./porttest /dev/ttyUSB0
> 0
> 
> real    0m2.003s
> user    0m0.000s
> sys     0m0.001s
> 
> As you can see, this time there is the correct pause. However
> it still does not send the break.
> 
> To add the mix, I dug about and found a differnt type of USB serial
> converter, a no-brand one that uses the pl2303 module. Both minicom
> and porttest with either stock 2.6.8.1 or 2.6.8.1 with your patch
> send the break fine with this different converter.
> 
> This makes me think it is a problem with the mct_u232 driver?

OK. This problem has multiple parts.

The change to tty_io.c is necessary to get the proper delay
between setting and clearing break. I will submit that
patch for inclusion.

Now it is a matter of figuring why the device is not
sending the break. The device break_ctl() gets called,
and the URB to set the line control is sent successfully.

Maybe the comments are wrong on the line control bits
or possibly the Belkin device requires some other setup
to send breaks.

I'll see if I can figure anything out.

-- 
Paul Fulghum
paulkf@microgate.com


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: belkin usb serial converter (mct_u232), break not working
  2004-10-21 12:41             ` Paul Fulghum
@ 2004-10-21 19:44               ` Paul Fulghum
  2004-11-04 18:20                 ` Thomas Stewart
  0 siblings, 1 reply; 14+ messages in thread
From: Paul Fulghum @ 2004-10-21 19:44 UTC (permalink / raw)
  To: Thomas Stewart; +Cc: Linux Kernel list

On Thu, 2004-10-21 at 07:41, Paul Fulghum wrote:
> On Thu, 2004-10-21 at 05:06, Thomas Stewart wrote:
> > As you can see, this time there is the correct pause. However
> > it still does not send the break.
> > 
> > To add the mix, I dug about and found a differnt type of USB serial
> > converter, a no-brand one that uses the pl2303 module. Both minicom
> > and porttest with either stock 2.6.8.1 or 2.6.8.1 with your patch
> > send the break fine with this different converter.
> > 
> > This makes me think it is a problem with the mct_u232 driver?
> 
> OK. This problem has multiple parts.
> 
> The change to tty_io.c is necessary to get the proper delay
> between setting and clearing break. I will submit that
> patch for inclusion.
> 
> Now it is a matter of figuring why the device is not
> sending the break. The device break_ctl() gets called,
> and the URB to set the line control is sent successfully.
> 
> Maybe the comments are wrong on the line control bits
> or possibly the Belkin device requires some other setup
> to send breaks.

I looked at mct_232.h and noticed the comment:

"There seem to be two bugs in the Win98 driver:
the break does not work (bit 6 is not asserted) and the
stick parity bit is not cleared when set once."
The driver was reverse engineered from the Win98 driver.

Even though the LCR for this device is similar to
the LCR of a 16550 UART, some bits work differently.

This suggests to me that either the device does not
properly support break, or that the break is
controlled through a different USB request and not
through MCT_U232_SET_LINE_CTRL_REQUEST

The Linux and FreeBSD drivers do the same thing
for setting break, so no new info there.
I don't have access to the device or manufacturer docs.

The only thing I can suggest is if you have
access to a Windows 2000/XP machine, try and generate
a break with the manufacturer provided drivers.
If you can't, then the device does not support break.
If you can, then maybe you can use USB sniffer
software to look at the USB requests going to the device.

-- 
Paul Fulghum
paulkf@microgate.com


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: belkin usb serial converter (mct_u232), break not working
  2004-10-21 19:44               ` Paul Fulghum
@ 2004-11-04 18:20                 ` Thomas Stewart
  2004-11-04 19:21                   ` Paul Fulghum
  0 siblings, 1 reply; 14+ messages in thread
From: Thomas Stewart @ 2004-11-04 18:20 UTC (permalink / raw)
  To: Paul Fulghum; +Cc: Linux Kernel list

On Thursday 21 October 2004 20:44, Paul Fulghum wrote:
> I looked at mct_232.h and noticed the comment:
>
> "There seem to be two bugs in the Win98 driver:
> the break does not work (bit 6 is not asserted) and the
> stick parity bit is not cleared when set once."
> The driver was reverse engineered from the Win98 driver.
>
> Even though the LCR for this device is similar to
> the LCR of a 16550 UART, some bits work differently.
>
> This suggests to me that either the device does not
> properly support break, or that the break is
> controlled through a different USB request and not
> through MCT_U232_SET_LINE_CTRL_REQUEST
>
> The Linux and FreeBSD drivers do the same thing
> for setting break, so no new info there.
> I don't have access to the device or manufacturer docs.
>
> The only thing I can suggest is if you have
> access to a Windows 2000/XP machine, try and generate
> a break with the manufacturer provided drivers.
> If you can't, then the device does not support break.
> If you can, then maybe you can use USB sniffer
> software to look at the USB requests going to the device.

I tried the converter on a XP machine and unfortunately while using the 
manufacturer provided drivers I was unable to produce a break :-(

As a last resort I tried Belkins tech support line. The first time I called I 
was told the product (F5U109ea) was designed for PDA use only and it would 
generate breaks fine if connected to them. Admittedly it is marketed as such 
(http://catalog.belkin.com/IWCatProductPage.process?Product_Id=103226). I was 
told to buy a F5U103 instead 
(http://catalog.belkin.com/IWCatProductPage.process?Product_Id=66002). Not 
happy with this I rang back to talk to another person, this time I was not 
fobbed off as quickly and although the tech support guy did not know what a 
break was, he offered to look into it and call me back. I've not heard back 
(yet), but I'm not too surprised.

Interestingly I got my hands on a F5U103 and it works fine (uses another chip 
and consequently module). However they are so much more bulky I don't think 
I'm going to bother changing over.

Thanks for all the help :-)

Regards
-- 
Tom

PGP Fingerprint [DCCD 7DCB A74A 3E3B 60D5  DF4C FC1D 1ECA 68A7 0C48]
PGP Publickey   [http://www.stewarts.org.uk/public-key.asc]
PGP ID  [0x68A70C48]

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: belkin usb serial converter (mct_u232), break not working
  2004-11-04 18:20                 ` Thomas Stewart
@ 2004-11-04 19:21                   ` Paul Fulghum
  0 siblings, 0 replies; 14+ messages in thread
From: Paul Fulghum @ 2004-11-04 19:21 UTC (permalink / raw)
  To: Thomas Stewart; +Cc: Linux Kernel list

On Thu, 2004-11-04 at 12:20, Thomas Stewart wrote:
> I tried the converter on a XP machine and unfortunately while using the 
> manufacturer provided drivers I was unable to produce a break :-(

That seems consistent with the code, comments,
and observed behavior.

I doubt this device can generate a break.

> was told the product (F5U109ea) was designed for PDA use only and it would 
> generate breaks fine if connected to them.

Sounds like garbage (industry standard for phone support) to me.

I can't see how the bit pattern generated on TxD is dependent
on the attached device. The support person probably
has no idea what a break pattern is.

> Interestingly I got my hands on a F5U103 and it works fine (uses another chip 
> and consequently module).

This all looks like a missing/non-functioning feature
for the F5U109.

-- 
Paul Fulghum
paulkf@microgate.com


^ permalink raw reply	[flat|nested] 14+ messages in thread

end of thread, other threads:[~2004-11-04 19:37 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-10-20 18:46 belkin usb serial converter (mct_u232), break not working Thomas Stewart
2004-10-20 20:48 ` Paul Fulghum
2004-10-20 21:22 ` Paul Fulghum
2004-10-20 22:08   ` Thomas Stewart
2004-10-20 22:15     ` Paul Fulghum
2004-10-20 22:21     ` Paul Fulghum
2004-10-20 22:27     ` Paul Fulghum
2004-10-20 23:04       ` Thomas Stewart
2004-10-21  2:37         ` Paul Fulghum
2004-10-21 10:06           ` Thomas Stewart
2004-10-21 12:41             ` Paul Fulghum
2004-10-21 19:44               ` Paul Fulghum
2004-11-04 18:20                 ` Thomas Stewart
2004-11-04 19:21                   ` Paul Fulghum

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).