It appears that Oracle has resolved the issue with the 10GbE drivers that were introduced in version 184.108.40.206.0. There is an updated note (1376664.1) that includes the patch to fix it. The issue was apparently related to TCP segmentation offloading, and can be fixed by installing the patch found in the note listed above. It does not require a reboot, and is similar to the fix for the IDT switch bug fixed in 220.127.116.11.0. Note that this bug only affected X2-2 systems utilizing 10 gigabit ethernet on the compute nodes. Oracle again recommends installing the 18.104.22.168.0 minimal pack on compute nodes.
After starting the service, users should see the following:
(root)# service disable10gigtso_13083530 start
Skipping igb interface eth0 using driver version 2.1.0-k2-1 - TSO disable unnecessary
Found ixgbe interface eth4 using driver version 2.0.84-k2 - Disabling TSO ... [SUCCESS]
Found ixgbe interface eth5 using driver version 2.0.84-k2 - Disabling TSO ... [SUCCESS]
Oracle has upgraded the supplemental note for 22.214.171.124.0 (1348647.1) with a handful of critical issues. First, there is an issue mentioned by Vishal Gupta here regarding 10 gigabit ethernet on the database servers. Currently, there is no workaround for this bug, and it is advised that customers utilizing 10 GbE on the database servers should stay on 126.96.36.199.5 for the minimal pack, while upgrading the storage servers to 188.8.131.52.0.
Additionally, there is a new issue that can be seen if the firmware on a disk fails to upgrade correctly during the patching process. If the firmware does not update correctly, it is possible that cellsrv will drop the celldisk (and corresponding griddisks), causing a loss of data on those disks. Before upgrading a cell to 184.108.40.206.0, check the status of your physical disks from cellcli with the following command:
cellcli -e 'list physicaldisk attributes luns where physicalInsertTime = null'
The command should return no output. If it does, Oracle recommends to reboot each cell that returns output from this command. After the reboot has completed, run the command again to verify that the disks are ready to be patched. Here is the output from one of Enkitec’s quarter rack systems (note that there is no output given, so the disks are ok to be upgraded):
> dcli -g cell_group -l root cellcli -e 'list physicaldisk attributes luns where physicalInsertTime = null'
Remember that these issues are not mentioned in the standard README files included in the 220.127.116.11.0 patch. Before applying any Exadata Storage Server patches, always consult the supplemental note that is referenced in the supported versions for Exadata note (#888828.1), as these notes are updated after a patch has been released.