Jeff Garzik wrote:
Kok, Auke wrote:
A certain AMD64 bridge (8132) has an option to turn on write combining
which breaks our adapter. To circumvent this we need to flush every
write.
Signed-off-by: Jesse Brandeburg <[EMAIL PROTECTED]>
Signed-off-by: Auke Kok <[EMAIL PROTECTED]>
---
drivers/net/e1000/e1000_hw.c | 24 ++++++++++++++++++++++--
drivers/net/e1000/e1000_main.c | 18 +++++++++++-------
2 files changed, 33 insertions(+), 9 deletions(-)
diff --git a/drivers/net/e1000/e1000_hw.c b/drivers/net/e1000/e1000_hw.c
index 3959039..749d621 100644
--- a/drivers/net/e1000/e1000_hw.c
+++ b/drivers/net/e1000/e1000_hw.c
@@ -705,8 +705,12 @@ e1000_init_hw(struct e1000_hw *hw)
/* Zero out the Multicast HASH table */
DEBUGOUT("Zeroing the MTA\n");
mta_size = E1000_MC_TBL_SIZE;
- for(i = 0; i < mta_size; i++)
+ for(i = 0; i < mta_size; i++) {
E1000_WRITE_REG_ARRAY(hw, MTA, i, 0);
+ /* use write flush to prevent Memory Write Block (MWB) from
+ * occuring when accessing our register space */
+ E1000_WRITE_FLUSH(hw);
+ }
NAK. We can't crap up every driver just for one weird piece of hardware.
If this problem falls outside the grounds of mmiowb() [see
Documentation/memory-barriers.txt], then other solutions need to be
looked into... ioremap_nocache() ? Tweaking the MTRR for this region?
Chipset quirk? ...
If there is an in-kernel fix for this that would make these flushes obsolete I
would certainly prefer it too, unfortunately we can't fix already released
kernels and our driver still needs to work there too, so that's why I queued
it. It can be dropped from this series if that's preferred.
Cheers,
Auke
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
