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.
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:38 UTC