linux-mips
[Top] [All Lists]

Re: [PATCH] SIBYTE: fix locking in set_irq_affinity

To: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Subject: Re: [PATCH] SIBYTE: fix locking in set_irq_affinity
From: Ralf Baechle <ralf@linux-mips.org>
Date: Thu, 14 May 2009 14:48:17 +0100
Cc: Martin Michlmayr <tbm@cyrius.com>, linux-mips@linux-mips.org
In-reply-to: <20090514132030.GA7926@alpha.franken.de>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <20090504215155.461B2E31C1@solo.franken.de> <20090512215556.GA4774@deprecation.cyrius.com> <20090514132030.GA7926@alpha.franken.de>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Mutt/1.5.18 (2008-05-17)
On Thu, May 14, 2009 at 03:20:30PM +0200, Thomas Bogendoerfer wrote:

> > [17179570.260000] attempted to set irq affinity for irq 8 to multiple CPUs
> > [17179570.484000] attempted to set irq affinity for irq 8 to multiple CPUs
> > [17179570.500000] attempted to set irq affinity for irq 8 to multiple CPUs
> 
> I saw them as well, either the caller of set_irq_affinity does something
> illegal or the API has changed and the message just should go away...

Several things here:

- I would be interested in the caller of set_irq_affinity here.  It seems
  like the IDE code is doing this - but why?
- the message should go away or at least be changed depend on DEBUG being
  defined.  Normal usage errors should not result in error messages to the
  console.  Heck, the kernel console is not stderr.
- the kernel's idea of interrupt mask is a different one from the hardware.
  In the kernel it is the set of CPUs one of which should process an
  interrupt.  The Sibyte hardware interprets it as the set of CPUs which
  (all!) will receive the interrupt to process.

  Ralf

<Prev in Thread] Current Thread [Next in Thread>