From nobody@FreeBSD.org  Wed Nov 12 20:57:18 2008
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 D0848106567D
	for <freebsd-gnats-submit@FreeBSD.org>; Wed, 12 Nov 2008 20:57:18 +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 BD41B8FC1E
	for <freebsd-gnats-submit@FreeBSD.org>; Wed, 12 Nov 2008 20:57:18 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (localhost [127.0.0.1])
	by www.freebsd.org (8.14.3/8.14.3) with ESMTP id mACKvHHd021399
	for <freebsd-gnats-submit@FreeBSD.org>; Wed, 12 Nov 2008 20:57:17 GMT
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.14.3/8.14.3/Submit) id mACKvHtX021397;
	Wed, 12 Nov 2008 20:57:17 GMT
	(envelope-from nobody)
Message-Id: <200811122057.mACKvHtX021397@www.freebsd.org>
Date: Wed, 12 Nov 2008 20:57:17 GMT
From: Thad Schulz <tschulz@sebeka.k12.mn.us>
To: freebsd-gnats-submit@FreeBSD.org
Subject: smbd causes periodic panic on 7-RELEASE
X-Send-Pr-Version: www-3.1
X-GNATS-Notify:

>Number:         128829
>Category:       kern
>Synopsis:       smbd(8) causes periodic panic on 7-RELEASE
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    jh
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed Nov 12 21:00:12 UTC 2008
>Closed-Date:    Tue Nov 23 17:01:35 UTC 2010
>Last-Modified:  Tue Nov 23 17:01:35 UTC 2010
>Originator:     Thad Schulz
>Release:        7-RELEASE
>Organization:
Sebeka Public School
>Environment:
FreeBSD nat.menahga.k12.mn.us 7.0-RELEASE FreeBSD 7.0-RELEASE #0: Sun Feb 24 19:59:52 UTC 2008     root@logan.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  i386
>Description:
smbd seems to produce a kernel panic under high load mostly during logins.  The server seems to panic infrequently between twice a day to a once every two weeks.
This is the backtrace of the core dump

Unread portion of the kernel message buffer:                                                               
kernel trap 12 with interrupts disabled                                                                    
                                                                                                           
                                                                                                           
Fatal trap 12: page fault while in kernel mode                                                             
cpuid = 2; apic id = 06                                                                                    
fault virtual address   = 0x29                                                                             
fault code              = supervisor write, protection violation                                           
instruction pointer     = 0x20:0xc0744a51                                                                  
stack pointer           = 0x28:0xf1b10b30                                                                  
frame pointer           = 0x28:0xf1b10b88                                                                  
code segment            = base 0x0, limit 0xfffff, type 0x1b                                               
                        = DPL 0, pres 1, def32 1, gran 1                                                   
processor eflags        = resume, IOPL = 0                                                                 
current process         = 56651 (smbd)                                                                     
trap number             = 12                                                                               
panic: page fault                                                                                          
cpuid = 2                                                                                                  
Uptime: 5d21h19m55s                                                                                        
Physical memory: 3571 MB                                                                                   
Dumping 333 MB: 318 302 286 270 254 238 222 206 190 174 158 142 126 110 94 78 62 46 30 14                  
                                                                                                           
#0  doadump () at pcpu.h:195                                                                               
195     pcpu.h: No such file or directory.                                                                 
        in pcpu.h                                                                                          
(kgdb) bt                                                                                                  
#0  doadump () at pcpu.h:195                                                                               
#1  0xc0754457 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409                                
#2  0xc0754719 in panic (fmt=Variable "fmt" is not available.                                              
) at /usr/src/sys/kern/kern_shutdown.c:563                                                                 
#3  0xc0a4905c in trap_fatal (frame=0xf1b10af0, eva=41) at /usr/src/sys/i386/i386/trap.c:899               
#4  0xc0a499df in trap (frame=0xf1b10af0) at /usr/src/sys/i386/i386/trap.c:280                             
#5  0xc0a2fc0b in calltrap () at /usr/src/sys/i386/i386/exception.s:139
#6  0xc0744a51 in lf_advlock (ap=0xf1b10c20, head=0xccde44d8, size=3956736) at atomic.h:149
#7  0xc095d7ad in ufs_advlock (ap=0xf1b10c20) at /usr/src/sys/ufs/ufs/ufs_vnops.c:2181
#8  0xc0a5e1e7 in VOP_ADVLOCK_APV (vop=0xc0b93c60, a=0xf1b10c20) at vnode_if.c:1977
#9  0xc0729547 in kern_fcntl (td=0xc7b20210, fd=13, cmd=9, arg=-240055200) at vnode_if.h:1036
#10 0xc0729e07 in fcntl (td=0xc7b20210, uap=0xf1b10cfc) at /usr/src/sys/kern/kern_descrip.c:336
#11 0xc0a49635 in syscall (frame=0xf1b10d38) at /usr/src/sys/i386/i386/trap.c:1035
#12 0xc0a2fc70 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:196
#13 0x00000033 in ?? ()
Previous frame inner to this frame (corrupt stack?)

>How-To-Repeat:
smbd seems to produce a kernel panic under high load mostly during logins.  The server seems to panic infrequently between twice a day to a once every two weeks.
>Fix:


>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->freebsd-fs 
Responsible-Changed-By: linimon 
Responsible-Changed-When: Thu Nov 13 01:09:39 UTC 2008 
Responsible-Changed-Why:  
Over to maintainer(s). 

http://www.freebsd.org/cgi/query-pr.cgi?pr=128829 
State-Changed-From-To: open->feedback 
State-Changed-By: kib 
State-Changed-When: Thu Nov 13 13:09:51 UTC 2008 
State-Changed-Why:  
I think that the problem you experience might be fixed by r184227. 
What is exact version of the kernel sources and kern_lockf.c on the 
problematic machine ? 

http://www.freebsd.org/cgi/query-pr.cgi?pr=128829 

From: Thad Schulz <tschulz@sebeka.k12.mn.us>
To: bug-followup@FreeBSD.org, tschulz@sebeka.k12.mn.us, kib@FreeBSD.org
Cc:  
Subject: Re: kern/128829: smbd(8) causes periodic panic on 7-RELEASE
Date: Thu, 13 Nov 2008 08:20:01 -0600

 The server is running the GENERIC kernel from 7.0-RELEASE and the 
 version of kern_lockf.c looks like v 1.57 2007/08/07 09:04:50 if the 
 GENERIC kernel was built from the sources that came with 7.0-RELEASE.  
 So it looks like  the kern_lockf.c from r184227 would be newer.
 
 -- 
 Thad Schulz
 Technology Coordinator
 Sebeka Public School
 Phone: 218-837-5101
 Email: tschulz@sebeka.k12.mn.us 
 

From: Kostik Belousov <kostikbel@gmail.com>
To: Thad Schulz <tschulz@sebeka.k12.mn.us>
Cc: bug-followup@freebsd.org
Subject: Re: kern/128829: smbd(8) causes periodic panic on 7-RELEASE
Date: Thu, 13 Nov 2008 17:04:00 +0200

 On Thu, Nov 13, 2008 at 08:20:01AM -0600, Thad Schulz wrote:
 > The server is running the GENERIC kernel from 7.0-RELEASE and the 
 > version of kern_lockf.c looks like v 1.57 2007/08/07 09:04:50 if the 
 > GENERIC kernel was built from the sources that came with 7.0-RELEASE.  
 > So it looks like  the kern_lockf.c from r184227 would be newer.
 
 In fact, forthcoming 7.1 contains a new implementation of the advisory
 locking. The mentioned r184227 was applicable to new code, not older one
 in 7.0.
State-Changed-From-To: feedback->open 
State-Changed-By: jh 
State-Changed-When: Tue Nov 23 16:14:22 UTC 2010 
State-Changed-Why:  
Back to open. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=128829 
State-Changed-From-To: open->feedback 
State-Changed-By: jh 
State-Changed-When: Tue Nov 23 16:14:40 UTC 2010 
State-Changed-Why:  
Is this still a problem for you? 


Responsible-Changed-From-To: freebsd-fs->jh 
Responsible-Changed-By: jh 
Responsible-Changed-When: Tue Nov 23 16:14:40 UTC 2010 
Responsible-Changed-Why:  
Track. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=128829 
State-Changed-From-To: feedback->closed 
State-Changed-By: jh 
State-Changed-When: Tue Nov 23 17:01:34 UTC 2010 
State-Changed-Why:  
Resolved in stable/7 according to submitter. 

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