Update: If it matters, I tried loading a host with ESXi 5.5 u3b and
that also crashed the filer. Still waiting on an answer about the
applying of upstream commits to an OS like fedora or any other ideas
about the cause of this.
On Sun, Jan 24, 2016 at 8:11 PM, Roland Dreier <roland@xxxxxxxxxxxxxxx> wrote:
>> I have tried a large number of other hosts and they all act the same
>> way regardless of hardware. ESXi <6 is no problem, but 6 and newer
>> crash the filer very quickly.
>
> You're crashing because of
>
> Jan 24 10:02:09 dracofiler kernel: kernel BUG at
> drivers/scsi/qla2xxx/qla_target.c:3105!
>
> which is the BUG_ON in
>
> void qlt_free_cmd(struct qla_tgt_cmd *cmd)
> {
> struct qla_tgt_sess *sess = cmd->sess;
>
> ql_dbg(ql_dbg_tgt, cmd->vha, 0xe074,
> "%s: se_cmd[%p] ox_id %04x\n",
> __func__, &cmd->se_cmd,
> be16_to_cpu(cmd->atio.u.isp24.fcp_hdr.ox_id));
>
> BUG_ON(cmd->cmd_in_wq);
>
> It seems we're freeing a command before we process it.
>
> what logging do you have from target or qla2xxx before you hit the
> crash? I'm wondering why the initiator is aborting commands (although
> we still shouldn't crash even if it does abort commands).
>
> You could try applying upstream commit 193b50b9d54a ("qla2xxx: Replace
> QLA_TGT_STATE_ABORTED with a bit.") which seems like it might be
> related, though I'm not sure whether it really will help.
>
> - R.
--
To unsubscribe from this list: send the line "unsubscribe target-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
