Date: Wed, 4 Jun 2008 05:04:18 +1000 From: Peter Jeremy <peterjeremy@optushome.com.au> To: John Baldwin <jhb@freebsd.org> Cc: freebsd-stable@freebsd.org Subject: Re: Interrupt storm with shared interrupt on digi(4) Message-ID: <20080603190418.GP1028@server.vk2pj.dyndns.org> In-Reply-To: <200806031021.35416.jhb@freebsd.org> References: <20080603070840.GH1028@server.vk2pj.dyndns.org> <200806031021.35416.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] On 2008-Jun-03 10:21:35 -0400, John Baldwin <jhb@freebsd.org> wrote: >> In the past, I have managed to avoid the problem by putting the Digi >> card on a dedicated interrupt. For reasons I don't understand, this >> appears to mask the problem. > >That is because we leave interrupts masked until it gets an interrupt handler. >Since digi(4) doesn't register a handler, we leave the interrupt masked >unless some other device is sharing the same interrupt and registers a >handler. This is what I assumed but doesn't explain how having two digi boards that share an interrupt with each other but nothing else winds up with an interrupt storm. I will have to investigate further... >No. Even better would be if there was a way to disable interrupt generation >in the digi(4) driver via some register. Agreed. Unfortunately, the only documentation is the Linux driver and it doesn't appear to initialise the digi board any differently to FreeBSD. >> Alternatively, can anyone suggest how I can disable or mask a specified >> PCI interrupt? > >The problem is that in this case you have another driver that is using that >interrupt, so if you completely mask the interrupt the other driver will stop >getting interrupts and likely stop working. I agree that this approach is a hack - but it will let me work around the problem on the problematic system. BTW, your MUA's list-reply configuration don't recognize that freebsd-stable@ and stable@ are aliases. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkhFlbIACgkQ/opHv/APuIdXGwCeMw1WvTkZDxeuokFx52bH44hn PBgAmwXo6x/zYHzpEpfbwXlQOAjZKnFa =m39y -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080603190418.GP1028>