Re: LAGG and CARP troubles

2012-03-18 Thread Alexander Lunev
On Fri, Mar 16, 2012 at 7:42 PM, Freddie Cash  wrote:
> If you're adventurous, could you upgrade a test box to 10-CURRENT and
> try the new CARP code?

I will try it on vmware stations.

--
your sweet isn't ready yet
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"


Re: Intel 82550 Pro/100 Ethernet and Microcode

2012-03-18 Thread Andreas Longwitz
YongHyeon PYUN wrote:
> 
> The microcode is normally used to reduce high number of interrupts
> under heavy network load by bundling multiple RX frames.

ok, I understand. But I have DEVICE_POLLING and HZ=1000 in the kernel
source, so interrupts do not occur.

> However
> your reason to use microcode for i82550C looks weird since the
> microcode used for i82550C does not have a fix for TCO bug.
> The microcode for i82550(fxp2 in your system) indeed has fix for
> TCO bug and includes additional feature for bundling.

According to the comments in rcvbundl.h it is just directly opposed.

> If you're
> suffering from TCO bug of i82550, NFS over UDP issue should happen
> only on i82550(fxp2). Can you check whether the NFS issue happens
> on i82550C (fxp0 and fxp1) without loading the microcode?

The NFS issue happens on fxp0 (i82550C) without loading of microcode:
Mar 16 16:12:52  dssresv1 kernel: nfs server
dsscam:/prod/mobotix: not responding
Mar 16 16:13:24  dssresv1 kernel: nfs server
dsscam:/prod/mobotix: not responding
Mar 16 16:13:56  dssresv1 kernel: nfs server
dsscam:/prod/mobotix: not responding
Mar 16 16:14:28  dssresv1 kernel: nfs server
dsscam:/prod/mobotix: not responding
Mar 16 16:14:59  dssresv1 kernel: nfs server
dsscam:/prod/mobotix: is alive again

The last message appears immediately after loading the microcode with
ifconfig fxp0 link0.

> I still can't explain why your i82550C with the loaded microcode
> does not generates SCB timeouts because mine always shows the error
> right after loading the microcode.

In FreeBSD 6 and 8 I need my bzero-patch to get fxp working, In FreeBSD
4 - on the same hardware - this was not necessary.

> Are you actively using fxp0 or fxp1 after loading the microcode?

Yes I have 6 server with fxp0/fxp1 i82550C and 2 server with fxp0/fxp1
i82550 on motherboard in production, additionally some fxp2 i82550
external cards. All run with microcode loaded and polling.

> If yes, could you check whether
> the CPU Saver feature of the microcode really works on i82550C?
> You may be able to use netperf UDP stream test to verify that.

I did some tests with netperf 2.5.0, At first I had to patch some format
strings in netperf from %d to %lld for uint64_t variables to get
readable output from netperf on my i386 systems.

The test command
  netperf -H host_with_fxp -t UDP_STREAM
gives nearly always the same output

Socket  Message  Elapsed  Messages
SizeSize Time Okay Errors   Throughput
bytes   bytessecs#  #   10^6bits/sec

  92169216   10.00   13069 1515880 96.34
 41600   10.00   13069 96.34

And this output did not considerably change for the test cases fxp-type
i82550C or i82550, microcode loaded or not and polling yes or no.

But I can answer your question concerning the CPU Saver funktion on
i82550C and its a little suprise (for me). In all my tests without
polling I checked the irq's on host_with_fxp using "vmstat -i". The
result is that the CPU Saver feature of the microcode does not work on
i82250C and it works on i82250. On i82250C the value of
dev.fxp.0.bundle_max is irrelevant, the i82250C always needs ca. 91000
irq's for the netperf test. The same number of irq's needs the i82250
with bundle_max=1, but when I set bundle_max=6 (the default), then the
number of irq's for the same test goes down to 91000/7 = 13000.


Regards

Andreas Longwitz

___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"


Re: msk/Yukon issues since 9.0-REL

2012-03-18 Thread YongHyeon PYUN
On Sat, Mar 17, 2012 at 03:18:19PM +, Joe Holden wrote:
> Hi guys,
> 
> I've upgraded to 9.0-REL from RC3 (I think) and the previous workarounds 
> I've used for msk/Yukon II problems don't seem to work anymore:
> 
> rc.conf:
> ifconfig_msk0="inet 192.168.201.2/30 -lro -tso -vlanhwfilter -vlanhwtag"
> 

msk(4) does not support VLAN hardware filter and LRO.  However I
don't understand how this affects stability of driver.

> pciconf:
> mskc0@pci0:7:0:0:   class=0x02 card=0x81e6104d chip=0x435111ab 
> rev=0x15 hdr=0x00
> vendor = 'Marvell Technology Group Ltd.'
> device = '88E8036 PCI-E Fast Ethernet Controller'
> class  = network
> subclass   = ethernet
> 
> I seem to get the usual error:
> msk0: watchdog timeout
> msk0: prefetch unit stuck?
> msk0: initialization failed: no memory for Rx buffers
> 

There was a related change after 9.0-RELEASE. The change already
merged to stable/9(r229874)  So would you try latest stable/9 or
apply the change to 9.0-RELEASE?
http://svnweb.freebsd.org/base/stable/9/sys/dev/msk/if_msk.c?r1=229524&r2=229874&view=patch

> MSI(-X) is disabled but it doesn't seem to make any difference
> 
> Is there anything I can try to either debug or "fix" it?
> 

If you've upgraded from somewhat old FreeBSD releases, make sure to
cold boot your box(i.e. completely remove power cord for several
minutes before booting).

> Thanks,
> J
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"