[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freebsd-net
Subject:    Re: igb(4) panic: already enqueue
From:       Konstantin Belousov <kostikbel () gmail ! com>
Date:       2013-09-28 22:45:01
Message-ID: 20130928224501.GX41229 () kib ! kiev ! ua
[Download RAW message or body]


On Sun, Sep 29, 2013 at 12:30:38AM +0300, Konstantin Belousov wrote:
> On a relatively old test machine, dual-socket X7DWU supermicro, Xeon
> X5272, with on-board 82575EB igb controllers, running the stress2
> udp blast test immediately causes the following
> 
> panic: buf=0xfffff8001aa5c800 already enqueue at 1445 prod=1315 cons=1445
> cpuid = 3
> KDB: stack backtrace:
> db_trace_self_wrapper() at 0xffffffff802839ab = db_trace_self_wrapper+0x2b/frame 0xfffffe0123570600
> vpanic() at 0xffffffff8033bd96 = vpanic+0x126/frame 0xfffffe0123570640
> panic() at 0xffffffff8033be23 = panic+0x43/frame 0xfffffe01235706a0
> igb_mq_start() at 0xffffffff80bcb228 = igb_mq_start+0xb8/frame 0xfffffe0123570710   
> ether_output() at 0xffffffff804072a8 = ether_output+0x5c8/frame 0xfffffe0123570780  
> ip_output() at 0xffffffff80430be1 = ip_output+0xe91/frame 0xfffffe0123570860
> udp_send() at 0xffffffff804a5fc4 = udp_send+0x834/frame 0xfffffe0123570910
> sosend_dgram() at 0xffffffff803b517b = sosend_dgram+0x36b/frame 0xfffffe0123570990  
> soo_write() at 0xffffffff8039dbb9 = soo_write+0x49/frame 0xfffffe01235709d0
> dofilewrite() at 0xffffffff803956c5 = dofilewrite+0x85/frame 0xfffffe0123570a20
> kern_writev() at 0xffffffff803953d5 = kern_writev+0x65/frame 0xfffffe0123570a70
> sys_write() at 0xffffffff80395363 = sys_write+0x63/frame 0xfffffe0123570ac0
> amd64_syscall() at 0xffffffff8053ae7d = amd64_syscall+0x28d/frame 0xfffffe0123570bf0
> 
> Test is available at
> svn:base/user/pho/stress2/testcases/udp, invocation line is
> BLASTHOST=192.168.5.1 ./udp -t 10m -i 50 -h -v
> Substitute the BLASTHOST with the ip address of a scratch box.
> 
> This is on the yesterday HEAD.  Could you, please, fix this ?

I also tested on i350 adapters, there the issue is harder to reproduce,
but it still panics under the test.  Also, I saw the following:
Expensive timeout(9) function: 0xffffffff809c7d60(0xfffffe0001864000) 1.9297931s
Expensive timeout(9) function: 0xffffffff809c7d60(0xfffffe0001864000) 9.9669852s
db> x/i 0xffffffff809c7d60
0xffffffff809c7d60 = igb_local_timer:   pushq   %rbp


[Attachment #3 (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]