Subject: serial related crash (lockup)
To: None <firstname.lastname@example.org, email@example.com, michaelv@HeadCandy.com>
From: Gordon W. Ross <firstname.lastname@example.org>
Date: 11/16/1995 11:46:08
> Date: Wed, 15 Nov 95 15:54:27 EST
> From: Mike Long <email@example.com>
[ Machine hangs after modem power-cycle... ]
> >Date: Wed, 15 Nov 1995 08:50:04 -0600
> >From: Randy Terbush <firstname.lastname@example.org>
> [michaelv wrote:]
> >> I've seen exactly the same behavior, occasionally. Every now and then
> >> my modem will get in a funky state, and I'll just reach over and flip
> >> it off, then back on. This used to be a painless fix. Since
> >> upgrading from 1.0 to current, however, it can cause these lockups.
> >> (Yes, I'm running with my ESP-patched com.c driver now, but I'm almost
> >> positive that it did it even with the stock driver.)
> >I am *not* running with your ESP driver and still have problems.
> >My problems (Window manager dies) can be caused simply by loss
> >of PPP connection. The Xserver is still running, but all windows
> >have died.
> It can't be just that. I've had my PPP connection die quite often
> while I was in X, and X has never died on me. It may be
> modem-specific, though: I have an internal modem, so it doesn't turn
> off unless the whole box does.
> Do any of you have a voltmeter and a breakout box? The hangups and/or
> X death may occur because your modem drops DSR when you turn it off,
> or something like that.
Note that typical UARTS used for serial ports have the ability to
generate "status change" interrupts faster than the system can
service them. This can happen if (for example) one of the input
lines goes into oscillation (can happen to unconnected lines).
I have seen this happen on several PC comm. cards (back when I
maintianed drivers for an SVR4 vendor).
If you have an NMI switch, you may be able to break into the kernel
debugger to verify that you are being flooded with UART interrupts.
My conclusion after seeing that was that it is really not safe to
enable the status interrupt unless you know the cabling is correct.
If the driver wants to be paranoid, it should just poll for status
line changes (they are not time-critical if your buffering is OK).
With the status lines polled, there is a guaranteed upper-bound on
the interrupt rate that the UART can hit you with. Comforting...