Acceleport loses bytes

Acceleport adapters lose input bytes, specifically byte 0xff and any following it. This happens at :

- Fedora release 13 (Goddard) kernel 2.6.33.3-85 - with  AccelePort 16em

- and   also at   ASP Linux 12 kernel 2.6.22.9-91 - with  Acceleport 8r 920.

Every time when byte 0xff arises in input stream, it is dropped by the driver together with the byte which follows this, so I don’t see these two bytes in received data.

Both these adapters work OK at RedHat 7.3.

Sounds like a port setting.

I recommend comparing the ditty.dgap -a ttyxyz between the working RH 7.3 port and non working ports to make certain they are identical.

Also, what happens if you use the built in serial port on the Fedora hosts?

Sorry, settings are identical, not counting those which don’t exist at RH 7.3 :
[root@u5 dgap]# ditty.dgap -a ttya05
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 50 bufsize 100 edelay 100
-forcedcd -altpin -fastbaud (57600) -printer eia232 -rtstoggle -dtrtoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+ RTS+ CTS- CD- DSR- RI-
speed 57600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^; erase = ^?; kill = ^U; eof = ; eol = ; eol2 = ;
swtch = ; 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 -iutf8
-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

/deb/ttyS[01] work OK.

Please post the ditty.dgap -a ttyS0 results for comparison.

There were slight differences, so I made all settings (which I can) of Digi port like ttyS0. Result is the same - byte 0xff and the following are lost.

Settungs for Digi ports:
onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 50 bufsize 100 edelay 100
-forcedcd -altpin -fastbaud (9600) -printer eia232 -rtstoggle -dtrtoggle
-rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+ RTS+ CTS- CD- DSR- RI-
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ; quit = ; erase = ; kill = ; eof = ;
eol = ; eol2 = ; swtch = ; start = ; stop = ;
susp = ; rprnt = ; werase = ; lnext = ;
flush = ; 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 -iutf8
-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

Settungs for ttyS0:
DTR+ RTS+ CTS- CD- DSR- RI-
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ; quit = ; erase = ; kill = ; eof = ;
eol = ; eol2 = ; swtch = ; start = ; stop = ;
susp = ; rprnt = ; werase = ; lnext = ;
flush = ; 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 -iutf8
-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

If you look at the ditty settings before starting the application and while the application is running, what settings are changed?

Sorry for delay, I was at holidays.

All the settings are taken when the program runs. Settings are not changed in fact, because they correspond to what the program needs.

What driver version are you using?

Do the characters display within dpa.dgap when monitoring the serial data?

> What driver version are you using?
dgap-1.3-19.src.rpm. I also tried releases 16 trough 18.

> Do the characters display within dpa.dgap when monitoring the serial data?

 Sorry, there is no program dpa.dgap, and no notion in docs, and I don't understand what monitoring do You mean.

I You are in doubt about my program: I have simply cross-connected Rx and Tx on two ports (5 and 7, to be exact), and then made:
cat file2 &
cat test test >/dev/ttya05
Binary file “test” contains all byte codes from 00 to ff. And output file “file2” lacks bytes ‘ff’ with one byte following these.

You may want to try the latest driver candidate:

ftp://ftp1.digi.com/support/beta/linux/dgap

An actual 0xff in the data is reported as 0xff 0xff, so an 0xff
followed by an 0xff is in fact an 0xff of data.

If IGNBRK is set, a break condition detected on input is ignored that is, not put on the input queue and therefore not read by any process.

If IGNBRK is not set and BRKINT is set, the break condition will flush the input and output queues, and if the terminal is the controlling terminal of a foreground process group, the break condition will generate a single SIGINT signal to that foreground process group. If neither IGNBRK nor BRKINT is set, a break condition is read as a single 0x00, or if PARMRK is set, as 0xff 0x00 0x00.

If IGNPAR is set, a byte with a framing or parity error (other than
break) is ignored.

If PARMRK is set, and IGNPAR is not set, a byte with a framing or parity error (other than break) is given to the application as the three-byte sequence 0xff 0x00 X, where 0xff 0x00 is a two-byte flag preceding each sequence and X is the data of the byte received in error. To avoid ambiguity in this case, if ISTRIP is not set, a valid byte of 0xff is given to the application as 0xff 0xff. If neither PARMRK nor IGNPAR is set, a framing or parity error (other than break) is given to the application as a single byte 0x00."

If you continue to experience problems with this, I recommend obtaing an strace and contacting Digi Tech. Support.