have you checked this
http://www.vmware.com/support/vi3/doc/vi3_esx35u4_rel_notes.html#knownissues
see if anything is applicable to the cause of the panic.
If the core is not debuggable there is nothing we can do as it is a propeietory
os with some modification . VMware support is the one that needs to be actively involved.
May be this is applicable:
ESX Server hosts become unresponsive during a network broadcast storm
When a network broadcast storm occurs, ESX Servers might become unresponsive due to an issue with the tg3 network driver. During this time, service console or virtual machines that use the tg3 NIC might lose network connectivity. Rebooting the machine or unloading/loading the driver restores connectivity, but does not resolve the issue.
ESX hosts with tg3 port cannot send or receive packets after being subjected to a broadcast storm. The following error messages might be logged in VMkernel:
1. WARNING: Net: 1082: Rx storm on 1 queue 3501>3500, run 321>320
2. VMNIX: WARNING: NetCos: 1086: virtual HW appears wedged (bug number 90831), resetting
Core dumps are lost when multiple ESX hosts share a dump partition
If multiple ESX hosts that share a dump partition fail and save core dumps simultaneously, the core dumps might be lost.
what is the messages output ?
May be something bad with the hardware . Is it a VMware HA environment ?
Does the panic happen on all nodes ? and unable to debug the others ?
From what i see the core is not valid , Even with gdb you might get an unable to do anything
do you get any error when running
gdb do you get the core file is truncated
or
Cannot access memory at address 0x0 ??
We might not be able to do anything further without vmware support assistance.
is there a difference of the readelf -a output of the core files you generated and the bad core file
you are dealing with ?
