From mboxrd@z Thu Jan 1 00:00:00 1970 From: "B.G. Bruce" Subject: Re: Driver domain - NEW issue: IRQ handling error Date: Wed, 02 Feb 2005 17:26:24 -0400 Message-ID: <1107379584.4411.178.camel@master.vms.security> References: <1107263493.4411.22.camel@master.vms.security> <3d8eece205020117282731fd2@mail.gmail.com> <1107310185.4411.109.camel@master.vms.security> <20050202024716.GP13868@cl.cam.ac.uk> <1107367218.4411.134.camel@master.vms.security> <20050202200415.GA13868@cl.cam.ac.uk> Reply-To: bgb@nt-nv.com Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit In-Reply-To: <20050202200415.GA13868@cl.cam.ac.uk> Sender: xen-devel-admin@lists.sourceforge.net Errors-To: xen-devel-admin@lists.sourceforge.net List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , List-Archive: To: xen-devel List-Id: xen-devel@lists.xenproject.org Christian, Thank you for your time and patience in helping me to understand what is going on. It is greatly appreciated. B. On Wed, 2005-02-02 at 16:04, Christian Limpach wrote: > On Wed, Feb 02, 2005 at 02:00:18PM -0400, B.G. Bruce wrote: > > What I've actually found is that if is disable the disabling of the > > interrupt in kernel/irq/spurious.c, everything works fine. I still get > > the error messages (I didn't comment them out) about every > > 50.000-100.000 packets but I don't drop a packet and everything works as > > it should. Now obviously I don't want to keep the disabling irq > > disabled, but I'm at a loss for how to fix this otherwise. > > I think I understand now what's happening: > - since you have devices on IRQ18 in both dom0 and another domain, > all IRQ18 interrupts get delivered to both (for loop in > __do_IRQ_guest in xen/arch/x86/irq.c). > - the ide driver in dom0 will only handle IRQs for the ide controller. > - all e1000 interrupts will be counted as spurious/unhandled. > - if there's hardly any ide interrupts, you can hit the case where > of 100000 interrupts, 99900 were unhandled and this will cause the > interrupt to get disabled. > > We seem to hit the case mentioned in () above __report_bad_irq. Not > disabling the interrupt in that case is the correct thing to do, but > the sharing does certainly have a significant performance impact. > > christian > > ------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl