Path: utzoo!utgpu!water!watmath!clyde!att-cb!osu-cis!tut.cis.ohio-state.edu!ut-sally!utah-cs!utah-gr!uplherc!sp7040!obie!wsccs!terry
From: terry@wsccs.UUCP (terry)
Newsgroups: comp.unix.microport
Subject: Re: system panics
Summary: Where does it hurt?
Keywords: uport panic System V/AT
Message-ID: <382@wsccs.UUCP>
Date: 25 Mar 88 06:14:47 GMT
References: <315@w3vh.UUCP>
Lines: 50

In article <315@w3vh.UUCP>, rolfe@w3vh.UUCP (Rolfe Tessem) writes:
> Recently, I downloaded the new, improved serial port driver from the
> uport BBS in the hope that it would cure my system panic problems. It
> didn't.  I generally poll for news and mail twice a day, once in early
> evening, and once between 5 and 5:30am.  The system panics invariably
> occur during the morning uucp activity, generally after some news and/or
> mail has been successfully queued, but before all the transfers are
> complete.

Does it happen with the modem online?  Are you using an internal modem, or is
DTR forced true?

Sounds like you have the System V driver bug where the system sees carrier
drop, but the modem does not hang up the phone, or is immediately called back.

What happens is that the hi->lo transition of DCD causes the driver to return
'EOF' when read from, thereby indicating that you've lost carrier.  That's
nice.  A side effect is that you can transmit to the port, but stuff coming in
goes to the noplace.  That's also acceptabl, as you do not need to read the
"NO CARRIER" to know you've lost carrier.  The problem is, that instead of just
throwing the characters away, it nulls the pointer and writes them to low core,
giving the symptom you noted.  Incidently, the port has to be opened O_NDELAY.
This has been reported to AT&T (I talked to one of the programmers in the
group who writes the stuff), and they seem to be planning on fixing the problem
in the very near future.  This problem does not occur on SCO Xenix, but *does*
happen with non-native drivers for SCO (like the SysV-derived computone drivers
you have to link in to make computone boards work; they don't anyway, unless
you twiddle the /atx/attype file -- but that's another gripe).

The only fix is to write your own drivers, or get UPort to fix them, or wait
for the real fixes from AT&T.

In the mean time, if you use a modem which responds sufficiently quickly to
a momentary DTR drop (such as AT&T modems... hhhmmmmm think there's a bit of
nepotism here?) and you have the modems set to follow DTR, it will fix it.

Don't use an internal modem with UNIX/Xenix boxes; they don't expect to not
have CTS/RTS not high all the time, and most internal modems of the Hayes
compatable variety only hold the CTS high IF they have carrier; Racal-Vadic
modems are an exception, but they're kind of inconsistant when it comes to
whether they say "\r\n ERROR", "\r\n\rERROR", or "\r\nERROR", so it's a pain
to get a dialer that works on all of them.


| Terry Lambert           UUCP: ...{ decvax, ihnp4 }                          |
| @ Century Software          : ...utah-cs!uplherc!sp7040!obie!wsccs!terry    |
| SLC, Utah                                                                   |
|                   These opinions are not my companies, but if you find them |
|                   useful, send a $20.00 donation to Brisbane Australia...   |
| 'There are monkey boys in the facility.  Do not be alarmed; you are secure' |