We haven't captured a PCI trace yet, but I think we have a good
lead. The MCA occurs in tg3_chip_reset(), which does:
tw32(GRC_MISC_CFG, GRC_MISC_CFG_CORECLK_RESET);
The comment immediately after the reset:
/* Flush PCI posted writes. The normal MMIO registers
* are inaccessible at this time so this is the only
* way to make this reliably. I tried to use indirect
* register read/write but this upset some 5701 variants.
*/
pci_read_config_dword(tp->pdev, PCI_COMMAND, &val);
says that the MMIO registers are inaccessible at this time.
Presumably they became inaccessible when tg3_write_indirect_reg32()
did the write to GRC_MISC_CFG, so the read-after-write for the
TG3_FLAG_5701_REG_WRITE_BUG is then reading an inaccessible register.
One unusual thing about our ia64 chipset (and our parisc chipset)
is that it's typically configured so PCI master aborts cause an MCA.
My understanding is that most other PCI controllers basically ignore
master aborts, so the aborted read would just return -1 instead of
causing an MCA.
The following change (though not correct because it ignores
TG3_FLAG_PCIX_TARGET_HWBUG) avoids the MCA:
--- 1.57/drivers/net/tg3.c Fri Feb 14 09:24:48 2003
+++ edited/drivers/net/tg3.c Fri Feb 14 09:26:49 2003
@@ -3059,7 +3059,7 @@
}
}
- tw32(GRC_MISC_CFG, GRC_MISC_CFG_CORECLK_RESET);
+ writel(GRC_MISC_CFG_CORECLK_RESET, tp->regs + GRC_MISC_CFG);
/* Flush PCI posted writes. The normal MMIO registers
* are inaccessible at this time so this is the only
So perhaps we need a special-case path for resetting, so we don't
try to access the registers while they're disabled.
Bjorn
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/