[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <m1sl8nn82i.fsf@ebiederm.dsl.xmission.com>
Date: Tue, 19 Jun 2007 11:54:45 -0600
From: ebiederm@...ssion.com (Eric W. Biederman)
To: "Darrick J. Wong" <djwong@...ibm.com>
Cc: "Siddha, Suresh B" <suresh.b.siddha@...el.com>,
linux-kernel@...r.kernel.org
Subject: Re: Device hang when offlining a CPU due to IRQ misrouting
"Darrick J. Wong" <djwong@...ibm.com> writes:
> On Mon, Jun 18, 2007 at 04:54:34PM -0700, Siddha, Suresh B wrote:
>
>> > <call to set_affinity>
>> > [ 256.298787] irq=4341 affinity=d
>> > <ethernet on irq 4341 stops working>
>>
>> And just to make sure, at this point, your MSI irq 4341 affinity
>> (/proc/irq/4341/smp_affinity) still points to '2'?
>
> Actually, it's 0xD. From the kernel's perspective the mask has been
> updated (and I even stuck a printk into set_msi_irq_affinity to verify
> that the writes are happening) but ... the hardware doesn't seem to
> reflect this. I also tried putting read_msi_msg right afterwards to
> compare contents, though it complained about all the MSIs _except_ for
> 4341. (Of course, I could just be way off on the effectiveness of
> that.)
The fact that MSI interrupts are having problems is odd. It is possible
that we still have a bug in there somewhere but msi interrupts should
be safe to migrate outside of irq context (no known hardware bugs).
As we can actually synchronize with the irq source and eliminate all
of the migration races.
The non-msi case requires hitting a hardware race that is rare enough
you should not normally have problems.
Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists