panic: sleeping thread & bufwrite: buffer is not busy???
Bartosz Stec
admin at kkip.pl
Fri Dec 12 10:35:12 UTC 2008
Kostik Belousov pisze:
> On Fri, Dec 12, 2008 at 08:46:10AM +0100, Bartosz Stec wrote:
>
>> Randy Bush pisze:
>>
>>> i386 soekris 5501
>>> current as of Dec 11 00:27 gmt
>>>
>>> Unread portion of the kernel message buffer:
>>> Sleeping thread (tid 100054, pid 646) owns a non-sleepable lock
>>> panic: sleeping thread
>>> panic: bufwrite: buffer is not busy???
>>> Uptime: 2m1s
>>> Physical memory: 503 MB
>>>
>>> #0 doadump () at pcpu.h:246
>>> #1 0xc0571f33 in boot (howto=260) at
>>> /usr/src/sys/kern/kern_shutdown.c:420
>>> #2 0xc05720f7 in panic (fmt=Variable "fmt" is not available.)
>>> at /usr/src/sys/kern/kern_shutdown.c:576
>>> #3 0xc06fc75c in ffs_bufwrite (bp=0xc2937e20)
>>> at /usr/src/sys/ufs/ffs/ffs_vfsops.c:1786
>>> #4 0xc05c7250 in vfs_bio_awrite (bp=0xc2937e20) at buf.h:385
>>> #5 0xc05cfee0 in vop_stdfsync (ap=0xc2a89b34)
>>> at /usr/src/sys/kern/vfs_default.c:479
>>> #6 0xc0520ad3 in devfs_fsync (ap=0xc2a89b34)
>>> at /usr/src/sys/fs/devfs/devfs_vnops.c:485
>>> #7 0xc074e50e in VOP_FSYNC_APV (vop=0xc07cc800, a=0xc2a89b34)
>>> at vnode_if.c:1007
>>> #8 0xc06fd0a2 in ffs_sync (mp=0xc2e33c80, waitfor=2, td=0xc2c28480)
>>> at vnode_if.h:529
>>> #9 0xc05e0803 in sync (td=0xc2c28480, uap=0x0)
>>> at /usr/src/sys/kern/vfs_syscalls.c:149
>>> #10 0xc0571ad2 in boot (howto=256) at
>>> /usr/src/sys/kern/kern_shutdown.c:312
>>> #11 0xc05720f7 in panic (fmt=Variable "fmt" is not available.)
>>> at /usr/src/sys/kern/kern_shutdown.c:576
>>> #12 0xc059ec81 in propagate_priority (td=0xc2e696c0)
>>> at /usr/src/sys/kern/subr_turnstile.c:222
>>> #13 0xc059f551 in turnstile_wait (ts=0xc2c0ee10, owner=0xc2e696c0,
>>> queue=Variable "queue" is not available.)
>>> at /usr/src/sys/kern/subr_turnstile.c:738
>>> #14 0xc0570c73 in _rw_wlock_hard (rw=0xc2cdcd80, tid=3267527808,
>>> file=0x0, line=0)
>>> at /usr/src/sys/kern/kern_rwlock.c:705
>>> #15 0xc06bdcb6 in in6_mtutimo (rock=0xc2cdcd00)
>>> at /usr/src/sys/netinet6/in6_rmx.c:437
>>> #16 0xc0580f77 in softclock (arg=0xc07ffbe0)
>>> at /usr/src/sys/kern/kern_timeout.c:398
>>> #17 0xc055790a in intr_event_execute_handlers (p=0xc2c257ec,
>>> ie=0xc2c22400)
>>> at /usr/src/sys/kern/kern_intr.c:1134
>>> #18 0xc0558933 in ithread_loop (arg=0xc2c07ba0)
>>> at /usr/src/sys/kern/kern_intr.c:1147
>>> #19 0xc0555cb6 in fork_exit (callout=0xc05588d0 <ithread_loop>,
>>> arg=0xc2c07ba0, frame=0xc2a89d38) at
>>> /usr/src/sys/kern/kern_fork.c:821
>>> #20 0xc0730a50 in fork_trampoline () at
>>> /usr/src/sys/i386/i386/exception.s:270
>>> _______________________________________________
>>> freebsd-current at freebsd.org mailing list
>>> http://lists.freebsd.org/mailman/listinfo/freebsd-current
>>> To unsubscribe, send any mail to
>>> "freebsd-current-unsubscribe at freebsd.org"
>>>
>> I have similiar problem:
>>
>> Dump header from device /dev/ad0s1b
>> Architecture: i386
>> Architecture Version: 2
>> Dump Length: 216797184B (206 MB)
>> Blocksize: 512
>> Dumptime: Thu Dec 11 20:20:45 2008
>> Hostname: serwer.obsysa.net
>> Magic: FreeBSD Kernel Dump
>> Version String: FreeBSD 8.0-CURRENT #3: Thu Dec 11 16:55:50 CET 2008
>> ncpnc at serwer.obsysa.net:/usr/obj/usr/src/sys/ATHLON8
>> Panic String: sleeping thread
>> Dump Parity: 1830535215
>> Bounds: 0
>> Dump Status: good
>>
>> Unfortunately I cannot provide more debug information at this time
>> because kernel was built without debugging options. (I will rebuild it
>> if needed) However I can still provide some info:
>> - kernel panic while loading modules, just after loding ZFS module (I
>> have RAIDZ configuration) and after a couple of minutes without any
>> visible action on the screen.
>> - I have this panic with *every* build I made after 7 Dec 2008, but I
>> don't remember wchich day exactly I have experienced that for the first
>> time.
>> - For now I'm using kernel builded 7 Dec 2008 and no panic seen at all.
>>
>
> You are mixing the issues without a reason. To claim that you problem
> is similar, you need to show the similar backtrace. The panic shown is
> the late manifestation of a problem, it is kind a catch-all for some
> sort of locking issues.
>
OK. I'll try to build debug kernel today and I will provide backtrace. I
forgot to mention in my last post that I saw very similiar (if not
identical) lines to:
Sleeping thread (tid 100054, pid 646) owns a non-sleepable lock
panic: sleeping thread
panic: bufwrite: buffer is not busy???
while checking dmesg buffer after one of the panics earlier. That's why
I assumed it's probably the same issue.
Sorry for confusion, they're my first steps with CURRENT and very first
experience with kernel panic :).
Cheers!
--
Bartosz Stec
More information about the freebsd-current
mailing list