Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 5 Oct 2015 18:16:54 -0400 (EDT)
From:      Rick Macklem <rmacklem@uoguelph.ca>
To:        Christian Kratzer <ck@cksoft.de>
Cc:        freebsd-stable@freebsd.org, John Baldwin <jhb@freebsd.org>
Subject:   Re: smbfs crashes since approx. 10.1-RELEASE
Message-ID:  <1721669289.24365403.1444083414400.JavaMail.zimbra@uoguelph.ca>
In-Reply-To: <alpine.BSF.2.20.1510051157450.16263@noc1.cksoft.de>
References:  <alpine.BSF.2.20.1510051157450.16263@noc1.cksoft.de>

next in thread | previous in thread | raw e-mail | index | archive | help
Christian Kratzer wrote:
> Hi,
> 
> I run a regular rsync job that runs from cron and copies stuff that gets
> created on a Windows smbfs share.
> 
> Starting about 10.1-RELEASE the VM has become unstable and started panicing.
> 
> I have narrowed the issue down to the aforementioned rsync job.
> 
> When I move the job to a different VM the the other VM starts crashing and
> the VM without the job becomes stable agin.
> 
> I have panics and crashinfos stored in /var/crash if anybody is interested:
> 
>      root@noc2:/var/crash # uname -a
>      FreeBSD noc2.cksoft.de 10.2-RELEASE FreeBSD 10.2-RELEASE #0 r286666: Wed
>      Aug 12 15:26:37 UTC 2015
>      root@releng1.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC  amd64
>      root@noc2:/var/crash # freebsd-version -u
>      10.2-RELEASE-p5
>      root@noc2:/var/crash # freebsd-version -k
>      10.2-RELEASE
>      root@noc2:/var/crash #
> 
> This is what I have in /var/crash/core.txt.0
> 
>      Fatal trap 12: page fault while in kernel mode
>      cpuid = 0; apic id = 00
>      fault virtual address   = 0x20
>      fault code              = supervisor read data, page not present
>      instruction pointer     = 0x20:0xffffffff80996c7c
>      stack pointer           = 0x28:0xfffffe003d6c0ac0
>      frame pointer           = 0x28:0xfffffe003d6c0af0
>      code segment            = base 0x0, limit 0xfffff, type 0x1b
>  			    = DPL 0, pres 1, long 1, def32 0, gran 1
>      processor eflags        = resume, IOPL = 0
>      current process         = 1349 (smbiod10)
>      trap number             = 12
>      panic: page fault
>      cpuid = 0
>      KDB: stack backtrace:
>      #0 0xffffffff80984e30 at kdb_backtrace+0x60
>      #1 0xffffffff809489e6 at vpanic+0x126
>      #2 0xffffffff809488b3 at panic+0x43
>      #3 0xffffffff80d4aadb at trap_fatal+0x36b
>      #4 0xffffffff80d4addd at trap_pfault+0x2ed
>      #5 0xffffffff80d4a47a at trap+0x47a
>      #6 0xffffffff80d307f2 at calltrap+0x8
>      #7 0xffffffff8092ebe0 at __mtx_unlock_sleep+0x60
>      #8 0xffffffff8092eb69 at __mtx_unlock_flags+0x69
>      #9 0xffffffff81a1b724 at smb_iod_thread+0xb4
>      #10 0xffffffff8091244a at fork_exit+0x9a
>      #11 0xffffffff80d30d2e at fork_trampoline+0xe
>      Uptime: 2h43m55s
>      Dumping 103 out of 999 MB: (CTRL-C to abort)
>      ..16%..31%..47%..62%..78%..93%
> 
This crash is occurring when doing an mtx_unlock(&Giant). Unfortunately, I'm not
conversant w.r.t. this code. I've cc'd jhb@ in case he has some insight.
If you don't get any responses, I'd suggest reposting to freebsd-current@ with
"crashes in mtx_unlock(&Giant)" in the subject line.

Btw John, the code does tsleep() in a loop before the mtx_unlock(&Giant). I do
remember that was once allowed, but am not sure if it still is (ie a tsleep() call
while holding Giant)?

Hopefully someone who knows what is special about Giant that might cause this will
respond.

Good luck with it, rick

>      Reading symbols from /boot/kernel/smbfs.ko.symbols...done.
>      Loaded symbols for /boot/kernel/smbfs.ko.symbols
>      Reading symbols from /boot/kernel/libiconv.ko.symbols...done.
>      Loaded symbols for /boot/kernel/libiconv.ko.symbols
>      Reading symbols from /boot/kernel/libmchain.ko.symbols...done.
>      Loaded symbols for /boot/kernel/libmchain.ko.symbols
>      #0  doadump (textdump=<value optimized out>) at pcpu.h:219
>      219     pcpu.h: No such file or directory.
>  	    in pcpu.h
>      (kgdb) #0  doadump (textdump=<value optimized out>) at pcpu.h:219
>      #1  0xffffffff80948642 in kern_reboot (howto=260)
>  	at /usr/src/sys/kern/kern_shutdown.c:451
>      #2  0xffffffff80948a25 in vpanic (fmt=<value optimized out>,
>  	ap=<value optimized out>) at /usr/src/sys/kern/kern_shutdown.c:758
>      #3  0xffffffff809488b3 in panic (fmt=0x0)
>  	at /usr/src/sys/kern/kern_shutdown.c:687
>      #4  0xffffffff80d4aadb in trap_fatal (frame=<value optimized out>,
>  	eva=<value optimized out>) at /usr/src/sys/amd64/amd64/trap.c:851
>      #5  0xffffffff80d4addd in trap_pfault (frame=0xfffffe003d6c0a10,
>  	usermode=<value optimized out>) at /usr/src/sys/amd64/amd64/trap.c:674
>      #6  0xffffffff80d4a47a in trap (frame=0xfffffe003d6c0a10)
>  	at /usr/src/sys/amd64/amd64/trap.c:440
>      #7  0xffffffff80d307f2 in calltrap ()
>  	at /usr/src/sys/amd64/amd64/exception.S:236
>      #8  0xffffffff80996c7c in turnstile_broadcast (ts=0x0, queue=0)
>  	at /usr/src/sys/kern/subr_turnstile.c:838
>      #9  0xffffffff8092ebe0 in __mtx_unlock_sleep (c=0xfffff80002df0390,
>  	opts=<value optimized out>,
>  	file=0xffffffff81a25801 "%s: Can't handle disordered parameters %d:%d\n",
>  	line=1) at /usr/src/sys/kern/kern_mutex.c:791
>      #10 0xffffffff8092eb69 in __mtx_unlock_flags (c=<value optimized out>,
>  	opts=<value optimized out>,
>  	file=0xffffffff81a25801 "%s: Can't handle disordered parameters %d:%d\n",
>  	line=1) at /usr/src/sys/kern/kern_mutex.c:254
>      #11 0xffffffff81a1b724 in smb_iod_thread (arg=0xfffff80002df0300)
>  	at /usr/src/sys/modules/smbfs/../../netsmb/smb_iod.c:624
>      #12 0xffffffff8091244a in fork_exit (
>  	callout=0xffffffff81a1b670 <smb_iod_thread>, arg=0xfffff80002df0300,
>  	frame=0xfffffe003d6c0c00) at /usr/src/sys/kern/kern_fork.c:1018
>      #13 0xffffffff80d30d2e in fork_trampoline ()
>  	at /usr/src/sys/amd64/amd64/exception.S:611
>      #14 0x0000000000000000 in ?? ()
>      Current language:  auto; currently minimal
>      (kgdb)
> 
> 
> Any tips on howto proceeed with this ?
> 
> I can setup a dedicated VM with a fresh install of whatever in case it helps.
> 
> Greetings
> Christian
> 
> --
> Christian Kratzer                   CK Software GmbH
> Email:   ck@cksoft.de               Wildberger Weg 24/2
> Phone:   +49 7032 893 997 - 0       D-71126 Gaeufelden
> Fax:     +49 7032 893 997 - 9       HRB 245288, Amtsgericht Stuttgart
> Mobile:  +49 171 1947 843           Geschaeftsfuehrer: Christian Kratzer
> Web:     http://www.cksoft.de/
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
> 



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1721669289.24365403.1444083414400.JavaMail.zimbra>