Did you try bigadmin?
-Original Message-
From: opensolaris-discuss-boun...@opensolaris.org
[mailto:opensolaris-discuss-boun...@opensolaris.org] On Behalf Of Tan
Loc Pham
Sent: Wednesday, February 03, 2010 6:11 AM
To: opensolaris-discuss@opensolaris.org
Subject: [osol-discuss] Solaris Zone
So if one of the disks goes south you dont send the system off into
the weeds because /tmp is blown up, backing store for stacks/heap/other
anon disappear, etc. Spanning swap across two spindles instead of
mirroring swap on an erstwhile HA system just introduces two single
points of failure.
--
Wondering if anyone knows the reason mmap always returns space 64K aligned on
32 bit sparc apps. If many small files are mmap'd, lots of address space gets
eaten up.
Also, can it be changed via a knob anywhere?
Thanks
-d
This message posted from opensolaris.org
OK, I confess, this isnt opensolaris, its S10 0606. But a lot of smart people
hang out here so I'll post anyway.
A multithreaded process core dumps with this traceback:
fed40f90 _lwp_kill (ffbfeec8, fed700b8, 39eb4, 0, fed68284, fed70904) + 8
fed2e574 thr_panic (fed55e10, 65, 39de0, feca2390,
Yup, UMEM_DEBUG exported.
It wasnt clear to me whether it took a value or not, but the comments
suggested to me it might:
50 *
51 * If the item is valid, item_flag_target != NULL, and:
52 * type is not CLEARFLAG, then (*item_flag_target) |=
item_flag_value
53 *
Anyone know the proper incantation for setting the noabort flag to avoid cores
on recoverable errors when using libumem? I've tried
UMEM_DEBUG=noabort=1 /* which seems like the right thing AFAIK */
UMEM_DEBUG=noabort=0
UMEM_DEBUG=noabort
But in all cases umem_err_recoverable calls umem_do_abo
Does anyone know of any pathway by which a userland process can core dump,
apparently due to SEGV, *without* calling the user installed signal handler?
I've been puzzling out a problem wherein the only conclusion I can reach is
that this process'd parent reports that the child died due to sig
However, many of the <4M binaries also dynamically link with many
libraries which individually are also <4M. But in the in the aggregate
they are >4M and thrash the 512x8K itlb beyond recognition. I did a
little experiment with this (posted on performance:discuss) wherein I
took such an app and a
MAIL PROTECTED]
> Sent: Monday, August 22, 2005 1:37 AM
> To: David McDaniel (damcdani)
> Cc: opensolaris-discuss@opensolaris.org
> Subject: Re: [osol-discuss] Obscure umem semantics
>
> On Wed, Aug 17, 2005 at 06:46:40PM -0700, David McDaniel wrote:
> > This might be better
Its really none of my business, but it seems to me you should at least
consider attaching an OpenSolaris presence to some of the traditional
telecom shows where Sun is often present in other guises, like
Supercomm. This might be an opportunity to to win back some otherwise
eroding mindshare to th
This might be better suited to another board, but if so I dont know which one.
In any case the dialog might be valuable to the community at large. To wit:
I dont fully grasp the semantics of umem_cache_alloc, et al. Some use cases
or examples would really help. A few of the obscure (to me) poin
Certainly in my mind some classes (or perhaps just some blueprints
with non-trivial examples) on how to deal with the introduction of smf.
For ISV's who have ostensibly portable products, ie Solaris and Linux,
migrating from traditional rc scripts can be a challenge.
-d
> -Original Message-
12 matches
Mail list logo
