Atcht; it's late. I forgot to mention that this system is a sparc64 V240
2-way SMP machine. It's running a kernel from 9.0-CURRENT r222833+262af52:
Tue Jun 7 18:47:35 EDT 2011 and a userland from a little later.
Sorry about that.
--nwf;
On Thu, Jun 16, 2011 at 03:31:38AM -0400, N
I have a few applications (bonnie++ and mysql, specifically, both from
ports) which trip over the assertion in
lib/libc/stdlib/malloc.c:/^_malloc_thread_cleanup that
> assert(tcache != (void *)(uintptr_t)1);
I have patched malloc.c thus:
> --- a/lib/libc/stdlib/malloc.c
> +++ b/lib/libc/stdlib/
nd disks) are common between this and the
machine reporting below.
Thoughts? Any help would be greatly appreciated.
Thanks.
--nwf;
On Wed, Apr 06, 2011 at 04:00:43AM -0400, Nathaniel W Filardo wrote:
>[...]
> panic: Lock buf_hash_table.ht_locks[i].ht_lock not exclusively locked @
> /usr/src/s
When racing two workloads, one doing
> zfs recv -v -d testpool
and the other
> find /testpool -type f -print0 | xargs -0 sha1
I can (seemingly reliably) trigger this panic:
panic: Lock buf_hash_table.ht_locks[i].ht_lock not exclusively locked @
/usr/src/sys/modules/zfs/../../cddl/contrib/openso
Well, I'm back in the same town as my sparc64 and so csup'd, built, and
rebooted, trying to get more information about the "vm object not owned"
panic I reported a while ago. To my dismay, I now get this panic, also late
enough in the boot process to be starting up jails:
panic: cheetah_ipi_selec
Attempting to boot on (2-way SMP; SUN Fire V240) sparc64 a 9.0-CURRENT
kernel built on Jun 9 at 14:41, and fully csup'd before building (I don't
have the SVN revision number, sorry) yields, surprisingly late in the boot
process, this panic:
panic: mutex vm object not owned at /systank/src/sys/vm/v
