From nobody@FreeBSD.org  Tue Jul 20 07:37:27 2010
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id DD6AC1065673
	for <freebsd-gnats-submit@FreeBSD.org>; Tue, 20 Jul 2010 07:37:27 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (www.freebsd.org [IPv6:2001:4f8:fff6::21])
	by mx1.freebsd.org (Postfix) with ESMTP id CCDBD8FC14
	for <freebsd-gnats-submit@FreeBSD.org>; Tue, 20 Jul 2010 07:37:27 +0000 (UTC)
Received: from www.freebsd.org (localhost [127.0.0.1])
	by www.freebsd.org (8.14.3/8.14.3) with ESMTP id o6K7bRka067373
	for <freebsd-gnats-submit@FreeBSD.org>; Tue, 20 Jul 2010 07:37:27 GMT
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.14.3/8.14.3/Submit) id o6K7bRb1067372;
	Tue, 20 Jul 2010 07:37:27 GMT
	(envelope-from nobody)
Message-Id: <201007200737.o6K7bRb1067372@www.freebsd.org>
Date: Tue, 20 Jul 2010 07:37:27 GMT
From: Yuriy Kohut <ykohut@onapp.com>
To: freebsd-gnats-submit@FreeBSD.org
Subject: panic: mtx_lock() of spin mutex (null) @ /usr/src/sys/net/netisr.c:830
X-Send-Pr-Version: www-3.1
X-GNATS-Notify:

>Number:         148780
>Category:       kern
>Synopsis:       [panic] mtx_lock() of spin mutex (null) @ /usr/src/sys/net/netisr.c:830
>Confidential:   no
>Severity:       serious
>Priority:       low
>Responsible:    freebsd-xen
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Jul 20 07:40:00 UTC 2010
>Closed-Date:    Mon Nov 29 10:47:09 UTC 2010
>Last-Modified:  Mon Nov 29 10:47:09 UTC 2010
>Originator:     Yuriy Kohut
>Release:        FreeBSD 8.0-RELEASE-p4 (XEN)
>Organization:
UK2, OnApp
>Environment:
FreeBSD freebsd.tst 8.0-RELEASE-p4 FreeBSD 8.0-RELEASE-p4 #0: Tue Jul 20 08:46:15 EEST 2010     root@freebsd.vm:/mnt/usr/src/sys/XEN  i386
>Description:
FreeBSD 8.0 i386 is running as Xen 3.0 guest (DomU). Kernel panics while building on ports. The command was:

cd /usr/ports/devel/m4 && make config;

The panic details:
panic: mtx_lock() of spin mutex (null) @ /usr/src/sys/net/netisr.c:830
cpuid = 0
KDB: enter: panic
[thread pid 36643 tid 100050 ]
Stopped at      kdb_enter+0x3a: movl    $0,kdb_why
db> where
Tracing pid 36643 tid 100050 td 0xc41246c0
kdb_enter(c035909f,c035909f,c0357ac9,c3db39d8,0,...) at kdb_enter+0x3a
panic(c0357ac9,0,c03678d3,33e,c00d6a98,...) at panic+0x136
_mtx_lock_flags(c07b2808,0,c03678d3,33e,c43db600,...) at _mtx_lock_flags+0x98
netisr_clearqdrops(c3db3a28,c3db3a3c,c00df55a,0) at netisr_clearqdrops+0x66e
netisr_queue_src(1,0,c43db600,c3db3a6c,c01817ce,...) at netisr_queue_src+0xa7
netisr_queue(1,c43db600,df,0,c3db3a80,...) at netisr_queue+0x20
if_simloop(c3ece400,c43db600,2,0,c019df3f,...) at if_simloop+0xfe
looutput(c3ece400,c43db600,c3db3b00,c3db3af8,c031b624,...) at looutput+0x141
ip_output(c43db600,0,0,0,0,...) at ip_output+0x9cc
tcp_output(c429f9e0,c40f12b0,1b9,c429d7a8,c42b4338,...) at tcp_output+0x1540
tcp_ctloutput(c42b4338,c40f12b0,c41246c0,25,c3db3c70,...) at tcp_ctloutput+0x933
soconnect(c42b4338,c40f12b0,c41246c0,bf7fae30,c40f12b0,...) at soconnect+0x52
kern_connect(c41246c0,6,c40f12b0,c40f12b0,ffffffff,...) at kern_connect+0xa6
connect(c41246c0,c3db3d08,c,c3db0000,c0397338,...) at connect+0x46
syscall(c3db3d48) at syscall+0x2a3
Xint0x80_syscall() at Xint0x80_syscall+0x22
--- syscall (98, FreeBSD ELF32, connect), eip = 0x283b9e5b, esp = 0xbf7faccc, ebp = 0xbf7faef8 ---
>How-To-Repeat:

>Fix:


>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-i386->freebsd-net 
Responsible-Changed-By: brucec 
Responsible-Changed-When: Sat Nov 13 16:08:11 UTC 2010 
Responsible-Changed-Why:  
Over to maintainer(s). 

http://www.freebsd.org/cgi/query-pr.cgi?pr=148780 
Responsible-Changed-From-To: freebsd-net->freebsd-xen 
Responsible-Changed-By: cperciva 
Responsible-Changed-When: Sun Nov 28 14:59:04 UTC 2010 
Responsible-Changed-Why:  
This is actually a FreeBSD/Xen bug.  Somehow the pcpu data is being 
mangled in the presence of VM pressure; the panic shows up in netisr 
because netisr looks up a per-cpu data structure (and locks it, hence 
the locking assertion). 



http://www.freebsd.org/cgi/query-pr.cgi?pr=148780 
State-Changed-From-To: open->closed 
State-Changed-By: cperciva 
State-Changed-When: Mon Nov 29 10:46:26 UTC 2010 
State-Changed-Why:  
Fixed in HEAD (svn r216041), will MFC in the next couple of weeks. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=148780 
>Unformatted:
