Hi,
I have a Debian system,
Linux version 2.6.20.4 (root@xxxxxxxxxxxxxxxxxxxxxxxxxxxx) (gcc version
4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #1 SMP PREEMPT Fri Apr 6
13:41:02 CEST 2007
The motherboard has one serial port and the pci card (PCI 9835 Multi-I/O
Controller) has another two. When autoconfig is set for setserial we get:
/dev/ttyS0 at 0x03f8 (irq = 4) is a 16550A
/dev/ttyS1 at 0x1030 (irq = 20) is a 16550A
/dev/ttyS2 at 0x1028 (irq = 20) is a 16550A
I have an application that works well if I use ttyS0 but not from ttyS1 or
ttyS2. I loose characters in the latter case. It looks if only the last
character is outputted on the port...
I have the assumption that it must be possible to "set" the ports with
setserial as a 16450.
/dev/ttyS0 at 0x03f8 (irq = 4) is a 16450
/dev/ttyS1 at 0x1030 (irq = 20) is a 16450
/dev/ttyS2 at 0x1028 (irq = 20) is a 16450
Doing that makes ttyS0 not longer work, here only the last character is
output. This is similar to ttyS1/ttyS2 in 16550A mode. ???
If I modify the application like:
#ifdef _NORMAL_SERIAL_OUT
write(hartfd.fd, &odbuf, pcnt);
#else
int fd;
#define PORT_ADDR 0x3f8
unsigned char cc= 0x00;
fd=open("/dev/port", O_RDWR);
for( i =0 ; i<= pcnt; i++){
do {
lseek(fd, PORT_ADDR+5, 0); // LSR
read(fd, &cc, 1);
fprintf(stderr, "read LSR=%02x\n", cc);
} while (!(cc & 0x20));
lseek(fd, PORT_ADDR, 0); // THR
write(fd, &odbuf[i], 1);
fprintf(stderr, "write THR=%02x\n",odbuf[i]);
}
close(fd);
#endif
Everything is output on ttyS0, ttyS1 and ttyS2 (If I set the PORT_ADDR
correct)
So the _device_ works well.
I noticed though that for port ttyS0 the stderr(log) shows
read LSR=60 <--
write THR=ff
read LSR=00 <--
...
read LSR=20 <--
write THR=ff
read LSR=00
...
which looks OK but for the NMOS chip I get
For ttyS1/ttyS2 I get
read LSR=60 <--
write THR=ff
read LSR=40 <-- (repeat 24 times)
...
read LSR=00 <--
...
read LSR=20 <--
write THR=ff
read LSR=00
...
So this chip does not clear XMIT Empty right away but it took time before
it was cleared.
I feel that somewhere the driver is confused by this. But I find it
difficult to follow the flow of the data in the serial
driver in the kernel.
I'm able and willing to do more detailed tests (even in the driver source)
if one asks for it.
Any clue?
regards
Kees
-
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
