From owner-freebsd-hardware Wed Sep 18 23:58:22 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id XAA05699 for hardware-outgoing; Wed, 18 Sep 1996 23:58:22 -0700 (PDT) Received: from mail.crl.com (mail.crl.com [165.113.1.22]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id XAA05679 for ; Wed, 18 Sep 1996 23:58:19 -0700 (PDT) Received: from godzilla.zeta.org.au by mail.crl.com with SMTP id AA05269 (5.65c/IDA-1.5 for ); Wed, 18 Sep 1996 23:58:52 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id QAA30028; Thu, 19 Sep 1996 16:27:46 +1000 Date: Thu, 19 Sep 1996 16:27:46 +1000 From: Bruce Evans Message-Id: <199609190627.QAA30028@godzilla.zeta.org.au> To: bde@zeta.org.au, BRETT_GLASS@infoworld.com, hardware@freebsd.org Subject: Re: More or fewer IRQs? Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >If what you say is true, the only place I can be sure to save time (this is >on a 486DX4/100) is at the ICU by setting those AUTO_EOI flags. But how >safe are these? I was getting missed IDE completion interrupts with a >kernel that had AUTO_EOI_1 on, but don't know if that was the only source >of the problem. (I've changed a LOT of options in more recent kernels.) For my hardware, they either fail completely (AUTO_EOI_2 fails for one system) or are completely safe. A missing EOI is probably unrecoverable - the software doesn't send one because it expects the hardware to, and the hardware only sends for the next interrupt which never occurs. If the IDE timeout fixed the missing IDE interrupts, then they probably weren't missed because of the EOI configuration. Bruce