From owner-freebsd-hackers Sun Nov 26 22:26:03 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id WAA06089 for hackers-outgoing; Sun, 26 Nov 1995 22:26:03 -0800 Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.20.4]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id WAA06084 for ; Sun, 26 Nov 1995 22:25:59 -0800 Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id AAA10644; Mon, 27 Nov 1995 00:23:17 -0600 From: Joe Greco Message-Id: <199511270623.AAA10644@brasil.moneng.mei.com> Subject: Re: 16 ports Boca - anyone using it? To: rich@spirit.com.au (Rich Siggs) Date: Mon, 27 Nov 1995 00:23:17 -0600 (CST) Cc: hsu@clinet.fi, msmith@atrad.adelaide.edu.au, freebsd-hackers@freefall.freebsd.org In-Reply-To: <199511270541.QAA16483@pod.spirit.com.au> from "Rich Siggs" at Nov 27, 95 04:41:20 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > I've done testing of this port-no-probe behaviour on both my AST/4 > cards & the BOCA. Both of them have the _potential_ to fail a port's probe if > DCD is set, but not all DCD-active ports fail a crash-reboot probe.. > However, a port that has DCD _&_ either TX or RX at the crash is bound to fail > the probe (ain't 100%, but certainly 75% probable ;) *Hmm* > > Could this be related to the 16550A's, or (as suggested) some code in the > boot probe? Hmmmm... that could be what I saw the other day :-) As a related topic: I've been having very occasional problems with a BB2016 (very occasional ~== every week or two). All the ports just "up and die". They come back after a reboot. Having caught an incident in progress, I did some "debugging" and ran cu on a port. I typed "AT" and saw my echo, but no response from the modem - until I hit another key. Hmmm, having some familiarity with that particular symptom from past lives, I poke around further, run systat and notice that there are ZERO interrupts coming in from the board. (explanation: the only way that input arrives is when it checks as the output is sent). Um. "Fascinating", I say. I didn't have any diagnostic tools handy so I rebooted the box and wrote a little program that would page me if the board died again. The next day I went and hooked up my trusty logic probe, and the wait began. :-) A week later (last nite, actually!), I got a page, and fortunately somebody was at the office to observe the logic probe. The interrupt line is being held ACTIVE....???!!! (solid red on the probe, normally green). Do any sio-shared-interrupt-geniuses have any ideas? I can picture all sorts of plausible race conditions and I have no idea what the code is doing. My next "well lets try this" idea is to try opening and read/writing all the ports the next time my BB2016 gets in this state, to see if that un-wedges the interrupt. Haven't written the code to do this yet, however... Comments, etc.,? ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/342-4847