Knowledge Base

Summaries and Symptoms

This patch resolves the following issues:

• When the aacraid driver handles SCSI aborts but fails to call the scsi_done handler before completion, the ESXi host becomes unresponsive with the following warning message:

  0:00:25:03.275 cpu0:4204)WARNING: SCSILinuxAbortCommands Failed, Driver AAC, for vmhba0
  0:00:25:03.407 cpu0:4204)<3>aacraid: Host adapter abort request (2,0,0,0) - cmd 0x41000a023fc0 (0x28)
  0:00:25:03.415 cpu0:4204)<3>aacraid: Host adapter abort request (2,0,0,0) - cmd 0x41000a023fc0 (0x28) - FAILED
  0:00:25:03.425 cpu0:4204)WARNING: SCSILinuxAbortCommands Failed, Driver AAC, for vmhba0
  0:00:25:03.461 cpu2:4203)<3>aacraid: Host adapter abort request (2,3,0,0) - cmd 0x41000a02bdc0 (0x0)
  0:00:25:03.469 cpu2:4203)<3>aacraid: Host adapter abort request (2,3,0,0) - cmd 0x41000a02bdc0 (0x0) - SUCCESS
  0:00:25:03.479 cpu2:4203)WARNING: SCSILinuxAbortCommand - The driver failed to call scsi_done from itsabort handler and yet it returned SUCCESS
  
  
  The issue is noticed in PMC-Sierra (earlier Adaptec) RAID controllers.
  
  
• Multiple threads compete during task deactivation in the ESXi software iSCSI initiator. This might cause the ESXi server to become unresponsive with a purple diagnostic screen showing messages similar to the following:
  
  7:01:32:32.996 cpu2:4098)0x417f800179b8:[0x41800da85e31]vmk_SPUnlock@vmkernel:nover+0x0 stack: 0x0
  7:01:32:32.997 cpu2:4098)0x417f80017a78:[0x41800e22a86b]iscsivmk_TaskHandleTx@ESXi:nover+0x46 stack: 0x4100be04c490
  7:01:32:32.997 cpu2:4098)0x417f80017ac8:[0x41800e22acaf]iscsivmk_ConnProcessTxSchQueue@ESXi:nover+0x116 stack: 0x417f80017b00
  7:01:32:32.997 cpu2:4098)0x417f80017bc8:[0x41800e22b72e]iscsivmk_ProcessWorldletConnTxEvent@ESXi:nover+0x3ad stack: 0x417fce2
  
  

  or

  43:12:49:27.294 cpu5:5012)0x417f81ca7b98:[0x41800da8bd0f]vmk_SPLock@vmkernel:nover+0x12 stack: 0x0
  43:12:49:27.295 cpu5:5012)0x417f81ca7bd8:[0x41800e19c051]iscsivmk_TransportStopConn@ESXi:nover+0xbc stack: 0x0
  43:12:49:27.295 cpu5:5012)0x417f81ca7c78:[0x41800df4e285]iscsitrans_HandleEvent@ESXi:nover+0x790 stack: 0x417f81ca7cb4
  43:12:49:27.295 cpu5:5012)0x417f81ca7ce8:[0x41800df4f6d2]iscsitrans_VmklinkCallback@ESXi:nover+0x169 stack: 0x41000000001d
  43:12:49:27.296 cpu5:5012)0x417f81ca7d38:[0x41800dbbdd28]VmkApiLinkSocketCallback@vmkernel:nover+0x53 stack:
  

  This issue might occur due to the following reasons:

  1. The task management thread attempts to abort a task, while the transmit thread attempts to take up the same task for data transmission.
  2. A task attempts completion normally while the task's connection is being closed.

  
  
• If a filesystem has a queue of inputs and outputs lined through libaio and does not cancel these inputs and outputs before it closing and releasing the file handle associated with the aiohandle, the ESXi server might become unresponsive with a purple diagnostic screen showing the following message:
  
  30:16:01:19.557 cpu7:4161)0x417f8020ff90:[0x418036c35477]LibAIODoAsyncIO@vmkernel:nover+0x16 stack: 0x417f8020fff0
  30:16:01:19.558 cpu7:4161)0x417f8020fff0:[0x418036a29a27]helpFunc@vmkernel:nover+0x53e stack: 0x0
  30:16:01:19.558 cpu7:4161)0x417f8020fff8:[0x0] < unknown > stack: 0x0
  30:16:01:19.568 cpu7:4161)FSbase:0x0 GSbase:0x418041c00000 kernelGSbase:0x0
  
  
  
• In the vSphere Client, the Hardware Status section of IBM 3650 M3 hosts show a battery status alert:
  
  Battery on Controller NN (Health State Not Good): Alert: Battery Status: Fully Charged
  
  Storelib in ESXi 4.x does not support iBBU08 raid controller battery, which causes an invalid alert on the Hardware Status tab of the Virtual Center Server and Health Status of the vSphere Client.
  
  
  
  

• The Python third party library is updated to Python 2.5.6 on ESXi to fix multiple security issues. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the names CVE-2009-3560, CVE-2009-3720, CVE-2010-1634, CVE-2010-2089, and CVE-2011-1521 to these issues.

• An erroneous code sends out Reverse Address Resolution Protocol (RARP) broadcasts immediately after a unicastAddress is changed. The issue is resolved by timing the RARP broadcasting in a timer to avoid RARP packets from flooding.
  
  
• ESXi generates unnecessary and excessive Reverse Address Resolution Protocol (RARP) packets when virtual machines join or leave multicast groups.

Deployment Considerations

None beyond the required patch bundles and reboot information listed in the table above.