From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [RFC] Spurious PIC interrupts Date: Wed, 29 Aug 2012 10:08:35 +0100 Message-ID: <503DDC13.30206@citrix.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Keir Fraser Cc: Jan Beulich , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org On 28/08/12 22:32, Keir Fraser wrote: > On 28/08/2012 20:59, "Andrew Cooper" wrote: > >> Since Jan's patch to print and mask bogus PIC vectors, we have found >> some issues on older hardware were supurious PIC vectors are being >> repeatedly logged, as spurious vectors will ignore the relevant mask bit. >> >> The log message is deceptive in the case of a spurious vector. I have >> attached an RFC patch which changes the bogus_8259A_irq logic to be able >> to detect spurious vectors and be rather less verbose about them. >> >> The new bogus_8259A_irq() function is basically a copy of >> _mask_and_ack_8259A_irq(), but returning a boolean indicating whether it >> was a genuine interrupt or not, which controls whether the "No irq >> handler" message in do_IRQ gets printed or not. >> >> Jan: are you happy with the style of the adjustment, or could you >> suggest a better way of doing it? > No, you should make the change to _mask_and_ack_8259A_irq() itself, and > callers which do not care about the return code can simply discard it. Ok - I initially avoided that because _mask_and_ack_8259A_irq() is used to fill a function pointer structure, and preferred less change to the core. I will re-design somewhat with these points in mind. ~Andrew > > I hardly even want one instance of that appalling function in the tree, let > alone two! Terrible abuse of goto, and I'm pretty laid back about goto use. > > And we don't use True/False anywhere else in Xen. We don't even have any > centralised definition of true/false of any kind, so you should really just > use 1/0 directly. Alternatively you could propose a patch to define > true/false in our types.h, and use those. I don't know where the capitalised > True/False came from! > > -- Keir > > -- Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer T: +44 (0)1223 225 900, http://www.citrix.com