Core dump VSCSIPoll "tried to re-acquire lock" on Supermicro Xeon D-1518. Anyone knows about this?

[bateau59]

Hi,

Very sorry to do this here, my VMUG licenses do not include support, and this is not critical enough for me to start paying for support, although it would be nice if I found out what this is about.

at 1AM precisely a couple of days ago I got a PSOD on a latest version ESXi, latest patches, on a Supermicro X10SDV-4C+-TLN4F, with latest BIOS and all.

Anyone knows what this is about?

Here is the dump:

2018-02-22T01:00:06.963Z cpu0:65720)World: 2776: PRDA 0x418040000000 ss 0x0 ds 0x10b es 0x10b fs 0x10b gs 0x0

2018-02-22T01:00:06.963Z cpu0:65720)World: 2778: TR 0x4020 GDT 0x4391180a1000 (0x402f) IDT 0x418028d3f000 (0xfff)

2018-02-22T01:00:06.963Z cpu0:65720)World: 2779: CR0 0x80010031 CR3 0x17438a000 CR4 0x42768

[7m2018-02-22T01:00:07.025Z cpu0:65720)WARNING: kbdmode_set:519: invalid keyboard mode 4: Not supported [0m

2018-02-22T01:00:07.025Z cpu0:65720)Backtrace for current CPU #0, worldID=65720, fp=0x0

2018-02-22T01:00:07.025Z cpu0:65720)0x4390c5c1bc20:[0x418028ced531]PanicvPanicInt@vmkernel#nover+0x545 stack: 0x418028ced531, 0x0, 0x4390c5c1bcc8, 0x0, 0x128cd320d

2018-02-22T01:00:07.025Z cpu0:65720)0x4390c5c1bcc0:[0x418028ced5bd]Panic_NoSave@vmkernel#nover+0x4d stack: 0x4390c5c1bd20, 0x4390c5c1bce0, 0x0, 0x0, 0x100b8

2018-02-22T01:00:07.025Z cpu0:65720)0x4390c5c1bd20:[0x418028c22051]LockCheckSelfDeadlockInt@vmkernel#nover+0x95 stack: 0x418040000080, 0x418028cf6583, 0x188e3dfa00000000, 0x7ab9207249b2e, 0x439111127000

2018-02-22T01:00:07.025Z cpu0:65720)0x4390c5c1bd40:[0x418028cf6583]SP_WaitLockIRQ@vmkernel#nover+0x18b stack: 0x439111127000, 0x1, 0x418040000000, 0x7ab920724909e, 0x439111127280

2018-02-22T01:00:07.025Z cpu0:65720)0x4390c5c1bd90:[0x418028cf6616]SPLockIRQWork@vmkernel#nover+0x3e stack: 0x0, 0x418028ec6956, 0x4390cdf27100, 0x418040000138, 0x410000000001

2018-02-22T01:00:07.025Z cpu0:65720)0x4390c5c1bdb0:[0x418028ec6956]CpuSchedDispatch@vmkernel#nover+0x606 stack: 0x410000000001, 0x418040000080, 0x418040000108, 0x418040000120, 0x4390c07a7100

2018-02-22T01:00:07.025Z cpu0:65720)0x4390c5c1bee0:[0x418028ec8712]CpuSchedWait@vmkernel#nover+0x27a stack: 0x100418028cd1638, 0x7ab9207237cc6, 0x70000007d, 0x0, 0x0

2018-02-22T01:00:07.025Z cpu0:65720)0x4390c5c1bf60:[0x418028ec8896]CpuSchedSleepUntilTC@vmkernel#nover+0xaa stack: 0x439100002001, 0x3, 0x0, 0x100b8, 0x3

2018-02-22T01:00:07.025Z cpu0:65720)0x4390c5c1bfc0:[0x418028f60ec1]VSCSIPollCallback@vmkernel#nover+0x139 stack: 0x4390c5c27100, 0x418028ec93c5, 0x0, 0x0, 0x0

2018-02-22T01:00:07.025Z cpu0:65720)0x4390c5c1bfe0:[0x418028ec93c5]CpuSched_StartWorld@vmkernel#nover+0x99 stack: 0x0, 0x0, 0x0, 0x0, 0x0

2018-02-22T01:00:07.053Z cpu0:65720) [45m [33;1mVMware ESXi 6.5.0 [Releasebuild-7526125 x86_64] [0m

CPU 0 / World 65720 tried to re-acquire lock

2018-02-22T01:00:07.053Z cpu0:65720)cr0=0x8001003d cr2=0x43000095a000 cr3=0x7bdb1000 cr4=0x216c

2018-02-22T01:00:07.053Z cpu0:65720)pcpu:0 world:65720 name:"VSCSIPoll" (S)

2018-02-22T01:00:07.053Z cpu0:65720)pcpu:1 world:68133 name:"vmm2:Windows_10_Pro_NVR" (V)

2018-02-22T01:00:07.053Z cpu0:65720)pcpu:2 world:66003 name:"vmnic3-pollWorldnetpoll[07]" (S)

2018-02-22T01:00:07.053Z cpu0:65720)pcpu:3 world:68129 name:"vmm0:Windows_10_Pro_NVR" (V)

2018-02-22T01:00:07.053Z cpu0:65720)pcpu:4 world:68347 name:"vmm3:vcsa" (V)

2018-02-22T01:00:07.053Z cpu0:65720)pcpu:5 world:65716 name:"VSCSI Emulation Helper Queue-33-0" (SH)

2018-02-22T01:00:07.053Z cpu0:65720)pcpu:6 world:68132 name:"vmm1:Windows_10_Pro_NVR" (V)

2018-02-22T01:00:07.053Z cpu0:65720)pcpu:7 world:68345 name:"vmm1:vcsa" (V)

2018-02-22T01:00:07.053Z cpu0:65720)@BlueScreen: CPU 0 / World 65720 tried to re-acquire lock

2018-02-22T01:00:07.054Z cpu0:65720)Code start: 0x418028c00000 VMK uptime: 11:08:35:50.385

2018-02-22T01:00:07.054Z cpu0:65720)0x4390c5c1bc20:[0x418028ced531]PanicvPanicInt@vmkernel#nover+0x545 stack: 0x418028ced531

2018-02-22T01:00:07.054Z cpu0:65720)0x4390c5c1bcc0:[0x418028ced5bd]Panic_NoSave@vmkernel#nover+0x4d stack: 0x4390c5c1bd20

2018-02-22T01:00:07.055Z cpu0:65720)0x4390c5c1bd20:[0x418028c22051]LockCheckSelfDeadlockInt@vmkernel#nover+0x95 stack: 0x418040000080

2018-02-22T01:00:07.055Z cpu0:65720)0x4390c5c1bd40:[0x418028cf6583]SP_WaitLockIRQ@vmkernel#nover+0x18b stack: 0x439111127000

2018-02-22T01:00:07.055Z cpu0:65720)0x4390c5c1bd90:[0x418028cf6616]SPLockIRQWork@vmkernel#nover+0x3e stack: 0x0

2018-02-22T01:00:07.055Z cpu0:65720)0x4390c5c1bdb0:[0x418028ec6956]CpuSchedDispatch@vmkernel#nover+0x606 stack: 0x410000000001

2018-02-22T01:00:07.056Z cpu0:65720)0x4390c5c1bee0:[0x418028ec8712]CpuSchedWait@vmkernel#nover+0x27a stack: 0x100418028cd1638

2018-02-22T01:00:07.056Z cpu0:65720)0x4390c5c1bf60:[0x418028ec8896]CpuSchedSleepUntilTC@vmkernel#nover+0xaa stack: 0x439100002001

2018-02-22T01:00:07.056Z cpu0:65720)0x4390c5c1bfc0:[0x418028f60ec1]VSCSIPollCallback@vmkernel#nover+0x139 stack: 0x4390c5c27100

2018-02-22T01:00:07.057Z cpu0:65720)0x4390c5c1bfe0:[0x418028ec93c5]CpuSched_StartWorld@vmkernel#nover+0x99 stack: 0x0

2018-02-22T01:00:07.059Z cpu0:65720)base fs=0x0 gs=0x418040000000 Kgs=0x0

.....

[vijayrana968]

Have you configured NPIV?

[bateau59]

No, not anywhere on the host. The VM that is mentioned in the log has only standard local storage (dependent non-thin provisioned vmdk on vmfs 6 stores), not even RDM. It uses 2 different disks though, one on nvme, and one spinning SATA disk. LSI Logic SAS controller, not sharing. Now that I look at it, it is the only VM I have that uses that controller, the others are parallel or paravirtual. Not sure why I did that, or even if it was a deliberate choice. It is also the only Windows VM I have. Should I move to Paravirtual?