[PATCH] lpfc: fix build issue if NVME_FC_TARGET is not defined

[James Smart]

fix build issue if NVME_FC_TARGET is not defined. noop the code.
The code will never be invoked if target mode is not enabled.

Signed-off-by: Dick Kennedy 
Signed-off-by: James Smart 
---
 drivers/scsi/lpfc/lpfc_nvmet.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/scsi/lpfc/lpfc_nvmet.c b/drivers/scsi/lpfc/lpfc_nvmet.c
index 312f54278bd4..f94294b77b7b 100644
--- a/drivers/scsi/lpfc/lpfc_nvmet.c
+++ b/drivers/scsi/lpfc/lpfc_nvmet.c
@@ -157,6 +157,7 @@ lpfc_nvmet_xmt_ls_rsp_cmp(struct lpfc_hba *phba, struct 
lpfc_iocbq *cmdwqe,
 void
 lpfc_nvmet_ctxbuf_post(struct lpfc_hba *phba, struct lpfc_nvmet_ctxbuf 
*ctx_buf)
 {
+#if (IS_ENABLED(CONFIG_NVME_TARGET_FC))
struct lpfc_nvmet_rcv_ctx *ctxp = ctx_buf->context;
struct lpfc_nvmet_tgtport *tgtp;
struct fc_frame_header *fc_hdr;
@@ -260,6 +261,7 @@ lpfc_nvmet_ctxbuf_post(struct lpfc_hba *phba, struct 
lpfc_nvmet_ctxbuf *ctx_buf)
  >sli4_hba.lpfc_nvmet_ctx_list);
phba->sli4_hba.nvmet_ctx_cnt++;
spin_unlock_irqrestore(>sli4_hba.nvmet_io_lock, iflag);
+#endif
 }
 
 #ifdef CONFIG_SCSI_LPFC_DEBUG_FS
-- 
2.11.0

Re: [PATCH] scsi: libfc: fix incorrect variable assingment

[Martin K. Petersen]

Gustavo A.,

> Previous assignment was causing the use of the uninitialized variable
> _explan_ inside fc_seq_ls_rjt() function, which in this particular
> case is being called by fc_seq_els_rsp_send().

Applied to 4.12/scsi-fixes. Thanks!

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH v4] sd: Ignore sync cache failures when not supported

[Martin K. Petersen]

Thierry,

> Some external hard drives don't support the sync command even though
> the hard drive has write cache enabled. In this case, upon suspend
> request, sync cache failures are ignored if the error code in the
> sense header is ILLEGAL_REQUEST. There's not much we can do for these
> drives, so we shouldn't fail to suspend for this error case. The drive
> may stay powered if that's the setup for the port it's plugged into.

Applied to 4.12/scsi-fixes, thanks!

-- 
Martin K. Petersen  Oracle Linux Engineering

[PATCH] ibmvscsis: Enable Logical Partition Migration Support

[Bryant G. Ly]

From: Michael Cyr 

Changes to support a new mechanism from phyp to better synchronize the
logical partition migration (LPM) of the client partition.
This includes a new VIOCTL to register that we support this new
functionality, and 2 new Transport Event types, and finally another
new VIOCTL to let phyp know once we're ready for the Suspend.

Signed-off-by: Michael Cyr 
Signed-off-by: Bryant G. Ly 
---
 drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c | 148 ---
 drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.h |  25 +-
 drivers/scsi/ibmvscsi_tgt/libsrp.h   |   5 +-
 3 files changed, 162 insertions(+), 16 deletions(-)

diff --git a/drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c 
b/drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c
index 7a45ac0..361773f 100644
--- a/drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c
+++ b/drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c
@@ -154,6 +154,9 @@ static long ibmvscsis_unregister_command_q(struct scsi_info 
*vscsi)
qrc = h_free_crq(vscsi->dds.unit_id);
switch (qrc) {
case H_SUCCESS:
+   spin_lock_bh(>intr_lock);
+   vscsi->flags &= ~PREP_FOR_SUSPEND_FLAGS;
+   spin_unlock_bh(>intr_lock);
break;
 
case H_HARDWARE:
@@ -421,6 +424,9 @@ static void ibmvscsis_disconnect(struct work_struct *work)
new_state = vscsi->new_state;
vscsi->new_state = 0;
 
+   vscsi->flags |= DISCONNECT_SCHEDULED;
+   vscsi->flags &= ~SCHEDULE_DISCONNECT;
+
pr_debug("disconnect: flags 0x%x, state 0x%hx\n", vscsi->flags,
 vscsi->state);
 
@@ -801,6 +807,13 @@ static long ibmvscsis_establish_new_q(struct scsi_info 
*vscsi)
long rc = ADAPT_SUCCESS;
uint format;
 
+   rc = h_vioctl(vscsi->dds.unit_id, H_ENABLE_PREPARE_FOR_SUSPEND, 3,
+ 0, 0, 0, 0);
+   if (rc == H_SUCCESS)
+   vscsi->flags |= PREP_FOR_SUSPEND_ENABLED;
+   else if (rc != H_NOT_FOUND)
+   pr_err("Error from Enable Prepare for Suspend: %ld\n", rc);
+
vscsi->flags &= PRESERVE_FLAG_FIELDS;
vscsi->rsp_q_timer.timer_pops = 0;
vscsi->debit = 0;
@@ -950,6 +963,63 @@ static void ibmvscsis_free_cmd_resources(struct scsi_info 
*vscsi,
 }
 
 /**
+ * ibmvscsis_ready_for_suspend() - Helper function to call VIOCTL
+ * @vscsi: Pointer to our adapter structure
+ * @idle:  Indicates whether we were called from adapter_idle.  This
+ * is important to know if we need to do a disconnect, since if
+ * we're called from adapter_idle, we're still processing the
+ * current disconnect, so we can't just call post_disconnect.
+ *
+ * This function is called when the adapter is idle when phyp has sent
+ * us a Prepare for Suspend Transport Event.
+ *
+ * EXECUTION ENVIRONMENT:
+ * Process or interrupt environment called with interrupt lock held
+ */
+static long ibmvscsis_ready_for_suspend(struct scsi_info *vscsi, bool idle)
+{
+   long rc = 0;
+   struct viosrp_crq *crq;
+
+   /* See if there is a Resume event in the queue */
+   crq = vscsi->cmd_q.base_addr + vscsi->cmd_q.index;
+
+   pr_debug("ready_suspend: flags 0x%x, state 0x%hx crq_valid:%x\n",
+vscsi->flags, vscsi->state, (int)crq->valid);
+
+   if (!(vscsi->flags & PREP_FOR_SUSPEND_ABORTED) && !(crq->valid)) {
+   rc = h_vioctl(vscsi->dds.unit_id, H_READY_FOR_SUSPEND, 0, 0, 0,
+ 0, 0);
+   if (rc) {
+   pr_err("Ready for Suspend Vioctl failed: %ld\n", rc);
+   rc = 0;
+   }
+   } else if (((vscsi->flags & PREP_FOR_SUSPEND_OVERWRITE) &&
+   (vscsi->flags & PREP_FOR_SUSPEND_ABORTED)) ||
+  ((crq->valid) && ((crq->valid != VALID_TRANS_EVENT) ||
+(crq->format != RESUME_FROM_SUSP {
+   if (idle) {
+   vscsi->state = ERR_DISCONNECT_RECONNECT;
+   ibmvscsis_reset_queue(vscsi);
+   rc = -1;
+   } else if (vscsi->state == CONNECTED) {
+   ibmvscsis_post_disconnect(vscsi,
+ ERR_DISCONNECT_RECONNECT, 0);
+   }
+
+   vscsi->flags &= ~PREP_FOR_SUSPEND_OVERWRITE;
+
+   if ((crq->valid) && ((crq->valid != VALID_TRANS_EVENT) ||
+(crq->format != RESUME_FROM_SUSP)))
+   pr_err("Invalid element in CRQ after Prepare for 
Suspend");
+   }
+
+   vscsi->flags &= ~(PREP_FOR_SUSPEND_PENDING | PREP_FOR_SUSPEND_ABORTED);
+
+   return rc;
+}
+
+/**
  * ibmvscsis_trans_event() - Handle a Transport Event
  * @vscsi: Pointer to our adapter structure
  * @crq:   

[Bug 195763] 4.12-rc1 fails to build

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=195763

Richard Narron (comet.berke...@gmail.com) changed:

   What|Removed |Added

 CC||linux-scsi@vger.kernel.org

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Re: [ANNOUNCE]: Broadcom (Emulex) FC Target driver - efct

[Roland Dreier]

On Sun, Mar 5, 2017 at 8:35 AM, Sebastian Herbszt  wrote:
> Just like Hannes I do favour integration. I guess it could be
> comparable to qla2xxx + tcm_qla2xxx, lpfc + lpfc_scst and
> lpfc + tcm_lpfc. That approach might even help Bart with his
> target driver unification if he didn't give up on that topic.

Resurrecting this old topic - sorry for not seeing this go by initially.

For context, I have a lot of experience debugging the qla2xxx target
code - we did a lot of work to get error/exception paths correct.
Basic FC target support is pretty straightforward but handling SAN log
in / log out events and other strange things that initiators do took a
lot of effort.

Anyway, my feeling is that the integration of tcm_qla2xxx and qla2xxx
was overall a net negative.  Having the target driver grafted onto the
side of an already-complex driver that has a bunch of code not
relevant to the target (SCSI error handling, logging into and timing
out remote target ports, etc) made the code harder to debug and harder
to get right.

Of course I'm in favor of making common code really common.  So
certainly we should have a common library of SLI-4 code that both the
initiator and target driver share.  And if there is more commonality,
that's great.  But any code similar to "if (initiator) ... else ..."
is really suspect to me - grepping for "qla_ini_mode_enabled" shows
great examples like

if (fcport->scan_state == QLA_FCPORT_SCAN) {
if ((qla_dual_mode_enabled(vha) ||
qla_ini_mode_enabled(vha)) &&
atomic_read(>state) == FCS_ONLINE) {
qla2x00_mark_device_lost(vha, fcport,
ql2xplogiabsentdevice, 0);
if (fcport->loop_id != FC_NO_LOOP_ID &&
(fcport->flags & FCF_FCP2_DEVICE) == 0 &&
fcport->port_type != FCT_INITIATOR &&
fcport->port_type != FCT_BROADCAST) {
ql_dbg(ql_dbg_disc, vha, 0x,
"%s %d %8phC post del sess\n",
__func__, __LINE__,
fcport->port_name);

qlt_schedule_sess_for_deletion_lock
(fcport);
continue;
}
}
}

Handling "dual mode" (both initiator and target on the same port at
the same time) is a design challenge, but I don't think the current
qla2xxx driver is an example of a maintainable way to do that.

(I'm agnostic about what to do about SLI-3 - perhaps the cleanest
thing to do is split the driver between SLI-4 and SLI-3, and handle
the initiator and target drivers for those two cases as appropriate)

I'd love to discuss this further and come up with a design that meets
the concerns about integration but also learns the lessons from
tcm_qla2xxx.

 - R.

Attn Beneficiary,

[Mrs. Linda Jones]

Attn Beneficiary,

We have deposited the check of your fund ($2.5m USD) through western union 
money transfer
department after our finally meeting today regarding your fund, Now all you
will do is to contact western union director Mis Rose Kelly  ,And She will give 
you
the direction on how you will be receiving your funds daily. Remember to send
her your Full information to avoid wrong transfer such as,

Your Receiver Name--­
Your Country­
Your City---­
Your Phone No---­
Your Address­
Your Id card or pasport :...

Therefore you are advised to contact western union accountant Manager 
 to her bellow information and tell She to give you the Mtcn, sender name
and question/answer to pick the money,

CONTACT Name: Mis Rose Kelly reply to (  wstun.office...@gmail.com  )
Phone: +229-99374614 


Get back to us once you receive your total fund of $2.5m.
Thanks and God bless you.

Best Regards
WESTERN UNION AGENT

Re: [RFC] scsi: generate uevent for SCSI sense code

[Song Liu]

> On May 16, 2017, at 10:00 AM, Benjamin Block  
> wrote:
> 
> Hello,
> 
> On Wed, May 03, 2017 at 05:50:13PM -0700, Song Liu wrote:
>> This patch adds capability for SCSI layer to generate uevent for SCSI
>> sense code. The feature is gated by CONFIG_SCSI_SENSE_UEVENT.
>> 
>> We can configure which sense keys generate uevent for each device
>> through sysfs entry sense_event_filter. For example, the following
>> enables uevent for MEDIUM_ERROR (0x03) and HARDWARE_ERROR (0x04)
>> on scsi drive sdc:
>> 
>>echo 0x000c > /sys/block/sdc/device/sense_event_filter
>> 
> 
> I know its an RFC, but the user-interface definitely needs better
> documentation. You also don't mention the 'wildcard' you document in the
> code below.
> 
> Would there be any public tooling for this, when it gets in?
> 
> There is already some events we can generate.. for example when the
> host-mapping changed, but I am not aware of any tooling that would ever
> make use of them (although, this probably would even be vert useful).
> And in the end that seems like dead-code for me. But maybe thats just me
> not knowing the tooling.

Hi Benjamin, 

Thanks for these feedbacks. I will incorporate them into next version. 

In term of tooling, we will open source useful tools we build to consume
these events.  

>> 
>> Here is an example output captured by udevadm:
>> 
>> KERNEL[1214.945358] change   /devices/pci:00/XXX
>> ACTION=change
>> DEVPATH=/devices/pci:00/:00:01.0/:01:00.0/host6/XXX
>> DEVTYPE=scsi_device
>> DRIVER=sd
>> LBA=0
>> MODALIAS=scsi:t-0x00
>> SDEV_UA=SCSI_SENSE
>> SENSE_CODE=3/11/14
>> SEQNUM=4536
>> SIZE=4096
>> SUBSYSTEM=scsi
>> 
>> Signed-off-by: Song Liu 
>> ---
>> drivers/scsi/Kconfig   | 14 +++
>> drivers/scsi/scsi_error.c  | 26 
>> drivers/scsi/scsi_lib.c| 27 +++--
>> drivers/scsi/scsi_sysfs.c  | 60 
>> ++
>> include/scsi/scsi_device.h | 26 +++-
>> 5 files changed, 150 insertions(+), 3 deletions(-)
>> 
>> diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
>> index 3c52867..4f7f211 100644
>> --- a/drivers/scsi/Kconfig
>> +++ b/drivers/scsi/Kconfig
>> @@ -237,6 +237,20 @@ config SCSI_LOGGING
>>there should be no noticeable performance impact as long as you have
>>logging turned off.
>> 
>> +config SCSI_SENSE_UEVENT
>> +bool "SCSI sense code logging"
>> +depends on SCSI
>> +default n
>> +---help---
>> +  This turns on uevent for SCSI sense code.
>> +
>> +  You can configure which sense keys generate uevent for each device
>> +  through sysfs entry sense_event_filter. For example, the following
>> +  enables uevent for MEDIUM_ERROR (0x03) and HARDWARE_ERROR (0x04)
>> +  on scsi drive sdc:
>> +
>> +  echo 0x000c > /sys/block/sdc/device/sense_event_filter
>> +
>> config SCSI_SCAN_ASYNC
>>  bool "Asynchronous SCSI scanning"
>>  depends on SCSI
>> diff --git a/drivers/scsi/scsi_error.c b/drivers/scsi/scsi_error.c
>> index d70c67c..eda150e 100644
>> --- a/drivers/scsi/scsi_error.c
>> +++ b/drivers/scsi/scsi_error.c
>> @@ -426,6 +426,31 @@ static void scsi_report_sense(struct scsi_device *sdev,
>>  }
>> }
>> 
>> +/*
>> + * generate uevent when receiving sense code from device
>> + */
>> +static void scsi_send_sense_uevent(struct scsi_device *sdev,
>> +   struct scsi_cmnd *scmd,
>> +   struct scsi_sense_hdr *sshdr)
>> +{
>> +#ifdef CONFIG_SCSI_SENSE_UEVENT
>> +struct scsi_event *evt;
>> +
>> +if (!test_bit(sshdr->sense_key & 0xf,
>> +  >sense_event_filter))
>> +return;
>> +evt = sdev_evt_alloc(SDEV_EVT_SCSI_SENSE, GFP_ATOMIC);
>> +if (!evt)
>> +return;
>> +
>> +evt->sense_evt_data.lba = scsi_get_lba(scmd);
>> +evt->sense_evt_data.size = blk_rq_bytes(scmd->request);
>> +memcpy(>sense_evt_data.sshdr, sshdr,
>> +   sizeof(struct scsi_sense_hdr));
>> +sdev_evt_send(sdev, evt);
>> +#endif
>> +}
>> +
> 
> So when I turn this CONFIG_ off, do I get all kinds of warning about
> unused variables?

I don't get any warning at this time. I will keep testing w/ and w/o
the config enabled. 

Thanks,
Song

RE: Donation

[Bamasi, Benafsha]

From: Bamasi, Benafsha
Sent: Tuesday, May 16, 2017 2:56 PM
Subject: Donation

I am terry Jones , Mrs Gloria Mackenzie is donating 700,000$ contact her 
through her personal email 
(gloriaz...@hotmail.com)

Re: A bug in scsi_alloc_target of drivers/scsi/scsi_scan.c

[Benjamin Block]

Hello Dashi,

On Tue, May 09, 2017 at 09:08:14AM +, Dashi DS1 Cao wrote:
> When debugging a race condition in scsi_remove_target of 3.12, I ran into 
> this possible bug within scsi_alloc_target.
> When an existing "struct scsi_target" is found and used, the starget just got 
> through kzmalloc should be freed, rather than dong a "put_device(dev)".

But that is exactly what is done when put_device is called and the
internal ref-count drops below 1. It will go through the kobj-core and
end up in scsi_target_dev_release().

Also this specific code was changed in 12fb8c1574d7d in 2010, see the
commit message there.

Beste Grüße / Best regards,
  - Benjamin Block
> 
> diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c
> index 81d4151..96795d4 100644
> --- a/drivers/scsi/scsi_scan.c
> +++ b/drivers/scsi/scsi_scan.c
> @@ -483,7 +483,7 @@ static struct scsi_target *scsi_alloc_target(struct 
> device *parent,
> 
> spin_unlock_irqrestore(shost->host_lock, flags);
> if (ref_got) {
> -   put_device(dev);
> +   kfree(starget);
> return found_target;
> }
> /*
> --
> 
> Dashi Cao
> 
-- 
Linux on z Systems Development / IBM Systems & Technology Group
  IBM Deutschland Research & Development GmbH 
Vorsitz. AufsR.: Martina Koederitz /Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen / Registergericht: AmtsG Stuttgart, HRB 243294

RE: [PATCH] scsi: zero per-cmd driver data for each MQ I/O

[Long Li]

> -Original Message-
> From: Bart Van Assche [mailto:bart.vanass...@sandisk.com]
> Sent: Monday, May 15, 2017 5:01 PM
> To: j...@linux.vnet.ibm.com; linux-scsi@vger.kernel.org; linux-
> ker...@vger.kernel.org; Long Li ;
> martin.peter...@oracle.com
> Cc: Stephen Hemminger ; KY Srinivasan
> 
> Subject: Re: [PATCH] scsi: zero per-cmd driver data for each MQ I/O
> 
> On Mon, 2017-05-15 at 23:32 +, Long Li wrote:
> > Thanks for looking! Yes this is for chasing a bug.
> >
> > With the patch, we also zero the private data used by lower layer
> > driver, in addition to the private data in scsi_cmnd.
> 
> Hello Long,
> 
> What bug did you encounter, with which combination of ULP (sd?) and LLD SCSI
> driver(s) and for which request type (REQ_OP_*)? You will have to mention
> that information in the patch description anyway if you want your patch to get
> accepted.
> 
> If the bug that you encountered only occurs with a single LLD, would it be
> possible to implement a fix by modifying the LLD instead of the SCSI core?

The bug I encounter is that in hv_storvsc (a LLD), sometime we are getting 
stale data in the private driver data memory allocated by SCSI. As a LLD, we 
expect the memory allocated by SCSI to be zeroed. If not we may send unexpected 
commands to the device.

A little background on private data: In LLD's scsi_host_template, the driver 
may optionally ask SCSI to allocate its private driver memory for each command, 
by specifying cmd_size. This memory is allocated at the end of scsi_cmnd by 
SCSI. Later when SCSI queues a command, the LLD can use scsi_cmd_priv to get 
its private data.

hv_storvsc doesn't clear its private data before use. I'm not sure about other 
LLD drivers. Although it's possible to fix it in LLD not SCSI core, I think 
that is not the ideal place to do it. Whoever is allocating the SCSI command 
should also zero it.

There is a similar patch that fixed a similar issue for non-MQ case:
commit ee5242360424b9b967454e9183767323d10cf985

I'm sorry I should have put more details in the patch. 

> 
> Thanks,
> 
> Bart.

Re: [RFC] scsi: generate uevent for SCSI sense code

[Benjamin Block]

Hello,

On Wed, May 03, 2017 at 05:50:13PM -0700, Song Liu wrote:
> This patch adds capability for SCSI layer to generate uevent for SCSI
> sense code. The feature is gated by CONFIG_SCSI_SENSE_UEVENT.
>
> We can configure which sense keys generate uevent for each device
> through sysfs entry sense_event_filter. For example, the following
> enables uevent for MEDIUM_ERROR (0x03) and HARDWARE_ERROR (0x04)
> on scsi drive sdc:
>
> echo 0x000c > /sys/block/sdc/device/sense_event_filter
>

I know its an RFC, but the user-interface definitely needs better
documentation. You also don't mention the 'wildcard' you document in the
code below.

Would there be any public tooling for this, when it gets in?

There is already some events we can generate.. for example when the
host-mapping changed, but I am not aware of any tooling that would ever
make use of them (although, this probably would even be vert useful).
And in the end that seems like dead-code for me. But maybe thats just me
not knowing the tooling.

>
> Here is an example output captured by udevadm:
>
> KERNEL[1214.945358] change   /devices/pci:00/XXX
> ACTION=change
> DEVPATH=/devices/pci:00/:00:01.0/:01:00.0/host6/XXX
> DEVTYPE=scsi_device
> DRIVER=sd
> LBA=0
> MODALIAS=scsi:t-0x00
> SDEV_UA=SCSI_SENSE
> SENSE_CODE=3/11/14
> SEQNUM=4536
> SIZE=4096
> SUBSYSTEM=scsi
>
> Signed-off-by: Song Liu 
> ---
>  drivers/scsi/Kconfig   | 14 +++
>  drivers/scsi/scsi_error.c  | 26 
>  drivers/scsi/scsi_lib.c| 27 +++--
>  drivers/scsi/scsi_sysfs.c  | 60 
> ++
>  include/scsi/scsi_device.h | 26 +++-
>  5 files changed, 150 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
> index 3c52867..4f7f211 100644
> --- a/drivers/scsi/Kconfig
> +++ b/drivers/scsi/Kconfig
> @@ -237,6 +237,20 @@ config SCSI_LOGGING
> there should be no noticeable performance impact as long as you have
> logging turned off.
>
> +config SCSI_SENSE_UEVENT
> + bool "SCSI sense code logging"
> + depends on SCSI
> + default n
> + ---help---
> +   This turns on uevent for SCSI sense code.
> +
> +   You can configure which sense keys generate uevent for each device
> +   through sysfs entry sense_event_filter. For example, the following
> +   enables uevent for MEDIUM_ERROR (0x03) and HARDWARE_ERROR (0x04)
> +   on scsi drive sdc:
> +
> +   echo 0x000c > /sys/block/sdc/device/sense_event_filter
> +
>  config SCSI_SCAN_ASYNC
>   bool "Asynchronous SCSI scanning"
>   depends on SCSI
> diff --git a/drivers/scsi/scsi_error.c b/drivers/scsi/scsi_error.c
> index d70c67c..eda150e 100644
> --- a/drivers/scsi/scsi_error.c
> +++ b/drivers/scsi/scsi_error.c
> @@ -426,6 +426,31 @@ static void scsi_report_sense(struct scsi_device *sdev,
>   }
>  }
>
> +/*
> + * generate uevent when receiving sense code from device
> + */
> +static void scsi_send_sense_uevent(struct scsi_device *sdev,
> +struct scsi_cmnd *scmd,
> +struct scsi_sense_hdr *sshdr)
> +{
> +#ifdef CONFIG_SCSI_SENSE_UEVENT
> + struct scsi_event *evt;
> +
> + if (!test_bit(sshdr->sense_key & 0xf,
> +   >sense_event_filter))
> + return;
> + evt = sdev_evt_alloc(SDEV_EVT_SCSI_SENSE, GFP_ATOMIC);
> + if (!evt)
> + return;
> +
> + evt->sense_evt_data.lba = scsi_get_lba(scmd);
> + evt->sense_evt_data.size = blk_rq_bytes(scmd->request);
> + memcpy(>sense_evt_data.sshdr, sshdr,
> +sizeof(struct scsi_sense_hdr));
> + sdev_evt_send(sdev, evt);
> +#endif
> +}
> +

So when I turn this CONFIG_ off, do I get all kinds of warning about
unused variables?

>  /**
>   * scsi_check_sense - Examine scsi cmd sense
>   * @scmd:Cmd to have sense checked.
> @@ -446,6 +471,7 @@ int scsi_check_sense(struct scsi_cmnd *scmd)
>   return FAILED;  /* no valid sense data */
>
>   scsi_report_sense(sdev, );
> + scsi_send_sense_uevent(sdev, scmd, );
>
>   if (scsi_sense_is_deferred())
>   return NEEDS_RETRY;
> diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
> index 95f963b..1095f27 100644
> --- a/drivers/scsi/scsi_lib.c
> +++ b/drivers/scsi/scsi_lib.c
> @@ -2656,8 +2656,9 @@ EXPORT_SYMBOL(scsi_device_set_state);
>   */
>  static void scsi_evt_emit(struct scsi_device *sdev, struct scsi_event *evt)
>  {
> - int idx = 0;
> - char *envp[3];
> + int idx = 0, i;
> + char *envp[5];  /* SDEV_EVT_SCSI_SENSE needs most entries (4) */
> + int free_envp = -1;
>
>   switch (evt->evt_type) {
>   case SDEV_EVT_MEDIA_CHANGE:
> @@ -2682,6 +2683,23 @@ static void scsi_evt_emit(struct scsi_device *sdev, 
> struct scsi_event *evt)
>   case SDEV_EVT_ALUA_STATE_CHANGE_REPORTED:
>   envp[idx++] = 

[Bug 195285] qla2xxx FW immediatly crashing after target start

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=195285

--- Comment #5 from lober...@redhat.com ---
- Original Message -
> From: bugzilla-dae...@bugzilla.kernel.org
> To: linux-s...@kernel.org
> Sent: Tuesday, May 16, 2017 10:45:22 AM
> Subject: [Bug 195285] qla2xxx FW immediatly crashing after target start
> 
> https://bugzilla.kernel.org/show_bug.cgi?id=195285
> 
> --- Comment #4 from Anthony (anthony.blood...@gmail.com) ---
> I'm trying to select working setting, and some investigation shows:
> with parameter ql2xmqsupport=0 - target starting to work
> 
> --
> You are receiving this mail because:
> You are watching the assignee of the bug.
> 
OK, I default to MQ so will look at testing without it later.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

Re: [PATCH] scsi: sg: Fix mismatch in sg_get_rq_mark

[Andrey Konovalov]

On Tue, May 16, 2017 at 4:52 PM,   wrote:
> From: Firo Yang 
>
> This bug was reported by Andrey Konovalov with syzkaller:
>
> Call Trace:
>  sg_finish_rem_req+0x2a6/0x320 drivers/scsi/sg.c:1839
>  sg_new_read+0x3c/0x430 drivers/scsi/sg.c:567
>  sg_read+0x866/0x1830 drivers/scsi/sg.c:455
>  __vfs_read+0x5c3/0x750 fs/read_write.c:450
>  vfs_read+0x11e/0x350 fs/read_write.c:473
>  SYSC_read fs/read_write.c:589
>  SyS_read+0xfb/0x230 fs/read_write.c:582
>  entry_SYSCALL_64_fastpath+0x1f/0xbe arch/x86/entry/entry_64.S:204
>
> If there is nothing matched in the loop of list_for_each_entry,
> at last the iteration variable 'resp' will point to
> list_entry(>rq_list, typeof(resp), entry); it's not a valid
> Sg_request. Finnally, 'resp' will be wrongly returned to the caller
> function.
>
> To fix it, add another return variable to record the correct
> match and return it to the caller function.

I think this was already fixed by https://lkml.org/lkml/2017/5/10/83

Thanks!

>
> Signed-off-by: Firo Yang 
> ---
>  drivers/scsi/sg.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/scsi/sg.c b/drivers/scsi/sg.c
> index 0a38ba0..74a9188 100644
> --- a/drivers/scsi/sg.c
> +++ b/drivers/scsi/sg.c
> @@ -2065,7 +2065,7 @@ sg_unlink_reserve(Sg_fd * sfp, Sg_request * srp)
>  static Sg_request *
>  sg_get_rq_mark(Sg_fd * sfp, int pack_id)
>  {
> -   Sg_request *resp;
> +   Sg_request *resp, *ret_resp = NULL;
> unsigned long iflags;
>
> write_lock_irqsave(>rq_list_lock, iflags);
> @@ -2074,11 +2074,12 @@ sg_get_rq_mark(Sg_fd * sfp, int pack_id)
> if ((1 == resp->done) && (!resp->sg_io_owned) &&
> ((-1 == pack_id) || (resp->header.pack_id == pack_id))) {
> resp->done = 2; /* guard against other readers */
> +   ret_resp =  resp;
> break;
> }
> }
> write_unlock_irqrestore(>rq_list_lock, iflags);
> -   return resp;
> +   return ret_resp;
>  }
>
>  /* always adds to end of list */
> --
> 2.9.4
>
> --
> You received this message because you are subscribed to the Google Groups 
> "syzkaller" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to syzkaller+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[PATCH] scsi: sg: Fix mismatch in sg_get_rq_mark

[firogm]

From: Firo Yang 

This bug was reported by Andrey Konovalov with syzkaller:

Call Trace:
 sg_finish_rem_req+0x2a6/0x320 drivers/scsi/sg.c:1839
 sg_new_read+0x3c/0x430 drivers/scsi/sg.c:567
 sg_read+0x866/0x1830 drivers/scsi/sg.c:455
 __vfs_read+0x5c3/0x750 fs/read_write.c:450
 vfs_read+0x11e/0x350 fs/read_write.c:473
 SYSC_read fs/read_write.c:589
 SyS_read+0xfb/0x230 fs/read_write.c:582
 entry_SYSCALL_64_fastpath+0x1f/0xbe arch/x86/entry/entry_64.S:204

If there is nothing matched in the loop of list_for_each_entry,
at last the iteration variable 'resp' will point to
list_entry(>rq_list, typeof(resp), entry); it's not a valid
Sg_request. Finnally, 'resp' will be wrongly returned to the caller
function.

To fix it, add another return variable to record the correct
match and return it to the caller function.

Signed-off-by: Firo Yang 
---
 drivers/scsi/sg.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/sg.c b/drivers/scsi/sg.c
index 0a38ba0..74a9188 100644
--- a/drivers/scsi/sg.c
+++ b/drivers/scsi/sg.c
@@ -2065,7 +2065,7 @@ sg_unlink_reserve(Sg_fd * sfp, Sg_request * srp)
 static Sg_request *
 sg_get_rq_mark(Sg_fd * sfp, int pack_id)
 {
-   Sg_request *resp;
+   Sg_request *resp, *ret_resp = NULL;
unsigned long iflags;
 
write_lock_irqsave(>rq_list_lock, iflags);
@@ -2074,11 +2074,12 @@ sg_get_rq_mark(Sg_fd * sfp, int pack_id)
if ((1 == resp->done) && (!resp->sg_io_owned) &&
((-1 == pack_id) || (resp->header.pack_id == pack_id))) {
resp->done = 2; /* guard against other readers */
+   ret_resp =  resp;
break;
}
}
write_unlock_irqrestore(>rq_list_lock, iflags);
-   return resp;
+   return ret_resp;
 }
 
 /* always adds to end of list */
-- 
2.9.4

[Bug 195285] qla2xxx FW immediatly crashing after target start

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=195285

--- Comment #4 from Anthony (anthony.blood...@gmail.com) ---
I'm trying to select working setting, and some investigation shows:
with parameter ql2xmqsupport=0 - target starting to work

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[PATCH] scsi: libcxgbi: fix skb use after free

[Varun Prakash]

skb->data is assigned to task->hdr in cxgbi_conn_alloc_pdu(),
skb gets freed after tx but task->hdr is still dereferenced
in iscsi_tcp_task_xmit() to avoid this call skb_get() after
allocating skb and free the skb in cxgbi_cleanup_task() or
before allocating new skb in cxgbi_conn_alloc_pdu().

Signed-off-by: Varun Prakash 
---
 drivers/scsi/cxgbi/libcxgbi.c | 25 ++---
 drivers/scsi/cxgbi/libcxgbi.h | 16 
 2 files changed, 26 insertions(+), 15 deletions(-)

diff --git a/drivers/scsi/cxgbi/libcxgbi.c b/drivers/scsi/cxgbi/libcxgbi.c
index bd7d39e..fb06974 100644
--- a/drivers/scsi/cxgbi/libcxgbi.c
+++ b/drivers/scsi/cxgbi/libcxgbi.c
@@ -1873,6 +1873,11 @@ int cxgbi_conn_alloc_pdu(struct iscsi_task *task, u8 
opcode)
tcp_task->dd_data = tdata;
task->hdr = NULL;
 
+   if (tdata->skb) {
+   kfree_skb(tdata->skb);
+   tdata->skb = NULL;
+   }
+
if (SKB_MAX_HEAD(cdev->skb_tx_rsvd) > (512 * MAX_SKB_FRAGS) &&
(opcode == ISCSI_OP_SCSI_DATA_OUT ||
 (opcode == ISCSI_OP_SCSI_CMD &&
@@ -1890,6 +1895,7 @@ int cxgbi_conn_alloc_pdu(struct iscsi_task *task, u8 
opcode)
return -ENOMEM;
}
 
+   skb_get(tdata->skb);
skb_reserve(tdata->skb, cdev->skb_tx_rsvd);
task->hdr = (struct iscsi_hdr *)tdata->skb->data;
task->hdr_max = SKB_TX_ISCSI_PDU_HEADER_MAX; /* BHS + AHS */
@@ -2035,9 +2041,9 @@ int cxgbi_conn_xmit_pdu(struct iscsi_task *task)
unsigned int datalen;
int err;
 
-   if (!skb) {
+   if (!skb || cxgbi_skcb_test_flag(skb, SKCBF_TX_DONE)) {
log_debug(1 << CXGBI_DBG_ISCSI | 1 << CXGBI_DBG_PDU_TX,
-   "task 0x%p, skb NULL.\n", task);
+   "task 0x%p, skb 0x%p\n", task, skb);
return 0;
}
 
@@ -2050,7 +2056,6 @@ int cxgbi_conn_xmit_pdu(struct iscsi_task *task)
}
 
datalen = skb->data_len;
-   tdata->skb = NULL;
 
/* write ppod first if using ofldq to write ppod */
if (ttinfo->flags & CXGBI_PPOD_INFO_FLAG_VALID) {
@@ -2078,6 +2083,7 @@ int cxgbi_conn_xmit_pdu(struct iscsi_task *task)
pdulen += ISCSI_DIGEST_SIZE;
 
task->conn->txdata_octets += pdulen;
+   cxgbi_skcb_set_flag(skb, SKCBF_TX_DONE);
return 0;
}
 
@@ -2086,7 +2092,6 @@ int cxgbi_conn_xmit_pdu(struct iscsi_task *task)
"task 0x%p, skb 0x%p, len %u/%u, %d EAGAIN.\n",
task, skb, skb->len, skb->data_len, err);
/* reset skb to send when we are called again */
-   tdata->skb = skb;
return err;
}
 
@@ -2094,7 +2099,8 @@ int cxgbi_conn_xmit_pdu(struct iscsi_task *task)
"itt 0x%x, skb 0x%p, len %u/%u, xmit err %d.\n",
task->itt, skb, skb->len, skb->data_len, err);
 
-   kfree_skb(skb);
+   __kfree_skb(tdata->skb);
+   tdata->skb = NULL;
 
iscsi_conn_printk(KERN_ERR, task->conn, "xmit err %d.\n", err);
iscsi_conn_failure(task->conn, ISCSI_ERR_XMIT_FAILED);
@@ -2113,8 +2119,10 @@ void cxgbi_cleanup_task(struct iscsi_task *task)
 
tcp_task->dd_data = NULL;
/*  never reached the xmit task callout */
-   if (tdata->skb)
-   __kfree_skb(tdata->skb);
+   if (tdata->skb) {
+   kfree_skb(tdata->skb);
+   tdata->skb = NULL;
+   }
 
task_release_itt(task, task->hdr_itt);
memset(tdata, 0, sizeof(*tdata));
@@ -2714,6 +2722,9 @@ EXPORT_SYMBOL_GPL(cxgbi_attr_is_visible);
 static int __init libcxgbi_init_module(void)
 {
pr_info("%s", version);
+
+   BUILD_BUG_ON(FIELD_SIZEOF(struct sk_buff, cb) <
+sizeof(struct cxgbi_skb_cb));
return 0;
 }
 
diff --git a/drivers/scsi/cxgbi/libcxgbi.h b/drivers/scsi/cxgbi/libcxgbi.h
index 18e0ea8..239462a 100644
--- a/drivers/scsi/cxgbi/libcxgbi.h
+++ b/drivers/scsi/cxgbi/libcxgbi.h
@@ -195,7 +195,8 @@ struct cxgbi_skb_rx_cb {
 };
 
 struct cxgbi_skb_tx_cb {
-   void *l2t;
+   void *handle;
+   void *arp_err_handler;
struct sk_buff *wr_next;
 };
 
@@ -203,6 +204,7 @@ enum cxgbi_skcb_flags {
SKCBF_TX_NEED_HDR,  /* packet needs a header */
SKCBF_TX_MEM_WRITE, /* memory write */
SKCBF_TX_FLAG_COMPL,/* wr completion flag */
+   SKCBF_TX_DONE,  /* skb tx done */
SKCBF_RX_COALESCED, /* received whole pdu */
SKCBF_RX_HDR,   /* received pdu header */
SKCBF_RX_DATA,  /* received pdu payload */
@@ -215,13 +217,13 @@ enum cxgbi_skcb_flags {
 };
 
 struct cxgbi_skb_cb {
-   unsigned char ulp_mode;
-   unsigned long flags;
-   unsigned int seq;
union {
struct cxgbi_skb_rx_cb rx;
struct cxgbi_skb_tx_cb tx;
};
+   unsigned char 

Re: [PATCH] sd: fix sysfs writes to "provisioning_mode" and "zeroing_mode"

[Ewan D. Milne]

On Mon, 2017-05-15 at 17:18 -0400, Martin K. Petersen wrote:
> Bart,
> 
> >> So, are you suggesting we change all the other sysfs store routines?
> >
> > I will leave it to Martin and James to comment on this.
> 
> As I mentioned a few weeks ago, I have a patch that converts all these
> to sysfs_match_string(). Now that the latter is upstream I intend to
> post the patch.
> 

OK good.  One other thing I wanted to check -- I assume it is
intentional that the provisioning mode cannot be set back to "full"
once the device probe has set it and/or it has been manually set via
sysfs?

-Ewan

[PATCH v2 33/53] scsi: fix some kernel-doc markups

[Mauro Carvalho Chehab]

Sphinx is very pedantic with regards to ident/spacing.
Fix some kernel-doc markups in order to solve those
errors/warnings:

./drivers/scsi/scsicam.c:121: WARNING: Inline emphasis start-string without 
end-string.
./drivers/scsi/scsicam.c:121: WARNING: Inline emphasis start-string without 
end-string.
./drivers/scsi/scsicam.c:121: WARNING: Inline emphasis start-string without 
end-string.
./drivers/scsi/scsi_scan.c:1056: ERROR: Unexpected indentation.
./drivers/scsi/scsi_scan.c:1057: WARNING: Block quote ends without a blank 
line; unexpected unindent.
./drivers/scsi/scsi_transport_fc.c:2918: ERROR: Unexpected indentation.
./drivers/scsi/scsi_transport_fc.c:2921: WARNING: Block quote ends without a 
blank line; unexpected unindent.
./drivers/scsi/scsi_transport_fc.c:2922: WARNING: Enumerated list ends without 
a blank line; unexpected unindent.

No functional changes.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/scsi/scsi_scan.c |  7 ---
 drivers/scsi/scsi_transport_fc.c | 18 ++
 drivers/scsi/scsicam.c   |  4 ++--
 3 files changed, 16 insertions(+), 13 deletions(-)

diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c
index 6f7128f49c30..69979574004f 100644
--- a/drivers/scsi/scsi_scan.c
+++ b/drivers/scsi/scsi_scan.c
@@ -1051,10 +1051,11 @@ static unsigned char *scsi_inq_str(unsigned char *buf, 
unsigned char *inq,
  * allocate and set it up by calling scsi_add_lun.
  *
  * Return:
- * SCSI_SCAN_NO_RESPONSE: could not allocate or setup a scsi_device
- * SCSI_SCAN_TARGET_PRESENT: target responded, but no device is
+ *
+ *   - SCSI_SCAN_NO_RESPONSE: could not allocate or setup a scsi_device
+ *   - SCSI_SCAN_TARGET_PRESENT: target responded, but no device is
  * attached at the LUN
- * SCSI_SCAN_LUN_PRESENT: a new scsi_device was allocated and initialized
+ *   - SCSI_SCAN_LUN_PRESENT: a new scsi_device was allocated and initialized
  **/
 static int scsi_probe_and_add_lun(struct scsi_target *starget,
  u64 lun, int *bflagsp,
diff --git a/drivers/scsi/scsi_transport_fc.c b/drivers/scsi/scsi_transport_fc.c
index d4cf32d55546..1df77453f6b6 100644
--- a/drivers/scsi/scsi_transport_fc.c
+++ b/drivers/scsi/scsi_transport_fc.c
@@ -2914,16 +2914,18 @@ EXPORT_SYMBOL(fc_remote_port_add);
  * port is no longer part of the topology. Note: Although a port
  * may no longer be part of the topology, it may persist in the remote
  * ports displayed by the fc_host. We do this under 2 conditions:
+ *
  * 1) If the port was a scsi target, we delay its deletion by "blocking" it.
- *   This allows the port to temporarily disappear, then reappear without
- *   disrupting the SCSI device tree attached to it. During the "blocked"
- *   period the port will still exist.
+ *This allows the port to temporarily disappear, then reappear without
+ *disrupting the SCSI device tree attached to it. During the "blocked"
+ *period the port will still exist.
+ *
  * 2) If the port was a scsi target and disappears for longer than we
- *   expect, we'll delete the port and the tear down the SCSI device tree
- *   attached to it. However, we want to semi-persist the target id assigned
- *   to that port if it eventually does exist. The port structure will
- *   remain (although with minimal information) so that the target id
- *   bindings remails.
+ *expect, we'll delete the port and the tear down the SCSI device tree
+ *attached to it. However, we want to semi-persist the target id assigned
+ *to that port if it eventually does exist. The port structure will
+ *remain (although with minimal information) so that the target id
+ *bindings remails.
  *
  * If the remote port is not an FCP Target, it will be fully torn down
  * and deallocated, including the fc_remote_port class device.
diff --git a/drivers/scsi/scsicam.c b/drivers/scsi/scsicam.c
index 910f4a7a3924..31273468589c 100644
--- a/drivers/scsi/scsicam.c
+++ b/drivers/scsi/scsicam.c
@@ -116,8 +116,8 @@ EXPORT_SYMBOL(scsicam_bios_param);
  * @hds: put heads here
  * @secs: put sectors here
  *
- * Description: determine the BIOS mapping/geometry used to create the 
partition
- *  table, storing the results in *cyls, *hds, and *secs 
+ * Determine the BIOS mapping/geometry used to create the partition
+ * table, storing the results in @cyls, @hds, and @secs
  *
  * Returns: -1 on failure, 0 on success.
  */
-- 
2.9.3

[PATCH v2 46/53] ia64, scsi: update references for the device-io book

[Mauro Carvalho Chehab]

The book is now at Documentation/driver-api/device-io.rst.
Update such references.

Signed-off-by: Mauro Carvalho Chehab 
---
 arch/ia64/include/asm/io.h | 2 +-
 arch/ia64/sn/kernel/iomv.c | 2 +-
 drivers/scsi/qla1280.c | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/ia64/include/asm/io.h b/arch/ia64/include/asm/io.h
index 5de673ac9cb1..a2540e21f919 100644
--- a/arch/ia64/include/asm/io.h
+++ b/arch/ia64/include/asm/io.h
@@ -117,7 +117,7 @@ extern int valid_mmap_phys_addr_range (unsigned long pfn, 
size_t count);
  * following the barrier will arrive after all previous writes.  For most
  * ia64 platforms, this is a simple 'mf.a' instruction.
  *
- * See Documentation/DocBook/deviceiobook.tmpl for more information.
+ * See Documentation/driver-api/device-io.rst for more information.
  */
 static inline void ___ia64_mmiowb(void)
 {
diff --git a/arch/ia64/sn/kernel/iomv.c b/arch/ia64/sn/kernel/iomv.c
index c77ebdf98119..2b22a71663c1 100644
--- a/arch/ia64/sn/kernel/iomv.c
+++ b/arch/ia64/sn/kernel/iomv.c
@@ -63,7 +63,7 @@ EXPORT_SYMBOL(sn_io_addr);
 /**
  * __sn_mmiowb - I/O space memory barrier
  *
- * See arch/ia64/include/asm/io.h and Documentation/DocBook/deviceiobook.tmpl
+ * See arch/ia64/include/asm/io.h and Documentation/driver-api/device-io.rst
  * for details.
  *
  * On SN2, we wait for the PIO_WRITE_STATUS SHub register to clear.
diff --git a/drivers/scsi/qla1280.c b/drivers/scsi/qla1280.c
index 634254a52301..8a29fb09db14 100644
--- a/drivers/scsi/qla1280.c
+++ b/drivers/scsi/qla1280.c
@@ -3390,7 +3390,7 @@ qla1280_isp_cmd(struct scsi_qla_host *ha)
 *On PCI bus, order reverses and write of 6 posts, then index 5,
 *   causing chip to issue full queue of stale commands
 * The mmiowb() prevents future writes from crossing the barrier.
-* See Documentation/DocBook/deviceiobook.tmpl for more information.
+* See Documentation/driver-api/device-io.rst for more information.
 */
WRT_REG_WORD(>mailbox4, ha->req_ring_index);
mmiowb();
-- 
2.9.3

[Bug 195285] qla2xxx FW immediatly crashing after target start

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=195285

--- Comment #3 from Anthony (anthony.blood...@gmail.com) ---
Two cards installed in new test machine: QLE2462 and QLE2560
qle2560 spam with errors (without starting a target)

scsi host8: qla2xxx
qla2xxx [:05:00.1]-00fb:8: QLogic QLE2462 - PCI-Express Dual Channel 4Gb
Fibre Channel HBA.
qla2xxx [:05:00.1]-00fc:8: ISP2432: PCIe (2.5GT/s x4) @ :05:00.1 hdma+
host#=8 fw=8.06.00 (9496).
qla2xxx [:09:00.0]-001a: : MSI-X vector count: 32.
qla2xxx [:09:00.0]-001d: : Found an ISP2532 irq 16 iobase
0xba4886335000.
qla2xxx [:09:00.0]-504b:9: RISC paused -- HCCR=40, Dumping firmware.
qla2xxx [:09:00.0]-d001:9: Firmware dump saved to temp buffer
(9/ba488c001000), dump status flags (0x3f).
qla2xxx [:09:00.0]-1005:9: Cmd 0x59 aborted with timeout since ISP Abort is
pending
scsi host9: qla2xxx
qla2xxx [:09:00.0]-00fb:9: QLogic QLE2560 - PCI-Express Single Channel 8Gb
Fibre Channel HBA.
qla2xxx [:09:00.0]-00fc:9: ISP2532: PCIe (5.0GT/s x8) @ :09:00.0 hdma+
host#=9 fw=8.06.00 (90d5).
qla2xxx [:05:00.0]-500a:7: LOOP UP detected (4 Gbps).
qla2xxx [:05:00.1]-500a:8: LOOP UP detected (4 Gbps).
qla2xxx [:09:00.0]-00af:9: Performing ISP error recovery -
ha=98315ee3.
qla2xxx [:09:00.0]-504b:9: RISC paused -- HCCR=40, Dumping firmware.
qla2xxx [:09:00.0]-d009:9: Firmware has been previously dumped
(ba488c001000) -- ignoring request.
qla2xxx [:09:00.0]-504b:9: RISC paused -- HCCR=40, Dumping firmware.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.