"Williams, Mitch A" <[EMAIL PROTECTED]> writes:
> Chuck Ebbert wrote:
>>Are you going to post one for 2.6.20 as well? Some people might be
>>interested...
>
> The first time I posted this patch, Greg KH indicated that he thought
> it was too intrusive to add to -stable, especially considering that
"Williams, Mitch A" <[EMAIL PROTECTED]> writes:
> Chuck Ebbert wrote:
>>Are you going to post one for 2.6.20 as well? Some people might be
>>interested...
>
> The first time I posted this patch, Greg KH indicated that he thought
> it was too intrusive to add to -stable, especially considering that
Williams, Mitch A wrote:
> Chuck Ebbert wrote:
>> Are you going to post one for 2.6.20 as well? Some people might be
>> interested...
>
> The first time I posted this patch, Greg KH indicated that he thought
> it was too intrusive to add to -stable, especially considering that
> our MSI-X capable
Chuck Ebbert wrote:
>Are you going to post one for 2.6.20 as well? Some people might be
>interested...
The first time I posted this patch, Greg KH indicated that he thought
it was too intrusive to add to -stable, especially considering that
our MSI-X capable hardware isn't in the field yet.
So th
Eric W. Biederman wrote:
>Do we still need the flush the set affinity routines?
>Shouldn't flush in mask and unmask should now be enough?
Yeah, I think you're right. I've removed that call, and
we're running some basic validation on the change. I'll
post a new patch tomorrow AM.
-Mitch
-
To un
On Thu, 29 Mar 2007 13:25:34 -0400 Chuck Ebbert wrote:
>
> Are you going to post one for 2.6.20 as well? Some people might be
> interested...
Please don't drop cc:s.
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
-
To unsubscribe from this list: send the
Mitch Williams wrote:
> This patch fixes a kernel bug which is triggered when using the
> irqbalance daemon with MSI-X hardware.
>
> Because both MSI-X interrupt messages and MSI-X table writes are posted,
> it's possible for them to cross while in-flight. This results in
> interrupts being recei
Mitch Williams <[EMAIL PROTECTED]> writes:
> This patch fixes a kernel bug which is triggered when using the
> irqbalance daemon with MSI-X hardware.
>
> Because both MSI-X interrupt messages and MSI-X table writes are posted,
> it's possible for them to cross while in-flight. This results in
> i
This patch fixes a kernel bug which is triggered when using the
irqbalance daemon with MSI-X hardware.
Because both MSI-X interrupt messages and MSI-X table writes are posted,
it's possible for them to cross while in-flight. This results in
interrupts being received long after the kernel thinks t
Eric W. Biederman wrote:
>The practical question in my book is do we set the enable/disable
>methods to the same functions as the mask/unmask methods or
>do we let them default to the crazy delayed disable scenario.
>
>Given that we do have a tiny race where we need to ensure the
>MSI is disabled b
"Williams, Mitch A" <[EMAIL PROTECTED]> writes:
> Doh! I was reading the code wrong. We only mask if we're still
> handling a previous interrupt on the same vector. My bad.
>
> However, I can't really see where mask() is used outside of that
> instance. Which then leads us back to the question
Eric W. Biederman wrote:
>> However the mask function is called at EVERY interrupt,
>> so this change would be VERY expensive.
>
>If true I think that would be bad. However I don't see it.
>Where in handle_edge_irq do we mask the interrupt?
>The only place I see us calling ->mask is from move_nat
"Williams, Mitch A" <[EMAIL PROTECTED]> writes:
> Eric W. Biederman wrote:
>>
>>> Because enabling and disabling the MSI interrupt is done through
>>> config space, and config space writes are not posted. So we won't
>>> see the problem that we do with MSI-X.
>>
>>Normally this is true. However
Eric W. Biederman wrote:
>
>> Because enabling and disabling the MSI interrupt is done through
>> config space, and config space writes are not posted. So we won't
>> see the problem that we do with MSI-X.
>
>Normally this is true. However when we have memory mapped pci config
>space the writes
"Williams, Mitch A" <[EMAIL PROTECTED]> writes:
> Grant Grundler wrote:
>
>>Why wouldn't MSI have the same problems as MSI-X?
>>
>
> Because enabling and disabling the MSI interrupt is done through
> config space, and config space writes are not posted. So we won't
> see the problem that we do w
Grant Grundler wrote:
>Why wouldn't MSI have the same problems as MSI-X?
>
Because enabling and disabling the MSI interrupt is done through
config space, and config space writes are not posted. So we won't
see the problem that we do with MSI-X.
-Mitch
-
To unsubscribe from this list: send the
On Mon, Mar 26, 2007 at 04:18:22PM -0700, Mitch Williams wrote:
> This patch fixes a kernel bug which is triggered when using the
> irqbalance daemon with MSI-X hardware.
>
> Because both MSI-X interrupt messages and MSI-X table writes are posted,
> it's possible for them to cross while in-flight.
Grant Grundler <[EMAIL PROTECTED]> writes:
> On Tue, Mar 27, 2007 at 07:23:16AM -0600, Eric W. Biederman wrote:
>> I guess I should add that I'm not certain that the code is exactly correct
>> there are weird differences between enable/disable and mask.
>
> My understanding was "enable" would clea
On Tue, Mar 27, 2007 at 07:23:16AM -0600, Eric W. Biederman wrote:
> I guess I should add that I'm not certain that the code is exactly correct
> there are weird differences between enable/disable and mask.
My understanding was "enable" would clear (or ignore) pending interrupts
and "unmask" would
Greg KH <[EMAIL PROTECTED]> writes:
> On Mon, Mar 26, 2007 at 04:18:22PM -0700, Mitch Williams wrote:
>> This patch fixes a kernel bug which is triggered when using the
>> irqbalance daemon with MSI-X hardware.
>>
>> Because both MSI-X interrupt messages and MSI-X table writes are posted,
>> it's
Greg KH <[EMAIL PROTECTED]> writes:
> How well does this play with the MSI core changes that Michael Ellerman
> has proposed on the linux-pci mailing list?
The patch looks reasonable and it is independent of those changes.
This just modifies the helper code for using the msi capability itself as
On Mon, Mar 26, 2007 at 04:18:22PM -0700, Mitch Williams wrote:
> This patch fixes a kernel bug which is triggered when using the
> irqbalance daemon with MSI-X hardware.
>
> Because both MSI-X interrupt messages and MSI-X table writes are posted,
> it's possible for them to cross while in-flight.
This patch fixes a kernel bug which is triggered when using the
irqbalance daemon with MSI-X hardware.
Because both MSI-X interrupt messages and MSI-X table writes are posted,
it's possible for them to cross while in-flight. This results in
interrupts being received long after the kernel thinks t
23 matches
Mail list logo
