The combination of 6664694 with the fix for 6357193
have exposed the fact that the scsi_sync_cache_pkt()
implementation does not adhere to the tran_sync_pkt(9E):
NOTES:
A target driver may call tran_sync_pkt() on packets for
which no DMA resources were allocated.
The result is a panic that looks like
panic[cpu0]/thread=ffffff000464fc80: assertion failed: (pkt->pkt_dma_flags &
0x0001) || (pkt->pkt_dma_flags & 0x0002), file:
../../common/io/scsi/impl/scsi_resource.c, line: 698
ffffff000464f780 genunix:assfail+7e ()
ffffff000464f7b0 scsi:scsi_sync_cache_pkt+67 ()
ffffff000464f7d0 scsi:scsi_sync_pkt+1d ()
ffffff000464f830 scsi:scsi_poll+1aa ()
ffffff000464f860 scsi_vhci:vhci_do_scsi_cmd+1c ()
ffffff000464f8f0 scsi_vhci:vhci_pathinfo_online+4ca ()
ffffff000464f980 scsi_vhci:vhci_pathinfo_state_change+72 ()
ffffff000464fa00 genunix:i_mdi_pi_state_change+377 ()
ffffff000464fa40 genunix:mdi_pi_online+39 ()
ffffff000464fae0 fcp:fcp_online_child+f3 ()
ffffff000464fb90 fcp:fcp_trigger_lun+280 ()
ffffff000464fbd0 fcp:fcp_hp_task+51 ()
ffffff000464fc60 genunix:taskq_thread+1cb ()
ffffff000464fc70 unix:thread_start+8 ()
On a scsi_pkt that looks like
[0]> ffffff01550e3b38::print struct scsi_pkt
{
pkt_ha_private = 0xffffff01550e3c08
pkt_address = {
a_hba_tran = 0xffffff01503cf800
a_target = 0
a_lun = 0
a_sublun = 0
}
pkt_private = 0
pkt_comp = 0
pkt_flags = 0
pkt_time = 0x3c
pkt_scbp = 0xffffff01550e9fe0
pkt_cdbp = 0xffffff01550e3c3c
pkt_resid = 0
pkt_state = 0x17
pkt_statistics = 0
pkt_reason = 0
pkt_cdblen = 0x6
pkt_tgtlen = 0
pkt_scblen = 0x20
pkt_handle = 0xffffff01550eb600
pkt_numcookies = 0
pkt_dma_offset = 0
pkt_dma_len = 0
pkt_dma_flags = 0
pkt_cookies = 0
}[0]> 0xffffff01550e3c3c,6/B
0xffffff01550e3c3c: 17 0 0 0 0 0
#define SCMD_RELEASE 0x17
This was missed in initial BFU-based testing of 6664694
due to the fact that base nwsnv bits were older, and did
not contain a the fix for 6357193.