Re: panic: sleeping thread & bufwrite: buffer is not busy???

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