Article Number: 541107

printer Print mail Email

RecoverPoint for Virtual Machines: Purple screen after I/O Submission failure

Summary: Purple screen after I/O Submission failure

Primary Product: RecoverPoint for Virtual Machines

Product: RecoverPoint for Virtual Machines more...

Last Published: 16 Sep 2020

Article Type: Break Fix

Published Status: Online

Version: 6

RecoverPoint for Virtual Machines: Purple screen after I/O Submission failure

Article Content

Issue


Issue:     
Purple screen after I/O Submission failure

Impacted Configuration or Settings:     
esx_splitter

Impact on RP:     
The splitter frees the same memory twice, resulting in a Purple Screen
Cause
Root cause:     
An unexpected callback called from VMWare kernel for a failed I/O submission causes the CommandIo to be freed from both the dispatch path and from the callback. The expectation is that if the I/O submission failed, it will not get a callback, and the CommandIo would be cleaned up in dispatch path only.

Symptoms found in the logs:     
In the vmkernel logs, the failed submission (first two lines) is seen, followed by the unexpected callback context (last line):     

2019-12-17T07:05:27.096Z cpu45:56697377)esx_splitter: KL_ERROR:944: #0 - IoEsx_ToStorage_s_forwardToLower: VSCSIFilter_IssueCommandToBackend Failed, with status I/O error
  2019-12-17T07:05:27.096Z cpu45:56697377)esx_splitter: KL_ERROR:944: #0 - CommandIoFromRpaRead_v_submitToStorage_i: Failed to submit IO. ID = 68280148. guid = 0x72e25d215066f427 res = I/O error
  2019-12-17T07:05:27.096Z cpu45:56697377)esx_splitter: KL_INFO:869: #2 - IoEsx_ToStorage_s_readFromStorageDone: command is null for io 0x431a0c0d40a0, skipping CommandIoBase_v_storageReadEndIo
Resolution
Resolution:     
Issue addressed in RP versions 5.2.2.4.0 and 5.3
Notes

Issue


Issue:     
Purple screen after I/O Submission failure

Impacted Configuration or Settings:     
esx_splitter

Impact on RP:     
The splitter frees the same memory twice, resulting in a Purple Screen
Cause
Root cause:     
An unexpected callback called from VMWare kernel for a failed I/O submission causes the CommandIo to be freed from both the dispatch path and from the callback. The expectation is that if the I/O submission failed, it will not get a callback, and the CommandIo would be cleaned up in dispatch path only.

Symptoms found in the logs:     
In the vmkernel logs, the failed submission (first two lines) is seen, followed by the unexpected callback context (last line):     

2019-12-17T07:05:27.096Z cpu45:56697377)esx_splitter: KL_ERROR:944: #0 - IoEsx_ToStorage_s_forwardToLower: VSCSIFilter_IssueCommandToBackend Failed, with status I/O error
  2019-12-17T07:05:27.096Z cpu45:56697377)esx_splitter: KL_ERROR:944: #0 - CommandIoFromRpaRead_v_submitToStorage_i: Failed to submit IO. ID = 68280148. guid = 0x72e25d215066f427 res = I/O error
  2019-12-17T07:05:27.096Z cpu45:56697377)esx_splitter: KL_INFO:869: #2 - IoEsx_ToStorage_s_readFromStorageDone: command is null for io 0x431a0c0d40a0, skipping CommandIoBase_v_storageReadEndIo
Resolution

Resolution:     
Issue addressed in RP versions 5.2.2.4.0 and 5.3

Notes

Article Attachments

Attachments

Attachments

Article Properties

First Published

Tue Feb 11 2020 04:41:33 GMT

First Published

Tue Feb 11 2020 04:41:33 GMT

Rate this article

Accurate
Useful
Easy to understand
Was this article helpful?
0/3000 characters