From owner-freebsd-hardware  Thu Jul 10 09:04:21 1997
Return-Path: <owner-hardware>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id JAA08862
          for hardware-outgoing; Thu, 10 Jul 1997 09:04:21 -0700 (PDT)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA08832;
          Thu, 10 Jul 1997 09:04:10 -0700 (PDT)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id BAA11291; Fri, 11 Jul 1997 01:55:39 +1000
Date: Fri, 11 Jul 1997 01:55:39 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199707101555.BAA11291@godzilla.zeta.org.au>
To: bde@zeta.org.au, phk@dk.tfs.com
Subject: Re: Configuring Byterunner TC-800 high speed 8-port serial card
Cc: danny@panda.hilink.com.au, freebsd-hardware@FreeBSD.ORG,
        freebsd-isp@FreeBSD.ORG, sdudley@byterunner.com
Sender: owner-hardware@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

>Speaking from experience: a correctly configured board fails the test#3
>after a crash.  Don't ask me why, but it is correctly configured, and
>I have verified the circuitry on the card myself, to make sure that it
>was possible to share the IRQs with this card.

Does OUT2 (aka MCR_IENABLE) disconnect the UARTs individually, as is
required for the non-AST multiport case?

For the non-multiport case, I have seen some cases where test #3 fails
but then succeeds when retried from ddb after a few seconds.  This may
have something to do with the fifo not being initialized early.  I've
only seen it after crashes.

Bruce