ACK
> -Original Message-
> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@lists.osuosl.org] On
> Behalf Of Alex Williamson
> Sent: Monday, July 27, 2015 4:19 PM
> To: intel-wired-...@lists.osuosl.org; Kirsher, Jeffrey T
> Cc: net...@vger.kernel.org; linux-kernel@vger.kernel.org
>
ACK
> -Original Message-
> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@lists.osuosl.org] On
> Behalf Of Alex Williamson
> Sent: Monday, July 27, 2015 4:19 PM
> To: intel-wired-...@lists.osuosl.org; Kirsher, Jeffrey T
> Cc: net...@vger.kernel.org; linux-kernel@vger.kernel.org
>
ACK
-Original Message-
From: Intel-wired-lan [mailto:intel-wired-lan-boun...@lists.osuosl.org] On
Behalf Of Alex Williamson
Sent: Monday, July 27, 2015 4:19 PM
To: intel-wired-...@lists.osuosl.org; Kirsher, Jeffrey T
Cc: net...@vger.kernel.org; linux-kernel@vger.kernel.org
Subject:
ACK
-Original Message-
From: Intel-wired-lan [mailto:intel-wired-lan-boun...@lists.osuosl.org] On
Behalf Of Alex Williamson
Sent: Monday, July 27, 2015 4:19 PM
To: intel-wired-...@lists.osuosl.org; Kirsher, Jeffrey T
Cc: net...@vger.kernel.org; linux-kernel@vger.kernel.org
Subject:
Acked-by: Mitch Williams <[EMAIL PROTECTED]>
>This is a simplified and actually more comprehensive form of a bug
>fix from Mitch Williams <[EMAIL PROTECTED]>.
[snip]
>Then if people do have a kernel message stating "No irq for vector" we
>will know it is yet another novel cause that needs a
Acked-by: Mitch Williams [EMAIL PROTECTED]
This is a simplified and actually more comprehensive form of a bug
fix from Mitch Williams [EMAIL PROTECTED].
[snip]
Then if people do have a kernel message stating No irq for vector we
will know it is yet another novel cause that needs a complete new
Eric W. Biederman wrote:
>The bug report would be phrased as someone seeing "No irq for vector"
>on x86_64. Unless they are a skilled developer they are unlikely to
>trace it down to not flushing posted writes to a MSI bar during irq
>migration. It part it is a subtle hardware/software race.
>
Greg KH wrote:
>
>> Perhaps we should put this into 2.6.22 then backport it to
>2.6.21.x once it
>> seems safe to do so. If we decide to go this way, we'll
>need to ask Mitch
>> to remind us to do the backport at the appropriate time,
>else we'll surely
>> forget.
>
>Yes, that's what I just
Greg KH wrote:
Perhaps we should put this into 2.6.22 then backport it to
2.6.21.x once it
seems safe to do so. If we decide to go this way, we'll
need to ask Mitch
to remind us to do the backport at the appropriate time,
else we'll surely
forget.
Yes, that's what I just asked him to
Eric W. Biederman wrote:
The bug report would be phrased as someone seeing No irq for vector
on x86_64. Unless they are a skilled developer they are unlikely to
trace it down to not flushing posted writes to a MSI bar during irq
migration. It part it is a subtle hardware/software race.
I have
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
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
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
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 the
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
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 before
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
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
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
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
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 could
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_native_irq
Greg KH wrote:
>Well, I'm sure you can agree that it is _very_ late in the 2.6.21
>release cycle to expect to get this in for that kernel. How about
>waiting for 2.6.22 and if it's a big deal, getting it into the
>2.6.21-stable tree if needed.
>
>So far I have not seen any bug reports that this
Greg KH wrote:
Well, I'm sure you can agree that it is _very_ late in the 2.6.21
release cycle to expect to get this in for that kernel. How about
waiting for 2.6.22 and if it's a big deal, getting it into the
2.6.21-stable tree if needed.
So far I have not seen any bug reports that this patch
>On Tue, Feb 01, 2005 at 12:38:00AM -0800, Greg KH wrote:
>Ick, no. Pulled back out, as it doesn't even compile :(
>
Agreed. Ick. Not necessary at all, so please drop this one on the
floor.
-Mitch
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
On Tue, Feb 01, 2005 at 12:38:00AM -0800, Greg KH wrote:
Ick, no. Pulled back out, as it doesn't even compile :(
Agreed. Ick. Not necessary at all, so please drop this one on the
floor.
-Mitch
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a
This patch corrects some errors that we saw while writing to sysfs
files.
- Attempts to open the file in append mode result in error
- Writes are buffered and flushed to the kobject owner during close
- Attempts to seek on sysfs files result in error
Generated from 2.6.11-rc1.
It's not a big
This patch corrects some errors that we saw while writing to sysfs
files.
- Attempts to open the file in append mode result in error
- Writes are buffered and flushed to the kobject owner during close
- Attempts to seek on sysfs files result in error
Generated from 2.6.11-rc1.
It's not a big
28 matches
Mail list logo
