amd64/122780: tcpdump on lagg interface during high pps wedges netcode

Paul paul at gtcomm.net
Tue Apr 15 00:40:01 UTC 2008


>Number:         122780
>Category:       amd64
>Synopsis:       tcpdump on lagg interface during high pps wedges netcode
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-amd64
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Apr 15 00:40:01 UTC 2008
>Closed-Date:
>Last-Modified:
>Originator:     Paul
>Release:        7.0 Release
>Organization:
GTCOMM
>Environment:
FreeBSD x 7.0-RELEASE FreeBSD 7.0-RELEASE #2: Fri Apr  4 13:11:07 EDT 2008     root at x:/usr/obj/usr/src/sys/ROUTER  amd64

>Description:
Sending a rate of 200kpps through or to lagg interface and then using the tcpdump command causes the entire network stack to have issues on all interfaces including ones that use other drivers eventually causing machine to be unaccessable on the network.  (ex.  tcpdump -n -i lagg0 )

Lagg interface is on EM driver using two EM ports, example:
ifconfig lagg0 laggproto lacp laggport em4 laggport em5  

Port on the other end is either Cisco switch or another FREEBSD machine with lagg interface.  Both have same problems.

kern.hz=4000
kern.polling.enable=1
kern.polling.reg_frac=400
kern.polling.user_frac=20
kern.polling.idle_poll=1
kern.polling.each_burst=1000
kern.polling.burst_max=8000

EM is PCI-E 4x 4 port  Intel Server card, copper ports

I would be happy to provide any more information.  dmesg reports nothing when it happens and I did not get a chance to do much more debugging on the issue.

I do have a second issue with this setup which may or may not be related.  With polling enabled, the machine panics on a spin lock when rebooting, during the shutdown process.  


>How-To-Repeat:

>Fix:


>Release-Note:
>Audit-Trail:
>Unformatted:


More information about the freebsd-amd64 mailing list