Port multiplier support in opensolaris

I just saw the following opensolaris putback notice:

PSARC/2009/394 SATA Framework Port Multiplier Support
6422924 sata framework has to support port multipliers
6691950 ahci driver needs to support SIL3726/4726 SATA port multiplier

This is awesome news, and I’m hopeful this will allow me to use one of my external SATA enclosures with OpenSolaris. Time to live upgrade my systems!

Using the CPU power management features in Solaris

I mentioned previously that I built out some new hardware. When I was spec’ing out the hardware, I made sure to get “green” components that supported advanced power management features. Solaris is able to take advantage of the CPU power states, and can lower the processor operating frequency when a server is idle. Power managementis handled by the the Solaris kernel, and configured through the /etc/power.conf configuration file. By default, the file will contain a CPU power management entry similar to the following:

cpupm                   enable
cpu-threshold           1s

The cpupm directive enables CPU power management, and the cpu-threshold directive indicates how often the processor needs to be idle before the CPU frequency is lowered. To check the current operating frequency of a CPU, you can check the current_clock_Hz value for each CPU:

$ kstat -m cpu_info -i 0 -s current_clock_Hz

module: cpu_info                        instance: 0     
name:   cpu_info0                       class:    misc
        current_clock_Hz                1100000000

This is awesome stuff, and when the disk power management project is integrated, servers will hopefully be able to reduce their power consumption dramatically. Viva la Solaris!

Getting core files when a Solaris hosts gets confused

In the past few months, I have had a couple of Solaris hosts go haywire (e.g., zones hanging, network interfaces no longer responding, etc.). When problems similar to these occur, I like to generate a core file from the running kernel to help the Sun support organization isolate the problem. There are two ways that I am aware of to grab a core file from a borked system. The first method utilizes the reboot utilities “-d” option:

$ reboot -d

This will reboot the host, and will generate a core file as part of the reboot. The second method uses the savecore utility to generate a core file from a running system. To use savecore, you will need to first configure a dedicated dump device (since swap is most likely in use on a production host, you can’t use it). Once the dedicated dump device is configured, the savecore utility can be run with the “-L” option:

$ savecore -Lv

It’s all about a bug free Solaris / Nevada, and these are two methods to help us get there.

Updating the Solaris boot archive from single user mode

On more than one occassion now, I have run into problems where the Solaris boot archive wasn’t in a consistent format at boot time. This stops the boot process, and the console recommends booting into FailSafe mode to fix it. If you want to do this manually, you can run the bootadm utility with the update_archive command, and the location where the root file system is mounted:

$ bootadm update_archive -v -R /a

I am hopeful that the opensolaris community will enhance the archive support to make it more fault tolerant. The current code seems somewhat brittle.

Limiting the size of Solaris tmpfs file systems

I had an application go nuts a week or two ago, and it filled up /tmp on one of my Solaris 10 hosts. Since /tmp is an in memory file system, you can only imagine the chaos this caused. :( To ensure that this never happens again, I modified the tmpfs entry in /etc/vfstab to limit tmpfs to 1GB in size:

$ grep ^swap /etc/vfstab

swap    -       /tmp    tmpfs   -       yes     size=1024m

That will teach that pesky application. :)