[OT(ish] Duplicate Character between modems

Hi,
	My apologies for sending this here, but I reckon you guys are probably the
best bet I have of finding a solution to my problem (esp. as it indirectly
relates to serial programming)

	I'm currently porting an application from DOS to Linux (RH7.2 with Cyclades
Cyclom-Y (hi henrique!!)).

	My issue is this, if I send down the modem ;
"ABCDEFGHI"
	the receiving end (very infrequently) receives
"AABCDEFGHI"
	This is caught by the check digit routine and the line is NAK'd ready for a
re-transmit. It will usually work the second or third time. This has found a
bug in the 3rd party transmitting software, but they're taking the attitude
of the existing system works, so you fix your end !!! (the bug if your
interested is after sending a NAK they drop the connection, instead of
waiting for 5 retries)

	The existing DOS system uses old modems such as Pace Linnet (1200 baud) and
an even older modem called a Compact which you cannot do anything with, no
init string, no RING or CONNECT message, just straight into getting the
data.

	The new system is using 3Com Courier V.everything modems. I can replicate
the problem on other modems as well, so it's not a courier issue. We have to
disable any error correction, compression (except MNP), and set the flow
control to hardware. As far as I can see I've disable pretty much
everything, but I still occasionally get these duplicated characters. It
used to be quite bad and then I realised that the Courier set the flow

Re: Linux 2.5.30: [SERIAL] build fails at 8250.c

	linux-2.5.30/include/linux/serialP.h needs struct async_icount,
which is defined in <linux/serial.h>, causing
linux-2.5.30/drivers/serial/8250.c not to compile, among other problems.
In linux-2.5.30, you cannot compile a file that includes <linux/serialP.h>
without including <linux/serial.h>.  So, I think the solution is for
serialP.h to #include serial.h.  I have attached a patch that does this.

	From the comments in serialP.h, it looks like there was some
effort in linux-2.2 to allow inclusion of serialP.h without serial.h,
but I see no indication of what benefit that was supposed to provide.

	Ted (or whowever gathers drivers/serial patches for Linus), do
you want to shepherd this change to Linus, do you want me to submit it
directly, or do you want to do something else?

--

-- 
Adam J. Richter     __     ______________   575 Oroville Road
adam <at> yggdrasil.com     \ /                  Milpitas, California 95035
+1 408 309-6081         | g g d r a s i l   United States of America
                         "Free Software For The Rest Of Us."

--- linux-2.5.30/include/linux/serialP.h	2002-08-01 14:16:07.000000000 -0700
+++ linux/include/linux/serialP.h	2002-08-02 14:51:03.000000000 -0700
 <at>  <at>  -24,11 +24,7  <at>  <at> 
 #include <linux/tqueue.h>
 #include <linux/circ_buf.h>
 #include <linux/wait.h>
-#if (LINUX_VERSION_CODE < 0x020300)
-/* Unfortunate, but Linux 2.2 needs async_icount defined here and

RE: [OT(ish] Duplicate Character between modems

On Fri, August 02, 2002 1:41 PM, Neil Everton wrote:
> Hi,

  [snip]

> 	I'm currently porting an application from DOS to Linux 
> (RH7.2 with Cyclades
> Cyclom-Y (hi henrique!!)).
> 
> 	My issue is this, if I send down the modem ;
> "ABCDEFGHI"
> 	the receiving end (very infrequently) receives
> "AABCDEFGHI"
> 	This is caught by the check digit routine and the line 
> is NAK'd ready for a
> re-transmit. It will usually work the second or third time. 
> This has found a
> bug in the 3rd party transmitting software, but they're 
> taking the attitude
> of the existing system works, so you fix your end !!! (the bug if your
> interested is after sending a NAK they drop the connection, instead of
> waiting for 5 retries)
> 
   [snip]

Hi Neil,

First thing I would check is to make sure that neither end is echoing. Check
both the systems' ports and the modems' digital side ports. 

Re: Linux 2.5.30: [SERIAL] build fails at 8250.c

On Fri, Aug 02, 2002 at 03:49:24PM -0700, Adam J. Richter wrote:
> 	linux-2.5.30/include/linux/serialP.h needs struct async_icount,
> which is defined in <linux/serial.h>, causing
> linux-2.5.30/drivers/serial/8250.c not to compile, among other problems.
> In linux-2.5.30, you cannot compile a file that includes <linux/serialP.h>
> without including <linux/serial.h>.  So, I think the solution is for
> serialP.h to #include serial.h.  I have attached a patch that does this.

Ack.  I've just found why I and many other people can build it, and
other people can't.  I can tell you that you're building 8250.c as a
module.

Why?

When I build 8250.c into the kernel, linux/module.h doesn't include
linux/version.h, so when we include linux/serialP.h, the compiler
assumes that LINUX_VERSION_CODE is zero.  So we end up including
linux/serial.h.

However, when building as a module, linux/module.h does include
linux/version.h, so when we don't include linux/serial.h.

Oh, the problems of trying to reduce the includes...  I think we should
re-include linux/serial.h and eliminate linux/serialP.h.

Hmm, I wonder how many other oddities like this are in the tree today.
It sounds like we want to create a rule similar to the one for using
CONFIG_* symbols.  Does this sound reasonable: if you use
LINUX_VERSION_CODE, you must include linux/version.h into that very
same file to guarantee that it is defined.

Re: Linux 2.5.30: [SERIAL] build fails at 8250.c

On Sat, Aug 03, 2002 at 12:56:26AM +0100, Russell King wrote:
> 	# Look for usages.
> 	next unless m/LINUX_VERSION_CODE/o;

It should probably look for the other two macros in linux/version.h as
well btw, so it could be generating false negatives.

--

-- 
Russell King (rmk <at> arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

-
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Linux 2.5.30: [SERIAL] build fails at 8250.c

On Sat, 3 Aug 2002 01:12:10 +0100, Russell King wrote:
>Ok, here's a fix for the 8250.c build problem (please don't send it
>to Linus; I've other changes that'll be going via BK and patch to
>lkml pending):
>
>--- orig/drivers/serial/8250.c  Fri Aug  2 21:13:31 2002
>+++ linux/drivers/serial/8250.c Sat Aug  3 00:28:47 2002
> <at>  <at>  -31,7 +31,8  <at>  <at> 
> #include <linux/console.h>
> #include <linux/sysrq.h>
> #include <linux/serial_reg.h>
>-#include <linux/serialP.h>
>+#include <linux/circ_buf.h>
>+#include <linux/serial.h>
> #include <linux/delay.h>
> 
> #include <asm/io.h>

	Your patch still results in a compilation error for me.
It looks like 8250.c needs <linux/serialP.h> for ALPHA_KLUDGE_MCR:

  gcc -Wp,-MD,./.8250.o.d -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes
-Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common -pipe
-mpreferred-stack-boundary=2 -march=i386 -nostdinc -iwithprefix include -DMODULE -include
/usr/src/linux/include/linux/modversions.h   -DKBUILD_BASENAME=8250 -DEXPORT_SYMTAB  -c -o 8250.o 8250.c
8250.c: In function `serial8250_set_mctrl':
8250.c:1061: `ALPHA_KLUDGE_MCR' undeclared (first use in this function)
8250.c:1061: (Each undeclared identifier is reported only once
8250.c:1061: for each function it appears in.)

Re: Linux 2.5.30: [SERIAL] build fails at 8250.c

On Sat, 3 Aug 2002, Russell King wrote:

> When I build 8250.c into the kernel, linux/module.h doesn't include
> linux/version.h, so when we include linux/serialP.h, the compiler
> assumes that LINUX_VERSION_CODE is zero.  So we end up including
> linux/serial.h.
> 
> However, when building as a module, linux/module.h does include
> linux/version.h, so when we don't include linux/serial.h.
> 
> Oh, the problems of trying to reduce the includes...  I think we should
> re-include linux/serial.h and eliminate linux/serialP.h.
> 
> Hmm, I wonder how many other oddities like this are in the tree today.
> It sounds like we want to create a rule similar to the one for using
> CONFIG_* symbols.  Does this sound reasonable: if you use
> LINUX_VERSION_CODE, you must include linux/version.h into that very
> same file to guarantee that it is defined.
> 
> Well, I took checkconfig.pl and created checkversion.pl (attached).
> Oh god, can I please put the worms back in the can?  Now?  I think
> there's lots of work to do here; lots of stuff including linux/version.h
> for the hell of it, and a comparitively small number not including it
> when they use LINUX_VERSION_CODE.
> 
> (No, I'm just off to zzz, so this must be a nightmare, maybe it'll go
> away by the time I wake up later today.) 8/

Hmmh, note that checkconfig.pl is actually not necessary anymore, it could 
be replaced by just including config.h unconditionally, or even include 

Re: Linux 2.5.30: [SERIAL] build fails at 8250.c

On Fri, Aug 02, 2002 at 05:20:28PM -0700, Adam J. Richter wrote:
> On Sat, 3 Aug 2002 01:12:10 +0100, Russell King wrote:
> >Ok, here's a fix for the 8250.c build problem (please don't send it
> >to Linus; I've other changes that'll be going via BK and patch to
> >lkml pending):
> >
> >--- orig/drivers/serial/8250.c  Fri Aug  2 21:13:31 2002
> >+++ linux/drivers/serial/8250.c Sat Aug  3 00:28:47 2002
> > <at>  <at>  -31,7 +31,8  <at>  <at> 
> > #include <linux/console.h>
> > #include <linux/sysrq.h>
> > #include <linux/serial_reg.h>
> >-#include <linux/serialP.h>
> >+#include <linux/circ_buf.h>
> >+#include <linux/serial.h>
> > #include <linux/delay.h>
> > 
> > #include <asm/io.h>
> 
> 	Your patch still results in a compilation error for me.
> It looks like 8250.c needs <linux/serialP.h> for ALPHA_KLUDGE_MCR:

Your quote above didn't include the patch for 8250.h which was in my
mail directly after 8250.c.  Did you specifically miss it for a reason?

--

-- 
Russell King (rmk <at> arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

-

Re: Linux 2.5.30: [SERIAL] build fails at 8250.c

On Sat, 3 Aug 2002 09:05:23 +0100, Russell King wrote:
>On Fri, Aug 02, 2002 at 05:20:28PM -0700, Adam J. Richter wrote:
>> On Sat, 3 Aug 2002 01:12:10 +0100, Russell King wrote:
>> >Ok, here's a fix for the 8250.c build problem (please don't send it
>> >to Linus; I've other changes that'll be going via BK and patch to
>> >lkml pending):
>> >
>> >--- orig/drivers/serial/8250.c  Fri Aug  2 21:13:31 2002
>> >+++ linux/drivers/serial/8250.c Sat Aug  3 00:28:47 2002
>> > <at>  <at>  -31,7 +31,8  <at>  <at> 
>> > #include <linux/console.h>
>> > #include <linux/sysrq.h>
>> > #include <linux/serial_reg.h>
>> >-#include <linux/serialP.h>
>> >+#include <linux/circ_buf.h>
>> >+#include <linux/serial.h>
>> > #include <linux/delay.h>
>> > 
>> > #include <asm/io.h>
>> 
>> 	Your patch still results in a compilation error for me.
>> It looks like 8250.c needs <linux/serialP.h> for ALPHA_KLUDGE_MCR:

>Your quote above didn't include the patch for 8250.h which was in my
>mail directly after 8250.c.  Did you specifically miss it for a reason?

	Doh!  Sorry, my mistake.

Adam J. Richter     __     ______________   575 Oroville Road
adam <at> yggdrasil.com     \ /                  Milpitas, California 95035

Re: [OT(ish] Duplicate Character between modems

Since you don't have an issue when error-correction is on, then I'd say
that pretty much rules out any software-based cause of your extra
character.

What the ec hides is line noise, why do you suppose it was invented to
begin with? Noise on a serial device turns into bogus serial characters,
and you end up with something like thi~ <at> #&!~!#ER$! <at> #as4 NO CARRIER

On Fri, 2 Aug 2002, Neil Everton wrote:

> Date: Fri, 2 Aug 2002 21:41:09 +0100
> From: Neil Everton <neil <at> gemini-it.com>
> To: "Linux-Serial <at> Vger. Kernel. Org" <linux-serial <at> vger.kernel.org>
> Subject: [OT(ish] Duplicate Character between modems
> 
> Hi,
> 	My apologies for sending this here, but I reckon you guys are probably the
> best bet I have of finding a solution to my problem (esp. as it indirectly
> relates to serial programming)
> 
> 	I'm currently porting an application from DOS to Linux (RH7.2 with Cyclades
> Cyclom-Y (hi henrique!!)).
> 
> 	My issue is this, if I send down the modem ;
> "ABCDEFGHI"
> 	the receiving end (very infrequently) receives
> "AABCDEFGHI"
> 	This is caught by the check digit routine and the line is NAK'd ready for a
> re-transmit. It will usually work the second or third time. This has found a
> bug in the 3rd party transmitting software, but they're taking the attitude