RE: [Intel-wired-lan] [PATCH 1/2] igb: Teardown SR-IOV before unregister_netdev()

2015-07-27 Thread Williams, Mitch A
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 > Su

RE: [Intel-wired-lan] [PATCH 2/2] ixgbe: Teardown SR-IOV before unregister_netdev()

2015-07-27 Thread Williams, Mitch A
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 > Su

RE: [PATCH] msi: Immediately mask and unmask msi-x irqs.

2007-04-03 Thread Williams, Mitch 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 comple

RE: [PATCH 2.6.21-rc5] Flush MSI-X table writes (rev 3)

2007-03-30 Thread Williams, Mitch A
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. > >

RE: [PATCH 2.6.21-rc5] Flush MSI-X table writes (rev 3)

2007-03-30 Thread Williams, Mitch A
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 a

RE: [PATCH 2.6.21-rc5] MSI: read-flush MSI-X table (rev 2)

2007-03-29 Thread Williams, Mitch A
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

RE: [PATCH 2.6.21-rc5] MSI: read-flush MSI-X table (rev 2)

2007-03-29 Thread Williams, Mitch A
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

RE: [PATCH 2.6.21-rc5] MSI: read-flush MSI-X table

2007-03-28 Thread Williams, Mitch A
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

RE: [PATCH 2.6.21-rc5] MSI: read-flush MSI-X table

2007-03-27 Thread Williams, Mitch A
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

RE: [PATCH 2.6.21-rc5] MSI: read-flush MSI-X table

2007-03-27 Thread Williams, Mitch A
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

RE: [PATCH 2.6.21-rc5] MSI: read-flush MSI-X table

2007-03-27 Thread Williams, Mitch A
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

RE: [PATCH 2.6.20.3] Flush writes to MSI-X table

2007-03-23 Thread Williams, Mitch A
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 pa

RE: [PATCH 3/3] change sematics of read flag

2005-02-01 Thread Williams, Mitch 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 me

[PATCH] sysfs write fixes

2005-01-21 Thread Williams, Mitch 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 p