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

From: Kostik Belousov <kostikbel_at_gmail.com>
Date: Fri, 12 Dec 2008 11:52:38 +0200
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.

Received on Fri Dec 12 2008 - 08:52:45 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:38 UTC