Appendix BRevision History for this Manual
This section describes the revision history for this manual.
Current Version--Solaris 9 8/03
Release
The current version of this manual applies to the Solaris 9
8/03 release.
New Parameters
ip_multidata_outbound
This parameter is new in the Solaris 9 8/03 release.
For information, see ip_multidata_outbound.
ip_policy_mask
This parameter is new in the Solaris 9 12/02 release.
For information, see ip_policy_mask.
logevent_max_q_sz
This parameter is new in the Solaris 8 1/01 release.
For information, see logevent_max_q_sz.
Unsupported or Obsolete Parameters
priority_paging and cachefree
are Not Supported
The priority_paging and cachefree
tunable parameters are not supported in the Solaris 9 release. They have been
replaced with an enhanced file system caching architecture that implements
paging policies similar to priority paging, but are always enabled. Attempts
to set these parameters in the /etc/system file result
in boot-time warnings such as:
sorry, variable 'priority_paging' is not defined in the 'kernel'
sorry, variable 'cachefree' is not defined in the 'kernel'
|
The SUNWcsr packages that contain the /etc/system file have been modified so that the inclusion of the priority_paging or cachefree tunable parameters
are prohibited. If you upgrade to the Solaris 9 release or pkgadd the SUNWcsr packages and your /etc/system file includes the priority_paging or cachefree parameters, the following occurs:
This message is displayed if the priority_paging or cachefree parameters are set in the /etc/system file:
/etc/system has been modified since it contains references to priority
paging tunables. Please review the changed file.
|
Comments are inserted in the /etc/system
file before any line that sets priority_paging or cachefree. For example, if priority_paging is
set to 1, the following lines are inserted before the line with the priority_paging value:
* NOTE: As of Solaris 9, priority paging is unnecessary and has been removed.
* Since references to priority paging-related tunables will now result in
* boot-time warnings, the assignment below has been commented out. For more
* details, see the Solaris 9 Release Notes, or the "Solaris Tunable Parameters
* Reference Manual".
|
Obsolete Parameters
The following parameters are now obsolete.
rlim_fd_max
shmsys:shminfo_shmmin
shmsys:shminfo_shmseg
Changed Parameters
These parameters changed or were corrected.
maxusers
The following section changed.
| Range | 1 to 2048
to:
| | Range | 1 to 2048, based on physical
memory without any setting in the /etc/system file.
1 to 4096, if set in the /etc/system file.
|
pages_pp_maximum
The following sections changed.
| Default | Maximum of the triplet (200, tune_t_minarmem + 100, [10% of memory available at boot time])
to:
| | Default | The greater of (tune_t_minarmem + 100 and [4% of memory available at boot time +
4 Mbytes])
| | Range | Default value to no more than
20% of physical memory. The systems does no enforcement of this range other
than that described in the Validation section.
to:
| | Range | Minimum value enforced by
the system is tune_t_minarmem + 100. The system does not
enforce a maximum value.
| | Dynamic? | Yes, unless dynamic reconfiguration
operations that add or delete memory occur. At that point, the value is reset
to whatever was provided in the /etc/system file or was
calculated.
| | Validation | Maximum of the quadruplet
(200, tune_t_minarmem + 100, [10% of memory available],
and the value from /etc/system). No message is displayed
if the value from /etc/system is increased. Done only
at boot time.
to:
| | Validation | If the value specified
in the /etc/system file or the calculated default is
less than tune_t_minarmem + 100, the value is reset to
tune_t_minarmem + 100.
No message is displayed if the value from the /etc/system
file is increased. Done only at boot time, and during dynamic reconfiguration
operations that involve adding or deleting memory.
| | When to Change | When memory locking
requests or attaching to a shared memory segment with the SHARE_MMU flag fails, yet the amount of memory available seems to be sufficient.
Keeping 10% of memory free on a 32-Gbyte system might be excessive.
Excessively large values can cause memory locking requests to fail unnecessarily.
to:
| | When to Change | When memory locking
requests or attaching to a shared memory segment with the SHARE_MMU flag fails, yet the amount of memory available seems to be sufficient.
Excessively large values can cause memory locking requests to fail unnecessarily.
|
| 
Previous