I tired the patch and got another panic, with slightly different backtrace as follows: smb_co_lock: recursive lock for object 0 panic: recursive lock for object 0xc1b87d80 KDB: enter: panic [thread pid 644 tid 100050 ] Stopped at kdb_enter+0x33: leave db> bt Tracing pid 644 tid 100050 td 0xc1a41c00 kdb_enter(c062139e, c0675e80,c1b85615,cc3ada44,cc3ada44,...) at kdb_enter+0x33 panic(x1b85615,c1b87d80,0,cc3adb98,cc3ada64,...) at panic+0x7e smb_share_lock(c1b87d80,2,c1a41c00,c1b69600,c1a68a00,...) at smb_share_lock smb_co_gone(c1a68a00,cc3ad98,c1a14c00,c,c1a41c00,...) at smb_co_gone+0x3a smb_co_gone(c1b69600,cc3ad98,cc3adb98,cc3adabc,c1b69600,...) at smb_co_gone+0x5e smb_sm_lookup(cc3adae8,cc3adb24,cc3adb98,cc3adb40,c199041c,...) at smb_sm_lookup+0x186 smb_usr_lookup(c1990400,cc3adb98,cc3adba4,cc3adba0,cc3adba0,...) at smb_usr_lookup+0x95 nsmb_dev_ioctl(c1b69900,82fc6e6a,c1990400,3,c1a41c00,...) at nsmb_dev_ioctl+0x1d6 giant_ioctl(c1b69900,82fc6e6a,c1990400,3,c1a41c00,...) at giant_ioctl+0x51 devfs_ioctl_f(c1a69b40,82fc6e6a,c1990400,c18eb800,c1a41c00,...) at devfs_ioctl_f+0x5d kern_ioctl(c1a44e00,4,82fc6e6a,c1990400,535e95,...) at kern_ioctl+0x9d ioctl(c1a41c00,cc3adcf8,c,cc3add38,c,...) at ioctl+0xbd syscall(cc398d38) at syscall+0x1fd Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x2814f047, esp = 0xbfbfe55c, ebp = 0xbfbfe888 --- db> 2007/6/19, John Baldwin <jhb_at_freebsd.org>: > > On Sunday 17 June 2007 06:27:46 am Takanori Saneto wrote: > > OK, here it is: > > > > smb_co_lock: recursive lock for object 1 > > panic: recursive lock for object 0xc1b3e600 > > KDB: enter: panic > > [thread pid 592 tid 100032 ] > > Stopped at kdb_enter+0x32: leave > > db> bt > > Tracing pid 592 tid 100032 td 0xc1a44e00 > > kdb_enter(c060f652, c066e920,c1b89b5a,cc398a70,cc398a70,...) at > > kdb_enter+0x32 > > panic(x1b89b5a,c1b3e600,1,c1bc0638,cc398ab0,...) at panic+0xc4 > > smb_share_lock(c1b3e600,2,c1a44e00,c,c1a44e00,...) at smb_share_lock > > smb_co_gone(c1bc0600,cc398ba4,cc398ba4,cc398ac8,c1bc0600,...) at > > smb_co_gone+0x3a > > smb_sm_lookup(cc398af4,cc398b30,cc398ba4,cc398b4c,c199041c,...) at > > smb_sm_lookup+0x16b > > smb_usr_lookup(c1990400,cc398ba4,cc398bb0,cc398bac,c060ac51,...) at > > smb_usr_lookup+0x95 > > nsmb_dev_ioctl(c1b5b100,82fc6e6a,c1990400,3,c1a44e00,...) at > > nsmb_dev_ioctl+0x1d6 > > Hmm, ok. Try this maybe: > > Index: smb_conn.c > =================================================================== > RCS file: /usr/cvs/src/sys/netsmb/smb_conn.c,v > retrieving revision 1.18 > diff -u -r1.18 smb_conn.c > --- smb_conn.c 6 Nov 2006 13:42:06 -0000 1.18 > +++ smb_conn.c 18 Jun 2007 22:12:33 -0000 > _at__at_ -212,8 +212,11 _at__at_ > error = smb_smb_treeconnect(ssp, scred); > if (error == 0) > vcspec->ssp = ssp; > - else > + else { > + smb_vc_put(vcp, scred); > + vcp = NULL; > smb_share_put(ssp, scred); > + } > out: > smb_sm_unlockvclist(td); > if (error == 0) > _at__at_ -351,6 +354,7 _at__at_ > if (smb_co_lockstatus(cp, td) == LK_EXCLUSIVE && > (flags & LK_CANRECURSE) == 0) { > SMBERROR("recursive lock for object %d\n", cp->co_level); > + panic("recursive lock for object %p", cp); > return 0; > } > return lockmgr(&cp->co_lock, flags, &cp->co_interlock, td); > > > -- > John Baldwin >Received on Wed Jun 20 2007 - 12:24:02 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:12 UTC