search for: mutex_enter

..., which has static probes. It is calling fork(), which causes it to end up at line 330 in fork.c: > 328 if (p->p_dtrace_helpers != NULL) { > 329 ASSERT(dtrace_helpers_fork != NULL); > 330 (*dtrace_helpers_fork)(p, cp); > 331 } > 332 > 333 mutex_enter(&p->p_lock); > 334 p->p_flag &= ~SFORKING; > 335 sprunlock(p); As you can see, the parent is sprlock''d. The call to dtrace_helpers_fork() ends up at line 13526 in dtrace.c: > 13526 mutex_enter(&dtrace_lock); > 13527 ASSERT(from->p_dtrace...

Author: maybee Repository: /hg/zfs-crypto/gate Revision: 424a72a4d1acbaacc5a5ae97dbb86dbe6f988d65 Log message: 6397271 panic: mutex_enter: bad mutex, lp=f074ea3c owner=deadbee8 thread=d794fde0 Files: update: usr/src/uts/common/fs/zfs/dnode_sync.c

...s.py Using config file "./solaris.py". Started domain solaris v3.2-1 chgset ''unavailable'' SunOS Release 5.11 Version snv_85 32-bit Copyright 1983-2008 Sun Microsystems, Inc. All rights reserved. Use is subject to license terms. panic[cpu0]/thread=f5028f20: [b]recursive mutex_enter[/b], lp=d245efd8 owner=f5028f20 thread=f5028f20 f5053454 unix:mutex_panic+55 (f50099e8, d245efd8) f5053494 unix:mutex_vector_enter+185 (d245efd8) f50534cc unix:x86pte_mapin+5f (3e244, 0, d26d7e38) f50534e4 unix:x86pte_access_pagetable+32 (d26d7e38, 0) f5053504 unix:x86pte_get+15 (d26d7e38, 0) f505...

Hi, Can a dbuf be in DB_CACHED state, db_holds == 0, b_efunc != NULL while its db_buf is put on the eviction list ? From an ASSERT in dbuf_do_evict(), it appears that it can. If it can, I am wondering what is preventing the following race dbuf_hold_impl() db = dbuf_find(dn, level, blkid); ... if (db->db_buf && refcount_is_zero(&db->db_holds)) {

http://defect.opensolaris.org/bz/show_bug.cgi?id=1986 Summary: ''zfs destroy'' hangs on encrypted dataset Classification: Development Product: zfs-crypto Version: unspecified Platform: Other OS/Version: Solaris Status: NEW Severity: major Priority: P2 Component: other

...38 unix: [ID 100000 kern.notice] genunix: [ID 655072 kern.notice] ffffff00100916d0 unix:die+c8 () genunix: [ID 655072 kern.notice] ffffff00100917e0 unix:trap+13b1 () genunix: [ID 655072 kern.notice] ffffff00100917f0 unix:cmntrap+e9 () genunix: [ID 655072 kern.notice] ffffff0010091940 unix:mutex_enter+b () genunix: [ID 655072 kern.notice] ffffff0010091960 zfs:zio_buf_alloc+25 () genunix: [ID 655072 kern.notice] ffffff00100919a0 zfs:zio_read_init+49 () genunix: [ID 655072 kern.notice] ffffff00100919d0 zfs:zio_execute+7f () genunix: [ID 655072 kern.notice] ffffff0010091a10 zfs:zio_wait+2e () genun...

These three patches (for discussion only, NOT to be applied) implement a mutex system that lets the user limit the number of libguestfs instances that can be launched per host. There are two uses that I have identified for this: firstly so we can enable parallel-tests (the default in automake >= 1.13) without blowing up the host. Secondly oVirt has raised concerns about how to limit the

Hi list, since we activated 10gbe on ixgbe cards + jumbo frames(9k) on 9.0 and now on 9.1 we recognize that after a random period of time, sometimes a week, sometimes only a day, the system doesn't send any packets out. The phenomenon is that you can't login via ssh, nfs and istgt is not operative. Yet you can login on the console and execute commands. A clean shutdown isn't possible

Hi, I work on a support team for the Sun StorEdge 6920 and have a question about the use of the SCSI sync cache command in Solaris and ZFS. We have a bug in our 6920 software that exposes us to a memory leak when we receive the SCSI sync cache command: 6456312 - SCSI Synchronize Cache Command is flawed It will take some time for this bug fix to role out to the field so we need to understand

Hi, Since almost all operations in the FUSE low-level API identify files by inode number, I''ve been using zfs_zget() to get the corresponding znode/vnode in order to call the corresponding VFS function in zfs_vnops.c. However, there are some cases when zfs_zget() behaves slightly different than I need: 1) If zp->z_unlinked != 0 then zfs_zget() returns ENOENT. I need it to return

Just to let people know what my big picture is, I''m trying to write a script that will let me run a program, and name a progeny of that program that I want to debug. My script should find the first occurrence of that progeny, and run it until it finishes initializing the runtime linker, but stop it before it runs any shared library startup routines. (Failing that, I''d be okay

I just had a quick play with gzip compression on a filesystem and the result was the machine grinding to a halt while copying some large (.wav) files to it from another filesystem in the same pool. The system became very unresponsive, taking several seconds to echo keystrokes. The box is a maxed out AMD QuadFX, so it should have plenty of grunt for this. Comments? Ian

Hello, I am building a home file server and am looking for an ATX mother board that will be supported well with OpenSolaris (onboard SATA controller, network, graphics if any, audio, etc). I decided to go for Intel based boards (socket LGA 775) since it seems like power management is better supported with Intel processors and power efficiency is an important factor. After reading several

Now at 36 hours since zdb process start and: PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/NLWP 827 root 4936M 4931M sleep 59 0 0:50:47 0.2% zdb/209 Idling at 0.2% processor for nearly the past 24 hours... feels very stuck. Thoughts on how to determine where and why? -- This message posted from opensolaris.org