msk msk0 watchdog timeout freeze hang lock stop problem

[Gareth Wyn Roberts]

I've run in to problems using the msk device where initially it works well enough to set DHCP etc. but stops/freezes as soon as any appreciable network traffic occurs . There are several threads describing similar symptoms over the past two years or more.  I've been following several false leads but have finally found a solution (at least it solves my problem).

I'm running a standard FreeBSD 10.1-RELEASE and the NIC is detected as:

mskc0: <Marvell Yukon 88E8057 Gigabit Ethernet> mem 0xfa000000-0xfa003fff irq 19 at device 0.0 on pci6
msk0: <Marvell Technology Group Ltd. Yukon Ultra 2 Id 0xba Rev 0x00> on mskc0
msk0: Ethernet address: 00:13:77:e9:df:eb
miibus0: <MII bus> on msk0
e1000phy0: <Marvell 88E1149 Gigabit PHY> PHY 0 on miibus0
e1000phy0:  none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-ma
ster, auto, auto-flow

The network worked when using the i386 release, but failed for the amd64 release (as reported previously) which prompted me to disable 64-bit DMA (the patch for this is attached below).  This worked for the first kernel built but mysteriously failed when another unrelated part of the kernel was changed (a usb driver) and the kernel recompiled.  So identical msk driver code worked in one kernel but not the second! This suggested that alignment differences between the two kernels were causing the msk driver to fail. Others have reported varying behaviour depending on different circumstances.

It transpires that changing just one value in the if_mskreg.h file solved all my problems.  Subsequently I have not been able to make it fail under heavy network traffic in either 32-bit or 64-bit mode.
I'm working on 10.1-RELEASE source, i.e. if_msk.c revision 262524 and if_mskreg.h revision 264442.

Here's the patch to if_mskreg.h
--- if_mskreg.h-orig    2014-11-11 20:02:58.000000000 +0000
+++ if_mskreg.h 2015-04-12 18:47:20.000000000 +0100
@@ -2179,9 +2179,11 @@
  * At first I guessed 8 bytes, the size of a single descriptor, would be
  * required alignment constraints. But, it seems that Yukon II have 4096
  * bytes boundary alignment constraints.
+ * And it seems that the DMA status region for the Yukon Ultra 2 (88E8057)
+ * requires 8192 byte alignment to prevent locking.
  */
 #define MSK_RING_ALIGN 4096
-#define        MSK_STAT_ALIGN  4096
+#define        MSK_STAT_ALIGN  8192


The patches to both files which also implement a MSK_64BIT_DMA_DISABLE flag are attached.  Perhaps the developers would consider committing these as it may be useful for future debugging.

Gareth.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: if_mskreg.h.rev264442.diff
Type: text/x-patch
Size: 603 bytes
Desc: if_mskreg.h.rev264442.diff
URL: <http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20150412/b581a021/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: if_msk.c.rev262524.dma.diff
Type: text/x-patch
Size: 3748 bytes
Desc: if_msk.c.rev262524.dma.diff
URL: <http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20150412/b581a021/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: if_mskreg.h.rev264442.dma.diff
Type: text/x-patch
Size: 1533 bytes
Desc: if_mskreg.h.rev264442.dma.diff
URL: <http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20150412/b581a021/attachment-0002.bin>