From owner-freebsd-hardware  Thu Jul 10 07:11:15 1997
Return-Path: <owner-hardware>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id HAA03670
          for hardware-outgoing; Thu, 10 Jul 1997 07:11:15 -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 HAA03648;
          Thu, 10 Jul 1997 07:11:04 -0700 (PDT)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id AAA08067; Fri, 11 Jul 1997 00:05:25 +1000
Date: Fri, 11 Jul 1997 00:05:25 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199707101405.AAA08067@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

>>No, you should keep the 0x10000 flag clear, so that a pending IRQ from
>>a higher port causes sio's test#3 to fail on a lower port, since such
>>IRQs "can't happen" (unless the multiport board is misconfigured or is
>>actually a multi-infernal modem :-).
>
>This is not true Bruce, they can happen if the sio driver doesnt disable
>interrupt sources before you reboot your kernel.  The 0x10000 flag
>is necessary if you want your sio ports after crashes.

This can't happen (except in misconfigured and buggy cases) since the
sio drivers disconnects the interrupts for all configured ports in its
first probe.  Of course, this can fail if not all ports are correctly
configured or if there is a non-sio device using an sio irq, but then
ignoring the problem won't help (except in the latter case when the
non-sio device gets completely disconnected later).

Bruce