There was a kernel bug, 4244523, that required a temporary
workaround which was to turn off ISM in /etc/system and
in the database application, for example, Oracle's init.ora file.
This was fixed in the Solaris 5.6 kernel update patch 105181-15.

Unfortunately some customers may forget to remove the modifications
to /etc/system and init.ora after upgrading their kernel. ISM
is enabled by default. The following should NOT be in /etc/system:

    shmsys:ism_off=1
    shmsys:share_page_table=1
    
In addition Oracle's init.ora should NOT have:
 
    use_ism=false
       
To turn off ISM can cause severe performance degradation and
cause what appears to be a hung state.       

PROPRIETARY and CONFIDENTIAL - FOR INTERNAL USE ONLY

The following is an email thread from Paris Bingham.

IF YOU WANT TO SAVE YOURSELF SOME REAL E10K HEARTBURN, PLEASE READ!!!

We have now run across, for the fourth time, a 2.6 E10K system that degrades
itself to the point of appearing hung.  In all four cases, this has been
caused by ISM not being enabled.  I suspect that what is happening is this:

1.  A data corruption problem was discovered on E10K systems (only) running
    the 105181-14 patch or less.  The problem was tracked to a bug in the
    ISM memory management code.  The only realistic workaround was to disable
    ISM.

2.  Lots of customers hear about this bug, and not wanting to risk data
    corruption, disable ISM.

3.  The 105181-15 is released, which fixes the ISM problem.

4.  Customers install 105181-15 (or higher), but they forget to re-enable ISM.

5.  Now, somewhere along the way, the systems will eventually grind themselves
    into what appears to be a hang state.  The reason being an excessive use of
    kernel memory in the sfmmu8_cache, caused by ISM not being enabled.

	The sfmmu8_cache size can be checked using crash, with the subcommand
	of kmastat.

If you know of any E10K customers running databases which are capable of
using ISM (almost all of them are), please, Please, PLEASE have them
re-enable ISM if they are running patch 105181-15 or higher.

Thanks,
Paris

By default, ISM is available for use when the system boots.  But, whether
ISM is actually getting used or not is dependent on the application making
the proper request to have it's shared memory attached in ISM mode.
In Oracle, there is a parameter in the init.ora file (called use_ism
I believe) that tells Oracle to always attach shared memory in ISM mode.
Check with the vendor of other RDBMS's to see how they do it.

This default behavior can be changed with two parameters in the /etc/system
file:

	set shmsys:ism_off=1		Force ISM off no matter what
	set shmsys:ism_off=0		Default behavior above
	
	set shmsys:share_page_table=1	Force ISM attaches no matter what
	set shmsys:share_page_table=0	Default behavior above
	
By setting ism_off to one, you can forcibly disable ISM attaches no matter
what the application wants to do.  By setting share_page_table to one,
you can force all attaches to be in ISM mode no matter what the application
specifies.  share_page_table takes precedence over ism_off, so if both
are one, ISM is forced.  Both of the above parameters are considered "internal
use only" and were added for testing purposes; they should never appear in a
customer's /etc/system file.

So the answer to both questions above is:

1.  Remove any settings of ism_off or share_page_table from the /etc/system
    file.
    
2.  Configure the applications to select ISM on their own using their
    configuration files, e.g. init.ora.
    
Sorry I didn't spell this out more clearly the first time.

HTH,
Paris

Authors Note: There was an older bug which also caused some customers
to turn off ISM. Again ISM should not be turned off on any Ultra servers.

(from 105181-06)
4089777 processes can hang or crash while forking with ISM on sun4u