'port forced close' after failed ppp

[Colin Helliwell]

> On 14 March 2017 at 17:55 Dan Williams <dcbw at redhat.com> wrote:
> 
> On Tue, 2017-03-14 at 14:18 +0000, Colin Helliwell wrote:
> 
> > Still trying to get to the bottom of this problem.
> > What are the events which can cause the G_IO_HUP (in MM)?
> 
> G_IO_HUP == POLLHUP from the standard C library (see
> /usr/include/bits/poll.h). It's coming directly from the kernel fd for
> the serial port, which in turn comes directly from the driver and the
> TTY subsystem. See drivers/tty/n_tty.c which is the default serial
> line discipline on Linux (IIRC).
> 
> The places n_tty sets POLLHUP are both in n_tty_poll():
> 
> if (test_bit(TTY_OTHER_CLOSED, &tty->flags))
>  mask |= POLLHUP;
> ** this one doesn't apply, since it's only set by drivers/tty/pty.c and
> we don't use pseudo-ttys for modem stuff.
> 
> if (tty_hung_up_p(file))
>  mask |= POLLHUP;
> 
> tty_hung_up_p() will only return true if __tty_hangup() has been
> called, which can happen from:
> 
> 1) tty_vhangup(): called on USB device disconnect, UART port removal
> (called from a lot of UART drivers, maybe yours?), from TIOCVHANGUP,
> and a couple other places. Could be the culprit.
> 
> 2) tty_hangup(): called from uart_handle_dcd_change() (which shouldn't
> affect anything that sets CLOCAL, but who knows...), and
> tty_port_tty_hangup(). This last one is called mostly from serial
> drivers when the DCD has changed.
> 
> Check your mux driver, does it do any calls to tty_port_tty_hangup() or
>  tty_hangup()?
> 
> Dan
> 

No sign in the source of any calls to those functions.
Could the signal be being sent from a hardware and 'physical uart driver' level (e.g. due to h/w handshake lines changing), to MM, without going through the mux driver...?