termios+PTY=real-time killer? (was Re: Interrupt Latency on PPC)
Thomas Doerfler
Thomas.Doerfler at imd-systems.de
Tue Nov 20 20:43:22 UTC 2001
Hi all,
> I'm confused.
> I see In termios.c: (4.5.0)
>
> osend (const char *buf, int len, struct rtems_termios_tty *tty)
> {
> unsigned int newHead;
> rtems_interrupt_level level;
> rtems_status_code sc;
>
> ** if (!tty->device.outputUsesInterrupts) {
> ** (*tty->device.write)(tty->minor, buf, len);
> ** return;
> ** }
> ** Is this no use??? Or you are talking about something else?
> ...................
finally someone really belives in my software!
I had no time to recheck termios polled mode in the last days, but I
was curious what I have written some years ago. From a first glance
I had the impression, that polled mode runs with interrupts enabled,
but I was not sure and everybody else seemed to be sure that
interrupts were blocked so....
I tried it out ten minutes ago on a mc68360 system (based on a
rather new termios code including task-driven mode). I use a
standard serial device in polled mode. I have set breakpoints into
the driver's "polledWrite" and "polledRead" function. And interrupts
are definitively enabled when these functions get called.
I have lokked into "termios.c" again. The ".write" function gets
called in various places, but only two places are used, when the
device is in polled mode: It's the location that Tu Juan pointed out
(see quoted section above) and in "termios_set_flowctrl".
In the second location, ".write" is called with interrupts disabled,
but this is executed only, when somebody enables or disables flow
control (XON/XOFF) mode in an "ioctl" call. It is not neccesary to
block interupts here in polled mode and that should definitively be
fixed, but I think this is not a realy issue.
So, finally I am rather sure: termios does not kill realtime in
polled mode.
Bye,
Thomas.
> rtems_interrupt_disable (level);
> while (newHead == tty->rawOutBufTail) {
> tty->rawOutBufState = rob_wait;
> rtems_interrupt_enable (level);
> sc = rtems_semaphore_obtain
> (tty->rawOutBufSemaphore,
>
RTEMS_WAIT,
>
RTEMS_NO_TIMEOUT);
> if (sc != RTEMS_SUCCESSFUL)
> rtems_fatal_error_occurred (sc);
> rtems_interrupt_disable (level);
> }
> tty->rawOutBuf[tty->rawOutBufHead] = *buf++;
> tty->rawOutBufHead = newHead;
> if (tty->rawOutBufState == rob_idle) {
> /* check, whether XOFF has been received */
> if (!(tty->flow_ctrl & FL_ORCVXOF)) {
> ** (*tty->device.write)(tty->minor,
> (char
> *)&tty->rawOutBuf[tty->rawOutBufTail],1);
> }
> else {
> /* remember that output has been stopped due
to flow
> ctrl*/
> tty->flow_ctrl |= FL_OSTOP;
> }
> tty->rawOutBufState = rob_busy;
> }
> rtems_interrupt_enable (level);
>
>
> Have a nice day!
>
> Juan Tu
>
>
> -----Original Message-----
> From: till at MAILBOX.SLAC.Stanford.EDU
> [mailto:till at MAILBOX.SLAC.Stanford.EDU]On Behalf Of Till Straumann
> Sent: 2001?11?16? 12:21
> To: Fernando RUIZ CASAS (E-mail)
> Cc: 'RTEMS List'; joel.sherrill at oarcorp.com
> Subject: termios+PTY=real-time killer? (was Re: Interrupt Latency
on PPC)
>
>
> "Fernando RUIZ CASAS (E-mail)" wrote:
>
> > Hi.
> > Is the PTY driver the pty.c file placed close to telnetd.c?
> >
> > This pty driver doesn't make any special thing with termios.
> > If the tcp/ip works fine the driver also.
> >
>
> We are talking about the very one. I agree, pty.c does not do
anything
> special. However, termios [under some circumstances] calls
> pty's pollWrite() function with _Interrupts_disabled_:
>
> rtems_interrupt_disable(level);
> ...
> tty->device.write(...);
> ...
> rtems_interrupt_enable(level);
>
> Because PTY's pollWrite() does socket/IO, I guess it could even
> block! - Or am I missing something?
>
> I suppose that termios could relax its interrupt-disabling policy
> in task driven mode. PTY should then probably be run in task
> driven or polled mode.
>
> -- Till
>
> >
> > Perhaps I'm speaking about other oignons.
> >
> > Fernando RUIZ CASAS
> > home:correo at fenando-ruiz.com
> > work:fernando.ruiz at ctv.es
> >
> > -----Mensaje original-----
> > De: till at MAILBOX.SLAC.Stanford.EDU
> > [mailto:till at MAILBOX.SLAC.Stanford.EDU]En nombre de Till
Straumann
> > Enviado el: viernes, 16 de noviembre de 2001 2:26
> > Para: RTEMS List; joel.sherrill at oarcorp.com
> > Asunto: Re: Interrupt Latency on PPC
> >
> > Things get _really_ bad when the PTY driver is
> > heavily used. I measured IRQ latencies of ~200us
> > during quite short measurement intervals (remember,
> > we're doing statistics here). This is in the order of
> > 100 times the average.
> >
> > I guess that the problem is caused by termios.c
> > which under some circumstances calls the
> > device's 'write' callback with _IRQs_disabled_.
> > The PTY driver's write callback is a
> >
> > write(socket,...)
> >
> > outchh!
> >
> > Is there a termios expert out there who could explain
> > to me what really needs to be protected from interrupts?
> >
> > Also, shouldn't the PTY driver run in task driven
> > (as opposed to the current IRQ driven) mode?
> >
> > -----Mensaje original-----
> > De: till at MAILBOX.SLAC.Stanford.EDU
> > [mailto:till at MAILBOX.SLAC.Stanford.EDU]En nombre de Till
Straumann
> > Enviado el: viernes, 16 de noviembre de 2001 2:26
> > Para: RTEMS List; joel.sherrill at oarcorp.com
> > Asunto: Re: Interrupt Latency on PPC
> >
> > Things get _really_ bad when the PTY driver is
> > heavily used. I measured IRQ latencies of ~200us
> > during quite short measurement intervals (remember,
> > we're doing statistics here). This is in the order of
> > 100 times the average.
> >
> > I guess that the problem is caused by termios.c
> > which under some circumstances calls the
> > device's 'write' callback with _IRQs_disabled_.
> > The PTY driver's write callback is a
> >
> > write(socket,...)
> >
> > outchh!
> >
> > Is there a termios expert out there who could explain
> > to me what really needs to be protected from interrupts?
> >
> > Also, shouldn't the PTY driver run in task driven
> > (as opposed to the current IRQ driven) mode?
> >
> > -- Till.
--------------------------------------------
IMD Ingenieurbuero fuer Microcomputertechnik
Thomas Doerfler Herbststrasse 8
D-82178 Puchheim Germany
email: Thomas.Doerfler at imd-systems.de
PGP public key available at: http://www.imd-systems.de/pgp_key.htm
More information about the users
mailing list