[Serial 2.5]: packet drop problem (FE ?)

[Serial 2.5]: packet drop problem (FE ?)

[Jean Tourrilhes]

	Hi,

	I've got two identical boxes (dual P6 200MHz) talking to each
other through serial IrDA dongles (each attached to the first serial
port).

	One side has 2.4.20-pre8 :
-------------------------------
# cat /proc/tty/driver/serial 
serinfo:1.0 driver:5.05c revision:2001-07-08
0: uart:16550A port:3F8 irq:4 baud:9600 tx:5249946 rx:120379 RTS|DTR
1: uart:16550A port:2F8 irq:3 tx:0 rx:0 
-------------------------------

	The other side has 2.5.46 :
----------------------------
# cat /proc/tty/driver/serial 
serinfo:1.0 driver revision:
0: uart:16550A port:000003F8 irq:4 tx:19541287 rx:14370938 fe:1384 RTS|DTR
1: uart:16550A port:000002F8 irq:3 tx:39761 rx:3 RTS|DTR
[...]
# setserial -a /dev/ttyS0
/dev/ttyS0, Line 0, UART: 16550A, Port: 0x03f8, IRQ: 4
        Baud_base: 115200, close_delay: 500, divisor: 0
        closing_wait: 30000
        Flags: spd_normal skip_test
----------------------------

	Problem : a noticeable number of large packet from 2.4.X to
2.5.X are dropped (and retransmitted), whereas almost no packet from
2.5.X to 2.4.X are dropped.
	I tried swapping the IrDA dongles themselves, and this didn't
make any difference. No other device/driver is using irq4. I also try
using a FIR as a sender, and I still see this packet dropped in Rx in
2.5.X. And this used to work properly way back when I had 2.4.X on
this box.
	I'm kind of suspicious about the "fe" number above. Could
anybody tell me a bit more about what "fe" means ?

	Thanks...

	Jean

Re: [Serial 2.5]: packet drop problem (FE ?)

[Russell King]

On Thu, Nov 07, 2002 at 02:47:50PM -0800, Jean Tourrilhes wrote:
> 	I tried swapping the IrDA dongles themselves, and this didn't
> make any difference. No other device/driver is using irq4. I also try
> using a FIR as a sender, and I still see this packet dropped in Rx in
> 2.5.X. And this used to work properly way back when I had 2.4.X on
> this box.
> 	I'm kind of suspicious about the "fe" number above. Could
> anybody tell me a bit more about what "fe" means ?

FE = framing error, which is an error which is solely detected by the
hardware when the stop bit(s) are not the mark value.  They can appear
when the wrong parity setting, number of stop bits, or baud rate is
programmed.

If you were overruning the serial port FIFOs, then you would see "oe"
errors.

What baud rate are you trying to run the link at?

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

Re: [Serial 2.5]: packet drop problem (FE ?)

[Jean Tourrilhes]

On Fri, Nov 08, 2002 at 12:18:22AM +0000, Russell King wrote:
> On Thu, Nov 07, 2002 at 02:47:50PM -0800, Jean Tourrilhes wrote:
> > 	I tried swapping the IrDA dongles themselves, and this didn't
> > make any difference. No other device/driver is using irq4. I also try
> > using a FIR as a sender, and I still see this packet dropped in Rx in
> > 2.5.X. And this used to work properly way back when I had 2.4.X on
> > this box.
> > 	I'm kind of suspicious about the "fe" number above. Could
> > anybody tell me a bit more about what "fe" means ?
> 
> FE = framing error, which is an error which is solely detected by the
> hardware when the stop bit(s) are not the mark value.  They can appear
> when the wrong parity setting, number of stop bits, or baud rate is
> programmed.
> 
> If you were overruning the serial port FIFOs, then you would see "oe"
> errors.
> 
> What baud rate are you trying to run the link at?

	115k (max negociated speed).

	The IrDA layer report many CRC errors, that could be dropped
char or flipped bits. I see around one 2000B frame dropped every 10
frame, which would be one byte/bit every 20000B, which is roughly the
frequency of the FE in /proc.
	On the other hand, this number seems a bit low for a
configuration error.

	The serial port is configured via irattach like this :
-----------------------------------------
	tios->c_cflag     = CS8|CREAD|B9600|CLOCAL;
	
	/* Ignore break condition and parity errors */
 	tios->c_iflag     = IGNBRK | IGNPAR;
	tios->c_oflag     = 0;
	tios->c_lflag     = 0; /* set input mode (non-canonical, no echo,..) */
	tios->c_cc[VMIN]  = 1; /* num of chars to wait for, before delivery */
	tios->c_cc[VTIME] = 0; /* timeout before delivery */
-----------------------------------------
	Now, it's possible that somehow irattach did mess up this
bit.
	Is there a way to see the current flag configuration of the
port with setserial or /proc ?

> Russell King

	Thanks for your help...

	Jean

Re: [Serial 2.5]: packet drop problem (FE ?)

[Russell King]

On Thu, Nov 07, 2002 at 04:41:55PM -0800, Jean Tourrilhes wrote:
> 	Is there a way to see the current flag configuration of the
> port with setserial or /proc ?

stty -a -F /dev/ttySx

should do the trick.

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

Re: [Serial 2.5]: packet drop problem (FE ?)

[Jean Tourrilhes]

On Fri, Nov 08, 2002 at 12:49:24AM +0000, Russell King wrote:
> On Thu, Nov 07, 2002 at 04:41:55PM -0800, Jean Tourrilhes wrote:
> > 	Is there a way to see the current flag configuration of the
> > port with setserial or /proc ?
> 
> stty -a -F /dev/ttySx
> 
> should do the trick.

	2.5.X :
-----------------------------------
speed 9600 baud; rows 0; columns 0; line = 11;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W;
lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts
ignbrk -brkint ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff
-iuclc -ixany -imaxbel
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0
ff0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop
-echoprt -echoctl -echoke
-----------------------------------

	2.4.X :
-------------------------
speed 9600 baud; rows 0; columns 0; line = 11;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W;
lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts
ignbrk -brkint ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff
-iuclc -ixany -imaxbel
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0
ff0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop
-echoprt -echoctl -echoke
-------------------------

	I'll try to dig further. It might be the hardware...

	Jean

Re: [Serial 2.5]: packet drop problem (FE ?)

[Jean Tourrilhes]

On Fri, Nov 08, 2002 at 12:49:24AM +0000, Russell King wrote:
> On Thu, Nov 07, 2002 at 04:41:55PM -0800, Jean Tourrilhes wrote:
> > 	Is there a way to see the current flag configuration of the
> > port with setserial or /proc ?
> 
> stty -a -F /dev/ttySx
> 
> should do the trick.
> 
> -- 
> Russell King

	More data...
	I rebooted my 2.5.X box with 2.4.X (still SMP).

	If I use the same traffic as before (unidirectional), I don't
see any FE (none).

	On the other hand, if I use bidirectional traffic of large
packets I see the FE and packet drops (actually, I start seeing them
on both side) :
--------------------------------
2.4.20-rc1 (was 2.4.46) :
0: uart:16550A port:3F8 irq:4 baud:9600 tx:1440518 rx:7466705 fe:303 RTS|DTR
2.4.20-pre8 :
0: uart:16550A port:3F8 irq:4 baud:9600 tx:16502356 rx:2486282 fe:8 RTS|DTR
--------------------------------
	(all the 303 of them appeared during the few bidirectional tests)
	(as my perf numbers for directional traffic are up from 2.5.X,
I guess there is less spacket drop than with 2.5.X).

	Lastly, directional traffic of small packet doesn't produce any FE.

	So, clearly it depend on the traffic pattern. And the move
from 2.4.X to 2.5.X bring FE/drop in case where there was none,
i.e. 2.5.X make it worse.
	And I'm wondering if it's just a case a crappy hardware, but
there seems to be more.

	From your description of what FE is, I don't understand how
changing the kernel/driver/traffic pattern would make this number
change. Puzzling...

	Good luck...

	Jean

Re: [Serial 2.5]: packet drop problem (FE ?)

[Martin Diehl]

On Thu, 7 Nov 2002, Jean Tourrilhes wrote:

> 	So, clearly it depend on the traffic pattern. And the move
> from 2.4.X to 2.5.X bring FE/drop in case where there was none,
> i.e. 2.5.X make it worse.
> 	And I'm wondering if it's just a case a crappy hardware, but
> there seems to be more.
> 
> 	From your description of what FE is, I don't understand how
> changing the kernel/driver/traffic pattern would make this number
> change. Puzzling...

Do you think it could be some kind of IR noise? Three points why I 
believe it might:

* FE indicates the UART fetched L instead of H when it expected to see the 
STOP bit. With SIR encoding L means IR-pulse and H means no IR-pulse, i.e. 
we've received an IR pulse at the very moment when we expected to see
silent media.

* Normally, I'm only getting very few of this, much less than 1 FE per MB 
traffic. However, if I'm starting placing objects (fingers f.e. ;-) close 
to any end into the IR-link I'm suddenly getting hundreds of this (within 
about a second). Using a CDR disc as IR mirror has a similar effect.

* Even without any IrDA activity I can trigger the FE's using some 
remote control as IR source directed to the dongle. (this is also 
causing BRK's, but I think this is due to particular remote control 
encoding).

The next to know is whether irtty_receive_buf() reports any "Framing or 
parity error"? IIRC with IGNPAR set we should neither get parity nor 
framing errors reported and it seems this is how serial8250_change_speed()
deals with ignore_status_mask. But wait - yes, 8250's receive_chars() 
seems to accept the character, but set TTY_FRAME anyway.

Hence irtty_receive_buf() finds it when scanning the fp-array. And here we 
have a difference between old and new irtty: the old one skipped the 
flagged byte but continued with the rest of the cp-chunk while the new one 
discards all bytes from this chunk. The idea was to avoid unwrapping and 
crc'ing data we already know being corrupted. But yes, it appears I was a 
bit too pessimistic there.

I'm just starting to wonder why we would like to check for flagged 
characters at all? Not doing so shouldn't cause any harm because we are 
sitting below the checksum handling and SIR unwrap - which has the frame 
state for better recovery. Sure, we could save handling corrupted data, 
but irtty has no good strategy to recover.

Ok, I think what might happen is you are receiving some kind of IR-noise 
(maybe environment, maybe reflected, maybe dongle echo) causing bytes with 
framing errors to get passed to and handled by irtty in one go with the 
beginning of the first byte(s) from the next incoming frame. Thus we 
discard the BOF and the whole frame is missed :-(

Could you try to disable the fp-scanning in irtty_receive_buf() to see if 
this helps wrt. to dropped frames?

If it does, I'd say we should do it, i.e. completely ignore the fp-array.
Note this is not identical to old irtty either, because we don't remove 
the flagged chars. But at this point we don't know whether they are really 
bogus or it's just an IR-spike making invalid STOP bit. IMHO wrapper+crc
will detect this - do you have any objections? 

Martin

Re: [Serial 2.5]: packet drop problem (FE ?)

[Russell King]

On Fri, Nov 08, 2002 at 11:34:18PM +0100, Martin Diehl wrote:
> The next to know is whether irtty_receive_buf() reports any "Framing or 
> parity error"? IIRC with IGNPAR set we should neither get parity nor 
> framing errors reported and it seems this is how serial8250_change_speed()
> deals with ignore_status_mask. But wait - yes, 8250's receive_chars() 
> seems to accept the character,

Correct.

> but set TTY_FRAME anyway.

Only if INPCK is set.  If it's clear, then it will ignore framing and
parity errors.  (Irrespective of this, it will still internally count
them for statistical purposes, just like 2.4 used to.)

However, since INPCK is clear (from the info Jean's already sent) you'll
receive the character a TTY_NORMAL flag, even though the hardware flagged
an error.

> Ok, I think what might happen is you are receiving some kind of IR-noise 
> (maybe environment, maybe reflected, maybe dongle echo) causing bytes with 
> framing errors to get passed to and handled by irtty in one go with the 
> beginning of the first byte(s) from the next incoming frame. Thus we 
> discard the BOF and the whole frame is missed :-(

Maybe the problem is that you want to discard the bad byte (by flagging
it with a non-TTY_NORMAL flag.)

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