Problematic network performance with Marvell 8072 on HP Probook
pyunyh at gmail.com
Sun Jan 24 20:55:08 UTC 2010
On Sun, Jan 24, 2010 at 07:39:11PM +0100, Emanuele A. Bagnaschi wrote:
> I've been experiencing a troubling issue with a Marvell 8072 NIC on an HP
> ProBook 4710s.
> I first noticed that there is a problem while transferring some files
> through scp to a FreeBSD8-STABLE server: CPUs usage sky-rocketed to 100% (system)
> and network performance was awful (about 1.8 MiB/s).
> I tried and succeeded in reproducing the issue with 'ttcp'. I decided
> to use this little benchmark because is so simple (it is linked only against libc) that I can
> be sure that the problem doesn't depend on scp/ssh or other parts of the system.
Last time I checked ttcp, it was broken with threading. So you have
to build ttcp without threading support or use netperf to check
> This is the output of 'uname -a':
> FreeBSD polaris 8.0-STABLE FreeBSD 8.0-STABLE #24: Sun Jan 17 21:08:02
> CET 2010 toor at polaris:/usr/obj/usr/src/sys/POLARIS amd64
> Here it's some relevant information to identify the NIC:
> first from 'dmesg'
> mskc0: <Marvell Yukon 88E8072 Gigabit Ethernet> port 0x2000-0x20ff mem
> 0x90100000-0x90103fff irq 17 at device 0.0 on pci134
> msk0: <Marvell Technology Group Ltd. Yukon EX Id 0xb5 Rev 0x02> on mskc0
> msk0: Ethernet address: 00:25:b3:52:fc:fa
> miibus0: <MII bus> on msk0
> mskc0: [FILTER]
> msk0: link state changed to DOWN
> msk0: link state changed to UP
> and then from 'pciconf -lv'
> mskc0 at pci0:134:0:0: class=0x020000 card=0x3074103c chip=0x436c11ab
> rev=0x10 hdr=0x00
> vendor = 'Marvell Semiconductor (Was: Galileo Technology Ltd)'
> device = 'Marvell 8072 Ethernet Nic (88E8072)'
> class = network
> subclass = ethernet
> Here it's the output of 'ifconfig':
> msk0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu
> ether 00:25:b3:52:fc:fa
> inet 192.168.1.4 netmask 0xffffff00 broadcast 192.168.1.255
> media: Ethernet autoselect (100baseTX <full-duplex,flag0,flag1>)
> satus: active
> Attached you will find the results of my tests, I hope that the file
> will be self-explanatory.
It seems you have Yukon Extreme controller and its revision is B0
which is known to have various silicon bug. How about disabling TX
related offloading?(e.g. ifconfig msk0 -txcsum -tso) Does that make
> I'm wondering, are there any other tunable parameters (apart from MSI on/off) I
> should try to modify? Should I file a PR? Are there any other interesting data
> I should gather? With the proper guide I'm also available to contribute some
> code myself.
Given that high rates of silicon bug of Yukon having a detailed
errata information would be great help to analyze the issue. But we
still have no access to the information as well as datasheet.
More information about the freebsd-stable