> On 14 March 2017 at 17:55 Dan Williams <d...@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...? _______________________________________________ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
