From owner-freebsd-current  Wed May 21 05:05:23 1997
Return-Path: <owner-current>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id FAA06780
          for current-outgoing; Wed, 21 May 1997 05:05:23 -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 FAA06771;
          Wed, 21 May 1997 05:05:15 -0700 (PDT)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id VAA21927; Wed, 21 May 1997 21:55:52 +1000
Date: Wed, 21 May 1997 21:55:52 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199705211155.VAA21927@godzilla.zeta.org.au>
To: ache@nagual.pp.ru, bde@zeta.org.au
Subject: Re: What happens with sio?
Cc: current@freebsd.org, phk@freebsd.org
Sender: owner-current@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

>Now I always got this diagnostic at reboot stage after installing recent
>-current...

>May 20 23:21:43 nagual /kernel: sio1: 65 events for device with no tp

The new fifo size detection code generates an interrupt although all
device interrupts are masked.  This happens because it doesn't preserve
the MCR_IENABLE bit when enabling and disabling loopback mode.  The IRQ
usually floats high, causing an interrupt.

The interrupt handler finds work to do because the new code is sloppy
about cleaning up (65 + 64 + 1 = 1 output completion + 1 character
received).  The sloppyness is not a bug, it just makes detection of the
problem easy by forcing some events which get reported by diagnostic
code.

There is no real problem in this case.  Interrupts are masked in the ICU
until the device is fully initialized.  This prevents problems when the
loopback mode is set. Resetting the mcr to 0 instead of restoring it to
com->mcr_image is what leaves a hot interrupt.  The mismatch between the
mcr and its image is fixed up on first open by believing that the image
is correct.

Bruce