Subject: Re: blocking tcsetattr in pppd 2.4.0
To: None <netbsd-users@netbsd.org>
From: Brad du Plessis <bradd@cat.co.za>
List: netbsd-users
Date: 06/01/2004 15:13:40
Setting the TCSAFLUSH flag to TCSANOW only means that the process locks up
later when the tty descriptor is closed. The close() obviously does some
data flushing that blocks forever if unsuccessful. Would the clearing of the
DTR line earlier in the finish_tty() function in tty.c perhaps have any
effect on this?

Brad

----- Original Message ----- 
From: "Christos Zoulas" <christos@zoulas.com>
To: <netbsd-users@netbsd.org>
Sent: Monday, May 31, 2004 11:04 PM
Subject: Re: blocking tcsetattr in pppd 2.4.0


> In article <03e701c446f3$e34d7cc0$4a22a8c0@intervid.co.za>,
> Brad du Plessis <bradd@cat.co.za> wrote:
> >Hi all,
> >
> >I've had an issue from time to time with pppd 2.4.0. Unfortunately the
> >problem is not easily repeatable but it will occur on occasion when I try
> >and kill a pppd listening process. Having sent the kill signal (SIGTERM),
> >the process fails to exit. I put printouts in the pppd code to figure out
> >where exactly the problem lies and it appears that having received the
kill
> >signal and doing all the tty cleanup before exit, pppd fails to return
from
> >the restore_tty() function called from finish_tty() in tty.c . Looking at
> >restore_tty() in sys-bsd.c, I assume the problems lies with the line:
> >
> >tcsetattr(fd, TCSAFLUSH, &inittermios)
> >
> >My thoughts are that before applying the attributes set in the structure
> >inittermios, tcsetattr attempts to flush all data written to descriptor
fd
> >to the terminal and for some reason it is unable to do this.
> >
> >Does this indicate a problem with the modem or serial port?
> >
> >The attribute change turns off echoing to avoid a loop between tty and
the
> >modem, is this line essential, why would echoing be enabled in the first
> >place?
> >
> >What effect would changing the TCSAFLUSH flag to TCSANOW have?
> >
> >Any ideas why TCSAFLUSH was used instead of TCSANOW?
> >
> >If TCSANOW was used and the attributes were successfully changed, would I
> >then see a problem when a close is called for this descriptor if the
close
> >tries a flush of some sort?
> >
> >Any help would be much appreciated.
>
> I have no idea why flush was chosen instead of now. But try your change
> and if it works for you, please send-pr.
>
> christos
>