sfc: Always map MCDI shared memory as uncacheable
authorBen Hutchings <bhutchings@solarflare.com>
Wed, 11 May 2011 16:41:18 +0000 (17:41 +0100)
committerBen Hutchings <bhutchings@solarflare.com>
Thu, 12 May 2011 14:16:32 +0000 (15:16 +0100)
commit747df2258b1b9a2e25929ef496262c339c380009
tree7f0ff222afed691599f24473e0b8d10b36f48cf2
parentff538818f4a82c4cf02d2d6bd6ac5c7360b9d41d
sfc: Always map MCDI shared memory as uncacheable

We enabled write-combining for memory-mapped registers in commit
65f0b417dee94f779ce9b77102b7d73c93723b39, but inhibited it for the
MCDI shared memory where this is not supported.  However,
write-combining mappings also allow read-reordering, which may also
be a problem.

I found that when an SFC9000-family controller is connected to an
Intel 3000 chipset, and write-combining is enabled, the controller
stops responding to PCIe read requests during driver initialisation
while the driver is polling for completion of an MCDI command.  This
results in an NMI and system hang.  Adding read memory barriers
between all reads to the shared memory area appears to reduce but not
eliminate the probability of this.

We have not yet established whether this is a bug in our BIU or in the
PCIe bridge.  For now, work around by mapping the shared memory area
separately.

Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
drivers/net/sfc/mcdi.c
drivers/net/sfc/nic.h
drivers/net/sfc/siena.c