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: [email protected] 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/
_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[email protected]"
