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!
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:
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
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!
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.
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.
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. :)
While researching PCI and MOESI this week, I came across the Sun developer connection article Writing Solaris PCI Device Drivers for Sun SPARC Platforms. While I am only 25% done reading it, the material is top notch, and is helping me understand the counters printed by busstat(1m).