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
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 ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
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
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 ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
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
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
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
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 ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html