From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alan Subject: Re: [PATCH] libata: waits up to 10 microseconds for early irq problem Date: Tue, 28 Nov 2006 10:46:59 +0000 Message-ID: <20061128104659.4ec91296@localhost.localdomain> References: <200611180759.34622.t.powa@gmx.de> <20061118002357.564dbb9d.akpm@osdl.org> <455F790C.2030509@garzik.org> <456BDCAC.4060609@tw.ibm.com> <20061128102534.5a42c9b2@localhost.localdomain> <456C0F11.30301@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-path: Received: from outpipe-village-512-1.bc.nu ([81.2.110.250]:1240 "EHLO lxorguk.ukuu.org.uk") by vger.kernel.org with ESMTP id S935836AbWK1Kkt (ORCPT ); Tue, 28 Nov 2006 05:40:49 -0500 In-Reply-To: <456C0F11.30301@gmail.com> Sender: linux-ide-owner@vger.kernel.org List-Id: linux-ide@vger.kernel.org To: Tejun Heo Cc: albertl@mail.com, albertcc@tw.ibm.com, Jeff Garzik , Linux IDE , Mark Lord , matthieu castet , Tobias Powalowski > > The IRQ delivery is async to the I/O so this makes a lot of sense for all > > cases. > > I don't think that's true unless the controller is doing something funky > as in SET XFERMODE. Can you enlighten me? It is true for all cases. There is no synchronization between interrupt delivery and I/O cycles and both of them are asynchronous. It is especially obvious on older APIC based boxes that use a 4 wire bus to send interrupt messages around. This leads to suprising sequences like device raises IRQ kernel blocks device IRQ at chip kernel reads to post the block kernel does other stuff IRQ message finally arrives IRQ taken