Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 21 Jan 1995 15:20:23 +1100
From:      Bruce Evans <bde@zeta.org.au>
To:        hackers@FreeBSD.org, luigi@labinfo.iet.unipi.it
Subject:   Re: sio.c...
Message-ID:  <199501210420.PAA10155@godzilla.zeta.org.au>

next in thread | raw e-mail | index | archive | help
>The first is easy, and deals with avoding the problem with processes
>which are not able to exit in case of hardware problems.

>In sioclose(), on 2.0R the call to the line_close routine is surrounded
>by a timeout/untimeout pair:

>	timeout(wakeup, TSA_OCOMPLETE(tp), 60 * hz);
>	(*linesw[tp->t_line].l_close)(tp, flag);
>	untimeout(wakeup, TSA_OCOMPLETE(tp));

>while 1.1.5R has only the call to l_close. Would it be possible to add
>the calls to timeout/untimeout on 1.1.5, or there are other changes
>needed ?

The timeouts are actually in a version later than 2.0R, and don't work
(wakeup() doesn't cause the tsleep() in ttywait() to return
EWOULDBLOCK).  -current has a better fix for the problem.  The tsleep()
in ttywait() uses a timeout (tp->t_timeout, default 0) and you can
change the timeout using comcontrol.  This involves Simple changes to
<sys/tty.h>, kern/tty.c and comcontrol.[c8].

>On the same 1.1.5 system here, I found out that a process here keeps
>blocking with WCHAN="siotx" (this happens with mgetty, when a
>particolar user drops the session, probably not in the most
>appropriate way). "siotx" seems to be present only in sio.c, function
>comparam(tp, t), in the following section of code, which is exactly the
>same as in 2.0R (I have no current sources handy):

>        disable_intr();
>retry:
>        com->state &= ~CS_TTGO;
>        enable_intr();
>        while ((inb(com->line_status_port) & (LSR_TSRE | LSR_TXRDY))
>               != (LSR_TSRE | LSR_TXRDY)) {
>                error = ttysleep(tp, TSA_OCOMPLETE(tp), TTIPRI | PCATCH,
>                                 "siotx", hz / 100);
>...

>from which it appears that there is no timeout or other way out in case
>the modem is not responding properly. Wouldn't it be better to add an
>emergemcy exit after a proper timeout ?

Perhaps.  The LSR_TSRE and LSR_TXRDY bits are guaranteed to go on in
a short time ((transmit_fifo_size + 1) * time_to_transmit_one_char)
if the hardware and software are working.  It's not practical to check
for all h/w bugs.  I'll check that there are no races in the s/w.
(There used to be a bug involving not fully stopping transmission
(something turned CS_TTGO back on).  For transmission to continue
"forever", something must supply new output "forever".  The ttysleep()
probably allows other processes to supply output.  Echoing of input
creates output.).

Bruce



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199501210420.PAA10155>