Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 7 Oct 2015 08:52:30 +0200 (CEST)
From:      Christian Kratzer <ck-lists@cksoft.de>
To:        John Baldwin <jhb@freebsd.org>
Cc:        Rick Macklem <rmacklem@uoguelph.ca>, freebsd-stable@freebsd.org
Subject:   Re: smbfs crashes since approx. 10.1-RELEASE
Message-ID:  <alpine.BSF.2.20.1510070844030.16263@noc1.cksoft.de>
In-Reply-To: <2148690.gx9M0ZzrG1@ralph.baldwin.cx>
References:  <alpine.BSF.2.20.1510051157450.16263@noc1.cksoft.de> <1721669289.24365403.1444083414400.JavaMail.zimbra@uoguelph.ca> <2148690.gx9M0ZzrG1@ralph.baldwin.cx>

next in thread | previous in thread | raw e-mail | index | archive | help
Hi,

On Tue, 6 Oct 2015, John Baldwin wrote:
<snipp/>
>> 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
>
> tsleep() with Giant is still allowed.  However, this sort of panic usually means
> you unlocked a mutex you didn't hold (but without INVARIANTS enabled or you'd get
> an assertion failure earlier).
>
> I don't see anything obviously wrong in smb_iod_thread() however.
>
> If you have the crashdump, can you please run this in kgdb:
>
> frame 9
> p (struct mtx *)c
> p *(struct mtx *)c

yes I have. Here we go:

--snipp--
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:0xfffffe004e79bac0
frame pointer           = 0x28:0xfffffe004e79baf0
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         = 12235 (smbiod172)
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: 1d18h34m4s
Dumping 161 out of 999 MB:..10%..20%..30%..40%..50%..60%..70%..80%..90%..100%

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) frame 9
#9  0xffffffff8092ebe0 in __mtx_unlock_sleep (c=0xfffff8002f531790, 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
791     /usr/src/sys/kern/kern_mutex.c: No such file or directory.
         in /usr/src/sys/kern/kern_mutex.c
Current language:  auto; currently minimal
(kgdb) p (struct mtx *)c
$1 = (struct mtx *) 0xfffff8002f531790
(kgdb) p *(struct mtx *)c
$2 = {lock_object = {lo_name = 0x6 <Address 0x6 out of bounds>, lo_flags = 0, lo_data = 0, lo_witness = 0xfffff8002f531798},
   mtx_lock = 1444181401}
(kgdb)
--snipp--

I can build a GENERIC kernel with INVARIANTS enabled on the box to see if we get a better assertions next time this happens.

That is in case it happens at all with a debug build.

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/



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.20.1510070844030.16263>