Date: Thu, 14 Jun 2007 20:02:04 +0900 From: "Takanori Saneto" <sanewo@gmail.com> To: "John Baldwin" <jhb@freebsd.org> Cc: freebsd-current@freebsd.org, Goran Gajic <ggajic@afrodita.rcub.bg.ac.yu> Subject: Re: smb related problem Message-ID: <639c2fce0706140402s305906caxfc39faa0a3212012@mail.gmail.com> In-Reply-To: <200704261730.42097.jhb@freebsd.org> References: <Pine.LNX.4.64.0704191600060.11366@afrodita.rcub.bg.ac.yu> <200704261730.42097.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi,
I encountered this smb_co_lock problem, too.
In my case, server was WindowsXP Pro and the share I was trying to mount was
500GB of capacity.
When I try to use smbclient to mount the same share, I got
NT_STATUS_INSUFF_SERVER_RESOURCES error.
After resolving server problem (increasing IRPStackSize to 0x11),
smb_co_lock problem went away as well.
So, I guess this problem seems to be related to the handling of above server
error status.
I hope this might help improving smbfs.
Regards,
2007/4/27, John Baldwin <jhb@freebsd.org>:
>
> On Thursday 19 April 2007 10:02:13 am Goran Gajic wrote:
> >
> > Hi,
> >
> > I have just noticed from today build:
> >
> > FreeBSD fbsd.interex-pla.net 7.0-CURRENT FreeBSD 7.0-CURRENT #0: Thu Apr
> > 19 11:42:17 CEST 2007
> > root@fbsd.interex-pla.net:/usr/src/sys/i386/compile/GENERIC i386
> >
> > netsmb_dev: loaded
> > smb_co_lock: recursive lock for object 1
> > lockmgr: thread 0xc3a39a20 unlocking unheld lock
> > KDB: stack backtrace:
> > db_trace_self_wrapper(c094fe7e) at db_trace_self_wrapper+0x25
> > kdb_backtrace(c094b1d7,c3a39a20) at kdb_backtrace+0x29
> > _lockmgr(c367ce08,2006,c367ce38,c3a39a20,c3a6e210,...) at _lockmgr+0x5fa
> > smb_co_put(c367ce00,d728ab90,c3678d00,c367ce00,0,...) at smb_co_put+0x50
> > smb_sm_lookup(d728ab1c,d728aafc,d728ab90,d728aaf8,d728aafc,...) at
> > smb_sm_lookup+0x11a
> > smb_usr_lookup(c2f09400,d728ab90,d728ab8c,d728ab88,c0a9e708,...) at
> > smb_usr_lookup+0x76
> >
>
> nsmb_dev_ioctl(c3678700,82fc6e6a,c2f09400,3,c3a39a20,c0a51488,0,c0948e06,131)
> > at nsmb_dev_ioctl+0x1e5
> > giant_ioctl(c3678700,82fc6e6a,c2f09400,3,c3a39a20,...) at
> giant_ioctl+0x33
> > devfs_ioctl_f(c37e8090,82fc6e6a,c2f09400,c3673e80,c3a39a20) at
> > devfs_ioctl_f+0xaf
> > kern_ioctl(c3a39a20,3,82fc6e6a,c2f09400) at kern_ioctl+0x1ae
> > ioctl(c3a39a20,d728ad00) at ioctl+0xf1
> > syscall(d728ad38) at syscall+0x252
> > Xint0x80_syscall() at Xint0x80_syscall+0x20
> > --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x2815772f, esp =
> > 0xbfbfe40c, ebp = 0xbfbfe738 ---
> >
> > I've noticed this when I have tried mount_smbfs..
>
> Can you try this and reply with the stack trace from the panic?
>
> 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 7 Nov 2006 18:42:41 -0000
> @@ -351,6 +351,7 @@
> if (smb_co_lockstatus(cp, td) == LK_EXCLUSIVE &&
> (flags & LK_CANRECURSE) == 0) {
> SMBERROR("recursive lock for object %d\n", cp->co_level);
> + panic("rescursive lock for object %p", cp);
> return 0;
> }
> return lockmgr(&cp->co_lock, flags, &cp->co_interlock, td);
>
> --
> John Baldwin
> _______________________________________________
> freebsd-current@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?639c2fce0706140402s305906caxfc39faa0a3212012>