Re: Possible bug in serial driver 8250/8250-fourport

[Colin Laplace <haiku@bloodshed.net>]

Hello,

Thank you for your reply. Please find my answers below :

> Did you try monitoring /proc/tty/driver/serial for the ports in question
> (byte counts in and out, and any errors (framing, parity, etc)) are in
> there, you can confirm your setserial settings there too, account for all
> bytes in and out.

The number of bytes sent to TX doesn't increase when the problem occurs.
4: uart:16550A port:0000D100 irq:177 tx:99925 rx:558 RTS|DTR

> Also -- do you have software or hardware flow control going?
> i.e. how are your tty's configured?  sounds like they should be a
> raw setup -- if canonical mode or otherwise are consuming characters
> that should normally pass through to your equipment it may cause
> problems.  I have no clue what protocol your music equipment speaks.
> Might be worthwhile sending your code snippet that configures your ttys
> and if hardware flow control is involved etc.

I use the following code to open and configure the serial ports :

        port->fd = open(port->device, O_RDWR | O_NONBLOCK, 0);
        if (port->fd < 0) {
                fprintf(stderr, "Cannot open %s: ", port->device);
                perror("midiseq");
                return -errno;
        }

 cflag = B38400 | CREAD | CSIZE | CS8 | HUPCL;

        if (tcgetattr(port->fd, &tio) < 0)
                perror("tcgetattr");
        cfmakeraw(&tio);
        tio.c_lflag |= NOFLSH;
        tio.c_iflag |= IGNBRK | IGNPAR;
        tio.c_cflag |= cflag;
        tio.c_cc[VEOL] = 0; /* '\r'; */
        tio.c_cc[VERASE] = 0;
        tio.c_cc[VKILL] = 0;
        tio.c_cc[VMIN] = 0;
        tio.c_cc[VTIME] = 0;
        if (tcsetattr(port->fd, TCSANOW, &tio) < 0)
                perror("tcsetattr");

> The serial and tty layer (I've found) have been very robust for a bunch
> of multiport stuff I've been doing in the last 6 months (albeit a 2.4
> kernel).  The tty stuff really has to work right as a lot of stuff
> besides just serial ports are tty based (duh).

I didn't have this problem on 2.4 kernel. But for some reasons (preemptive 
kernel, optimized i/o scheduling...) i need to stick with 2.6.
If you need other information please let me know.

Greetings,
Colin


> Good luck w/ your project.
>
> > Hello,
> >
> > I am writing to this list because i am now clueless on a problem i am
> > having with writing data on a serial port, and now the only thing i can
> > think of is a serial driver bug.
> > The situation is the following :
> > I have a NetMos Technology PCI 9845 Multi-I/O Controller (rev 01), which
> > has four ports. Each of its ports are connected as follow :
> > - port 1 TX connected to a Midi Chipset DREAM SAM9708 port 1
> >   port 1 RX connected to FATAR midi keyboard
> > - port 2 TX connected to a Midi Chipset DREAM SAM9708 port 2
> > - port 3 connected to an external midi in/out (1)
> > - port 4 connected to an external midi in/out (2)
> >
> > This configuration has been tested on both kernel 2.6.10 with 8250
> > module, and 2.6.15 with 8250-fourport module, the problem arises on both.
> > Each of the serial ports are configured this way :
> > setserial /dev/tts/$id uart 16550A port 0x$addr irq $irq
> > ^fourport spd_cust divisor 8 low_latency
> >
> > The problem is as follow :
> > When playing MIDI data over port 1, sometimes the output just stops, the
> > data doesn't go anymore to the Dream 1 port. Then (and that's the strange
> > part), if we press a key of the FATAR keyboard (connected to the same
> > serial port but on RX), all the data that was not played comes out all of
> > a sudden, and the playback continues to be output normally. This problem
> > does *NOT* happen on any of the other serial ports, only on the one where
> > TX is connected to the dream 1 and RX to the FATAR midi keyboard.
> > I have been trying with both snd-serialmidi alsa driver, as well with a
> > homemade user-land program which drives midi events to the serial port,
> > and the problems happens on both ways. Also, very important to note : NO
> > error messages are given by write() calls when the problem arises, nor do
> > i get kernel messages.
> >
> > This situation happens very often. If you need any other information
> > please let me know. I would really appreciate any feedback you could have
> > about this matter.
> >
> > Best regards,
> > Colin Laplace
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-serial"
> > in the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-serial" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html