msk watchdog timeout

Pyun YongHyeon pyunyh at
Mon May 21 01:09:53 UTC 2007

On Mon, May 21, 2007 at 01:41:24AM +0800, Li-Lun Wang (Leland Wang) wrote:
 > Hash: SHA1
 > Hi,
 > I am resending this the third time since my previous messages didn't seem
 > to go through.
 > I was persuaded to report this on freebsd-current.
 > I just installed 7.0-current as of May 3 on my new computer that comes
 > with an on-board Marvell Yukon Gigabit Ethernet.  Every now and then
 > if the network throughput comes near several hundred kbytes, I get the
 > msk0 watchdog timeout messages:
 > 	kernel: msk0: watchdog timeout
 > 	msk0: watchdog timeout (missed Tx interrupts) -- recovering
 > Although it says recovering, the interface never comes back alive.

The above message indicates the driver sent all pending transmission
requests but the driver didn't receive corresponding Tx completion
interrupts. Not recovering from the watchdog timeout means there are
another issues on the driver. However as disabling MSI fixed the
issue, I guess it's not fault of msk(4) and it comes from bad/broken
MSI implementation of your system. I guess it's time to add your
chipset to a PCI quirk table in order to blacklist it.

 > Sometimes doing a kldunload / kldload if_msk can bring the interface
 > back, but sometimes it is helpless with the following message when I
 > reload the kernel module:
 > kernel: mskc0: <Marvell Yukon 88E8053 Gigabit Ethernet> port 0xb000-0xb0ff
 > 	mem 0xf9000000-0xf9003fff irq 16 at device 0.0 on pci4
 > kernel: msk0: <Marvell Technology Group Ltd. Yukon EC Id 0xb6 Rev 0x02> on
 > 	mskc0
 > kernel: msk0: failed to allocate DMA'able memory for jumbo buf
 > kernel: device_attach: msk0 attach returned 1
 > I would have to reboot to solve this situation.

Supporting jumbo frame requires a big contiguous kernel memory which
may not be available at the time of driver loading. If you unload
the driver the contiguous kernel memory would be used by other parts
of kernel. Unfortunately, there is no easy way to recover from this
and the only known way to fix is reboot.

 > Google found me not much information, but someone did mention something
 > about MSI.  I set hw.pci.enable_msix=0 and hw.pci.enable_msi=0 in my
 > loader.conf, and I was able to reach megas of bytes throughput without
 > a problem.
 > - -- llwang
Pyun YongHyeon

More information about the freebsd-current mailing list