[OmniOS-discuss] R151018: kernel panic when iSCSI target goes south

[Stephan Budach]

Hi Dan,

Am 25.04.16 um 16:23 schrieb Dan McDonald:
> This one is a NULL pointer dereference. If you're still running with kmem_flags = 0xf, the dump will be especially useful.
>
> Dan
>
> Sent from my iPhone (typos, autocorrect, and all)
>
>> On Apr 25, 2016, at 3:27 AM, Stephan Budach <stephan.budach at JVM.DE> wrote:
>>
>> Hi,
>>
>> I have been struck by kernel panics on my OmniOS boxes lateley, when any one of the target hosts, where the system get it's LUNs from, experiences a kernel panic itself. When this happens, my RSF-1 node immediately panics as well. Looking at the vmdump, it shows this:
>>
>> root at zfsha02gh79:/var/crash/unknown# mdb -k unix.0 vmcore.0
>> Loading modules: [ unix genunix specfs dtrace mac cpu.generic uppc apix scsi_vhci zfs sata sd ip hook neti sockfs arp usba stmf stmf_sbd mm md lofs random idm crypto cpc kvm ufs logindmux nsmb ptm smbsrv nfs ipc mpt mpt_sas pmcs emlxs ]
>>> ::status
>> debugging crash dump vmcore.0 (64-bit) from zfsha02gh79
>> operating system: 5.11 omnios-r151018-ae3141d (i86pc)
>> image uuid: 18d57565-8b91-46ea-9469-fb0518d35e30
>> panic message: BAD TRAP: type=e (#pf Page fault) rp=ffffff00f8b5e590 addr=10 occurred in module "scsi_vhci" due to a NULL pointer dereference
>> dump content: kernel pages only
>>> ::stack
>> vhci_scsi_reset_target+0x75(ffffff2c7b200b88, 1, 1)
>> vhci_recovery_reset+0x7d(ffffff2c7ac9d080, ffffff2c7b200b88, 1, 2)
>> vhci_pathinfo_offline+0xe5(ffffff21d3288550, ffffff2273530838, 0)
>> vhci_pathinfo_state_change+0xd5(ffffff21d3288550, ffffff2273530838, 4, 0, 0)
>> i_mdi_pi_state_change+0x16a(ffffff2273530838, 4, 0)
>> mdi_pi_offline+0x39(ffffff2273530838, 0)
>> iscsi_lun_offline+0xb3(ffffff21f1bd4580, ffffff2c084f5d60, 0)
>> iscsi_sess_offline_luns+0x4d(ffffff27fea82000)
>> iscsi_sess_state_failed+0x6f(ffffff27fea82000, 3, 2a)
>> iscsi_sess_state_machine+0x156(ffffff27fea82000, 3, 2a)
>> iscsi_login_end+0x18f(ffffff286c8d6000, 15, ffffff22724e1158)
>> iscsi_login_start+0x318(ffffff22724e1158)
>> taskq_thread+0x2d0(ffffff2270a7cb50)
>> thread_start+8()
>> The vmdump is really big, approx 5GB compressed, but I could share that if necessary.
>>
>> Thanks,
>> Stephan

I sure do, if you'd grant me an upload token, I will upload that zip 
file of 4GB. This will expand to a 18GB vmdump…

Cheers,
Stephan