rolfe@w3vh.UUCP (Rolfe Tessem) (03/13/88)
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. Recently the rate that I'm experiencing this panic has also
increased, to the point that it happens almost every morning. Anyone
have any ideas on why this is happening, and any possible sytem inter-
actions that may be causing it? I'm running HDB uucp, for what it's
worth...
--
UUCP: {uunet}!w3vh!rolfe | Rolfe Tessem
ARPA: w3vh!rolfe@uunet.UU.NET | P.O. Box 793
PACKET RADIO: W3VH@WA2PVV | Great Barrington, MA 01230terry@wsccs.UUCP (terry) (03/25/88)
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' |
rolfe@w3vh.UUCP (Rolfe Tessem) (03/27/88)
In article <382@wsccs.UUCP>, terry@wsccs.UUCP (terry) writes: > 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. As I mentioned in the original article, I'm already using the improved uport serial driver, which is supposed to cure the rmsd panic problem. But after tearing my hair out over this, I believe I tracked it down to a serial board problem. I'd been using a "dumb" MS-400 4-port serial board, with only the two stock ports and interrupts enabled. After swapping it out and replacing it with a "standard" two serial port plus parallel port card, the system has been up for a week now without burping. So, at least circumstantially, I'm ready to believe that it was a hardware and/or interrupt problem. For the record, I'm using a MAXUM 2400 baud Hayes clone, with DTR following correctly. All other hardware is pretty vanilla, and I am running the production release of DOSMerge. -- UUCP: {uunet}!w3vh!rolfe | Rolfe Tessem ARPA: w3vh!rolfe@uunet.UU.NET | P.O. Box 793 PACKET RADIO: W3VH@WA2PVV | Great Barrington, MA 01230 IP ADDRESS: 44.44.0.1 | (413) 528-5966