Solaris 10 Kernel Patches 147440-04 and 147441-04 (WITHDRAWN) May Cause Systems Using VxVM to Panic on Reboot

Description

Solaris 10 kernel patches 147440-04/147441-04 (and later revisions) cause a panic in swapify() on systems that have one of the following VxVM configurations:

1.a VxVM swap volume
2.a VxVM volume used as the dump device
The panic occurs upon reboot after installing the affected patches.

Note: Patches 147440-04 and 147441-04 have been withdrawn from MOS. Patches 147440-05/147441-05 and 147440-06/147441-06 have been modified prior to release so that their installation will halt on systems affected by this issue.



Occurrence

This issue can occur in the following releases:

SPARC Platform

•Solaris 10 with patch 147440-04 or later and without patch 147440-07
•Solaris 11 without SRU 11/11 SRU4
x86 Platform

•Solaris 10 with patch 147441-04 or later and without patch 147441-07
•Solaris 11 without SRU 11/11 SRU4
Note 1: Solaris 8, Solaris 9, and Solaris 11 Express are not impacted by this issue.

Note 2: Only systems with one of the following VxVM configurations are affected by this issue:

1. VxVM swap volumes

To determine if a system has a VxVM swap volume, execute the following command:

    $ swap -l
    swapfile          dev  swaplo blocks   free
    /dev/vx/dsk/bootdg/swapvol 339,5001     16 16386384 16386384
2. VxVM volume used as a dump device

To determine if a system is using a VxVM volume as a dump device, execute the following command:

    $ dumpadm
    Dump content: kernel pages
    Dump device: /dev/vx/dsk/bootdg/dumpvol
    Savecore directory: /var/crash/machine
    Savecore enabled: yes
    Save compressed: on

Symptoms

Should the described issue occur, a panic similar to the following is seen:

    panic[cpu0]/thread=30001fc32c0: BAD TRAP: type=31 rp=2a100851420 addr=0 mmu_fsr=0 occurred in module "vxio"
    due to a NULL pointer dereferenceThe stack trace may mention swapify(), but the panic stack trace may vary.

Workaround

Systems with one of the affected VxVM configurations listed above should not be installed with the affected patches 147440-04 and 147441-04.

If this issue occurs, the system can be recovered by booting from a clone disk if one was set up initially, and then using patchrm(1M) against the root disk. If the encapsulated boot environment was mirrored and one set of mirror plexes was detached prior to patching, the best recourse is to boot from the detached mirror plexes to roll back to the pre-patch state. Otherwise, the boot environment should be unencapsulated and then patchrm run to remove the problem patch.

If it is necessary to install the affected patches onto a system that has VxVM swap volumes, this can be achieved by first removing the swap volumes using 'swap -d' and then removing all VxVM swap volume entries from the file /etc/vfstab. Furthermore, it is necessary to set a non-VxVM based dump device using 'dumpadm -d' or 'dumpadm swap'. The affected patches can then be installed. However, a VxVM swapvol cannot be added back at the end of this procedure until such time as a fix for this issue 7108029 has been installed. After this procedure, it is safe to use disk slices and file-based or ZFS based swap volumes as it is only VxVM swap volumes that are affected by this issue.

This issue is addressed in the following releases:

SPARC Platform:

•Solaris 10 with patch 147440-07 or later
•Solaris 11 with SRU 11/11 SRU4 or later
x86 Platform:

•Solaris 10 with patch 147441-07 or later
•Solaris 11 with SRU 11/11 SRU4 or later