Re: [PATCH qla2xxx] Race in handling rport deletion in Qlogic driver during recovery causes panic
On Tue, Nov 25, 2014 at 09:16:42AM -0500, Laurence Oberman wrote: When we have an rport disconnect we race during rport deletion and re-connection resulting in a panic. When we do this, we call fc_remote_port_del() just before we do the calls to re-establish the session with the FC transport with fc_remote_port_add() and then fc_remote_port_rolechg(). If we remove the call to fc_remote_port_del() before re-establishing the connection this prevents the race. This patch has resolved this for multiple customers via test kernels. Suggested by Chad Dupuis, implemented and tested by Laurence Oberman. Chad, can you review this one? Or do you plan to send it to me with the next qla2xxx update? Note that the 3.19 merge window is about to end. -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] bfa: switch to mid layer queue full tracking
On Thu, Nov 27, 2014 at 05:46:23AM +, Anil Gurumurthy wrote:
Patch looks good.
Thanks!
Acked-by: Anil Gurumurthy anil.gurumur...@qlogic.com
Thanks. Can someone give me a second review?
-Original Message-
From: Christoph Hellwig [mailto:h...@lst.de]
Sent: 24 November 2014 19:49
To: Anil Gurumurthy; Sudarsana Kalluru
Cc: linux-scsi
Subject: [PATCH] bfa: switch to mid layer queue full tracking
As far as I can tell the queue tracking in the bfa driver is a copypaste
copy of the midlayer version, just without support to configure it through
sysfs.
Remove the bfa copy and rely on the mid layer version.
Signed-off-by: Christoph Hellwig h...@lst.de
---
drivers/scsi/bfa/bfad_im.c | 66
++
drivers/scsi/bfa/bfad_im.h | 6 -
2 files changed, 2 insertions(+), 70 deletions(-)
diff --git a/drivers/scsi/bfa/bfad_im.c b/drivers/scsi/bfa/bfad_im.c index
7223b00..ac55fd9 100644
--- a/drivers/scsi/bfa/bfad_im.c
+++ b/drivers/scsi/bfa/bfad_im.c
@@ -43,8 +43,6 @@ bfa_cb_ioim_done(void *drv, struct bfad_ioim_s *dio, {
struct scsi_cmnd *cmnd = (struct scsi_cmnd *)dio;
struct bfad_s *bfad = drv;
- struct bfad_itnim_data_s *itnim_data;
- struct bfad_itnim_s *itnim;
u8 host_status = DID_OK;
switch (io_status) {
@@ -93,19 +91,6 @@ bfa_cb_ioim_done(void *drv, struct bfad_ioim_s *dio,
cmnd-host_scribble = NULL;
bfa_trc(bfad, cmnd-result);
- itnim_data = cmnd-device-hostdata;
- if (itnim_data) {
- itnim = itnim_data-itnim;
- if (!cmnd-result itnim
- (bfa_lun_queue_depth cmnd-device-queue_depth)) {
- /* Queue depth adjustment for good status completion */
- bfad_ramp_up_qdepth(itnim, cmnd-device);
- } else if (cmnd-result == SAM_STAT_TASK_SET_FULL itnim) {
- /* qfull handling */
- bfad_handle_qfull(itnim, cmnd-device);
- }
- }
-
cmnd-scsi_done(cmnd);
}
@@ -113,8 +98,6 @@ void
bfa_cb_ioim_good_comp(void *drv, struct bfad_ioim_s *dio) {
struct scsi_cmnd *cmnd = (struct scsi_cmnd *)dio;
- struct bfad_itnim_data_s *itnim_data;
- struct bfad_itnim_s *itnim;
cmnd-result = ScsiResult(DID_OK, SCSI_STATUS_GOOD);
@@ -123,17 +106,6 @@ bfa_cb_ioim_good_comp(void *drv, struct bfad_ioim_s *dio)
scsi_dma_unmap(cmnd);
cmnd-host_scribble = NULL;
-
- /* Queue depth adjustment */
- if (bfa_lun_queue_depth cmnd-device-queue_depth) {
- itnim_data = cmnd-device-hostdata;
- if (itnim_data) {
- itnim = itnim_data-itnim;
- if (itnim)
- bfad_ramp_up_qdepth(itnim, cmnd-device);
- }
- }
-
cmnd-scsi_done(cmnd);
}
@@ -801,6 +773,7 @@ struct scsi_host_template bfad_im_scsi_host_template = {
.max_sectors = BFAD_MAX_SECTORS,
.vendor_id = BFA_PCI_VENDOR_ID_BROCADE,
.use_blk_tags = 1,
+ .track_queue_depth = 1,
};
struct scsi_host_template bfad_im_vport_template = { @@ -823,6 +796,7 @@
struct scsi_host_template bfad_im_vport_template = {
.shost_attrs = bfad_im_vport_attrs,
.max_sectors = BFAD_MAX_SECTORS,
.use_blk_tags = 1,
+ .track_queue_depth = 1,
};
bfa_status_t
@@ -853,42 +827,6 @@ bfad_im_module_exit(void)
fc_release_transport(bfad_im_scsi_vport_transport_template);
}
-void
-bfad_ramp_up_qdepth(struct bfad_itnim_s *itnim, struct scsi_device *sdev) -{
- struct scsi_device *tmp_sdev;
-
- if (((jiffies - itnim-last_ramp_up_time)
- BFA_QUEUE_FULL_RAMP_UP_TIME * HZ)
- ((jiffies - itnim-last_queue_full_time)
- BFA_QUEUE_FULL_RAMP_UP_TIME * HZ)) {
- shost_for_each_device(tmp_sdev, sdev-host) {
- if (bfa_lun_queue_depth tmp_sdev-queue_depth) {
- if (tmp_sdev-id != sdev-id)
- continue;
- scsi_change_queue_depth(tmp_sdev,
- tmp_sdev-queue_depth + 1);
-
- itnim-last_ramp_up_time = jiffies;
- }
- }
- }
-}
-
-void
-bfad_handle_qfull(struct bfad_itnim_s *itnim, struct scsi_device *sdev) -{
- struct scsi_device *tmp_sdev;
-
- itnim-last_queue_full_time = jiffies;
-
- shost_for_each_device(tmp_sdev, sdev-host) {
- if (tmp_sdev-id != sdev-id)
- continue;
- scsi_track_queue_full(tmp_sdev, tmp_sdev-queue_depth - 1);
- }
-}
-
struct bfad_itnim_s *
bfad_get_itnim(struct bfad_im_port_s *im_port, int id) { diff --git
a/drivers/scsi/bfa/bfad_im.h b/drivers/scsi/bfa/bfad_im.h
Re: [PATCH 1/4] scsi: remove -change_queue_type method
On Wed, Dec 03, 2014 at 02:32:04PM +0100, Hannes Reinecke wrote: Why not setting the attribute to S_IRUGO always and drop the 'store' method altogether? For now I'm printing a warning if someone writes to it. I the long run we can simply mark it r/o. -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/12] nobody loves the advansys driver
On Wed, Dec 03, 2014 at 04:34:48PM +0100, Ondrej Zary wrote: I have an ASB-3940UA (bought around 2000) and use it for scanner so I can test patches. The driver was working fine so I never had to look at the code. Now I see that it's 12K lines long :( Converting that to something simple would require a lot of work. So we've got a dedicated tester for the narrow boards :) Just by splitting that monster in the two drivers it's underneath and removing various pointless wrappers they'd be down to a fairly reasonable size. -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/12] nobody loves the advansys driver
On Wed, Dec 03, 2014 at 03:42:19PM +, James Bottomley wrote:
That's the problem: The driver as-is works in all of the use cases, so
no-one has any motivation to fix it. Plus the complexity is pretty
daunting. It's not even the worst driver we have (that prize goes to
atp870u which still has internal bus scanning code). I'm not saying
don't do the conversion, but I am saying it will have to be validated
and tested before it can go in because lots of people still seem to use
this family of devices in odd corners of the world.
The split itself actually is really easy - every single method has
a if (ASC_NARROW_BOARD(boardp)) { ... } else { ... } so the
code actually is separate. But now that we have Hannes interested
in the wide side, and also a tester for the the narrow side I think we're
fine anyway.
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/12] advansys: use host_reset
-#define AdvAbortQueue(asc_dvc, scsiq) \
+#define AdvAbortQueue(asc_dvc, srb_tag) \
AdvSendIdleCmd((asc_dvc), (ushort) IDLE_CMD_ABORT, \
- (ADV_DCNT) (scsiq))
+ (ADV_DCNT) (srb_tag))
This change looks unrelated.
@@ -11250,7 +11250,7 @@ static struct scsi_host_template advansys_template = {
.name = DRV_NAME,
.info = advansys_info,
.queuecommand = advansys_queuecommand,
- .eh_bus_reset_handler = advansys_reset,
+ .eh_host_reset_handler = advansys_reset,
Please also update the comments in advansys_reset that talk about bus
resets and in one case event about a device reset.
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 12/12] advansys: Update to version 3.5 and remove compilation warning
/* FIXME:
*
- * 1. Although all of the necessary command mapping places have the
- * appropriate dma_map.. APIs, the driver still processes its internal
- * queue using bus_to_virt() and virt_to_bus() which are illegal under
- * the API. The entire queue processing structure will need to be
- * altered to fix this.
+ * 1. (done)
* 2. Need to add memory mapping workaround. Test the memory mapping.
* If it doesn't work revert to I/O port access. Can a test be done
* safely?
* 3. Handle an interrupt not working. Keep an interrupt counter in
* the interrupt handler. In the timeout function if the interrupt
* has not occurred then print a message and run in polled mode.
- * 4. Need to add support for target mode commands, cf. CAM XPT.
- * 5. check DMA mapping functions for failure
+ * 4. (obsolete)
+ * 5. (done)
* 6. Use scsi_transport_spi
* 7. advansys_info is not safe against multiple simultaneous callers
* 8. Add module_param to override ISA/VLB ioport array
Just drop the done/obsolete items and renumber the rest :)
+ if (dma_mapping_error(board-dev, scp-SCp.dma_handle)) {
+ ASC_DBG(1, failed to map sense buffer\n);
+ return 0;
+ }
dma_cache_sync(board-dev, scp-sense_buffer,
SCSI_SENSE_BUFFERSIZE, DMA_FROM_DEVICE);
return cpu_to_le32(scp-SCp.dma_handle);
@@ -7794,6 +7794,8 @@ static int asc_build_req(struct asc_board *boardp,
struct scsi_cmnd *scp,
ASC_TIDLUN_TO_IX(scp-device-id, scp-device-lun);
asc_scsi_q-q1.sense_addr = advansys_get_sense_buffer_dma(scp);
asc_scsi_q-q1.sense_len = SCSI_SENSE_BUFFERSIZE;
+ if (!asc_scsi_q-q1.sense_addr)
+ return ASC_ERROR;
Please split the addition of error handling into a separate patch,
or in case of newly added mappigns add them to the patch that add the
mappings.
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/12] advansys: use host_reset
On 12/04/2014 10:17 AM, Christoph Hellwig wrote:
-#define AdvAbortQueue(asc_dvc, scsiq) \
+#define AdvAbortQueue(asc_dvc, srb_tag) \
AdvSendIdleCmd((asc_dvc), (ushort) IDLE_CMD_ABORT, \
- (ADV_DCNT) (scsiq))
+ (ADV_DCNT) (srb_tag))
This change looks unrelated.
Yes, correct. This needs to be moved to the next patch.
@@ -11250,7 +11250,7 @@ static struct scsi_host_template advansys_template =
{
.name = DRV_NAME,
.info = advansys_info,
.queuecommand = advansys_queuecommand,
-.eh_bus_reset_handler = advansys_reset,
+.eh_host_reset_handler = advansys_reset,
Please also update the comments in advansys_reset that talk about bus
resets and in one case event about a device reset.
Okay.
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries Storage
h...@suse.de +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 21284 (AG Nürnberg)
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/12] advansys: use shared host tag map for command lookup
On 12/04/2014 10:20 AM, Christoph Hellwig wrote:
typedef struct asc_scsiq_2 {
-ASC_VADDR srb_ptr;
+__le32 srb_tag;
Given that the tag has no meaning for the hardware why do you
want to endian switch it? Keeping the ASC_VADDR for now makes
it easier to verify the hardware structures don't change.
Mhm. See the patch I've just sent to Ondrej.
For the narrow board it actually _has_ a meaning.
But okay, the endian switch is probably pointless here.
@@ -6132,6 +6077,13 @@ static void adv_async_callback(ADV_DVC_VAR
*adv_dvc_varp, uchar code)
AdvResetChipAndSB(adv_dvc_varp);
break;
+case ADV_ASYNC_CARRIER_READY_FAILURE:
+/*
+ * Carrier not ready; abort the command.
+ */
+ASC_DBG(0, ADV_ASYNC_CARRIER_READY_FAILURE\n);
+break;
+
Where does this one come from?
Encountered during debugging, I just thought to have it printed.
But okay, I can move it into a separate patch.
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries Storage
h...@suse.de +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 21284 (AG Nürnberg)
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] Revert mpt2sas, mpt3sas: remove disconnected phys on topology change
Thanks, I've applied both patches. -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] esas2r: Correct typos of validate in a comment
Thanks, applied. -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 12/12] advansys: Update to version 3.5 and remove compilation warning
On 12/04/2014 10:23 AM, Christoph Hellwig wrote:
/* FIXME:
*
- * 1. Although all of the necessary command mapping places have the
- * appropriate dma_map.. APIs, the driver still processes its internal
- * queue using bus_to_virt() and virt_to_bus() which are illegal under
- * the API. The entire queue processing structure will need to be
- * altered to fix this.
+ * 1. (done)
* 2. Need to add memory mapping workaround. Test the memory mapping.
* If it doesn't work revert to I/O port access. Can a test be done
* safely?
* 3. Handle an interrupt not working. Keep an interrupt counter in
* the interrupt handler. In the timeout function if the interrupt
* has not occurred then print a message and run in polled mode.
- * 4. Need to add support for target mode commands, cf. CAM XPT.
- * 5. check DMA mapping functions for failure
+ * 4. (obsolete)
+ * 5. (done)
* 6. Use scsi_transport_spi
* 7. advansys_info is not safe against multiple simultaneous callers
* 8. Add module_param to override ISA/VLB ioport array
Just drop the done/obsolete items and renumber the rest :)
+if (dma_mapping_error(board-dev, scp-SCp.dma_handle)) {
+ASC_DBG(1, failed to map sense buffer\n);
+return 0;
+}
dma_cache_sync(board-dev, scp-sense_buffer,
SCSI_SENSE_BUFFERSIZE, DMA_FROM_DEVICE);
return cpu_to_le32(scp-SCp.dma_handle);
@@ -7794,6 +7794,8 @@ static int asc_build_req(struct asc_board *boardp,
struct scsi_cmnd *scp,
ASC_TIDLUN_TO_IX(scp-device-id, scp-device-lun);
asc_scsi_q-q1.sense_addr = advansys_get_sense_buffer_dma(scp);
asc_scsi_q-q1.sense_len = SCSI_SENSE_BUFFERSIZE;
+if (!asc_scsi_q-q1.sense_addr)
+return ASC_ERROR;
Please split the addition of error handling into a separate patch,
or in case of newly added mappigns add them to the patch that add the
mappings.
Okay.
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries Storage
h...@suse.de +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 21284 (AG Nürnberg)
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/12] advansys: use shared host tag map for command lookup
On Thu, Dec 04, 2014 at 10:25:41AM +0100, Hannes Reinecke wrote: Given that the tag has no meaning for the hardware why do you want to endian switch it? Keeping the ASC_VADDR for now makes it easier to verify the hardware structures don't change. Mhm. See the patch I've just sent to Ondrej. For the narrow board it actually _has_ a meaning. But okay, the endian switch is probably pointless here. Well, 0 vs non-0 isn't changed by endian conversion. And the old driver didn't do it either, so changing to and endianess conversion needs to be documented, and preferably in a separate patch. -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch v2] mpt2sas: issue reset is never uninitialized
The issue_reset variable can be used uninitialized. It should be set to false at the start. Also I cleaned up the types by using bool. Signed-off-by: Dan Carpenter dan.carpen...@oracle.com --- v2: style fix diff --git a/drivers/scsi/mpt2sas/mpt2sas_base.c b/drivers/scsi/mpt2sas/mpt2sas_base.c index 58e4521..3fb01d1 100644 --- a/drivers/scsi/mpt2sas/mpt2sas_base.c +++ b/drivers/scsi/mpt2sas/mpt2sas_base.c @@ -3236,7 +3236,7 @@ mpt2sas_base_sas_iounit_control(struct MPT2SAS_ADAPTER *ioc, u16 smid; u32 ioc_state; unsigned long timeleft; - u8 issue_reset; + bool issue_reset = false; int rc; void *request; u16 wait_state_count; @@ -3300,7 +3300,7 @@ mpt2sas_base_sas_iounit_control(struct MPT2SAS_ADAPTER *ioc, _debug_dump_mf(mpi_request, sizeof(Mpi2SasIoUnitControlRequest_t)/4); if (!(ioc-base_cmds.status MPT2_CMD_RESET)) - issue_reset = 1; + issue_reset = true; goto issue_host_reset; } if (ioc-base_cmds.status MPT2_CMD_REPLY_VALID) @@ -3341,7 +3341,7 @@ mpt2sas_base_scsi_enclosure_processor(struct MPT2SAS_ADAPTER *ioc, u16 smid; u32 ioc_state; unsigned long timeleft; - u8 issue_reset; + bool issue_reset = false; int rc; void *request; u16 wait_state_count; @@ -3398,7 +3398,7 @@ mpt2sas_base_scsi_enclosure_processor(struct MPT2SAS_ADAPTER *ioc, _debug_dump_mf(mpi_request, sizeof(Mpi2SepRequest_t)/4); if (!(ioc-base_cmds.status MPT2_CMD_RESET)) - issue_reset = 1; + issue_reset = true; goto issue_host_reset; } if (ioc-base_cmds.status MPT2_CMD_REPLY_VALID) -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch v2] mpt3sas: issue_reset is uninitialized
The issue_reset can be used uninitialized. It should be set to false at the start. Also I cleaned up the types a little by using bool. Signed-off-by: Dan Carpenter dan.carpen...@oracle.com --- v2: style fix. use true/false instead of 1/0. diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c b/drivers/scsi/mpt3sas/mpt3sas_base.c index 1560115..b9c2739 100644 --- a/drivers/scsi/mpt3sas/mpt3sas_base.c +++ b/drivers/scsi/mpt3sas/mpt3sas_base.c @@ -3419,7 +3419,7 @@ mpt3sas_base_sas_iounit_control(struct MPT3SAS_ADAPTER *ioc, u16 smid; u32 ioc_state; unsigned long timeleft; - u8 issue_reset; + bool issue_reset = false; int rc; void *request; u16 wait_state_count; @@ -3483,7 +3483,7 @@ mpt3sas_base_sas_iounit_control(struct MPT3SAS_ADAPTER *ioc, _debug_dump_mf(mpi_request, sizeof(Mpi2SasIoUnitControlRequest_t)/4); if (!(ioc-base_cmds.status MPT3_CMD_RESET)) - issue_reset = 1; + issue_reset = true; goto issue_host_reset; } if (ioc-base_cmds.status MPT3_CMD_REPLY_VALID) @@ -3523,7 +3523,7 @@ mpt3sas_base_scsi_enclosure_processor(struct MPT3SAS_ADAPTER *ioc, u16 smid; u32 ioc_state; unsigned long timeleft; - u8 issue_reset; + bool issue_reset = false; int rc; void *request; u16 wait_state_count; @@ -3581,7 +3581,7 @@ mpt3sas_base_scsi_enclosure_processor(struct MPT3SAS_ADAPTER *ioc, _debug_dump_mf(mpi_request, sizeof(Mpi2SepRequest_t)/4); if (!(ioc-base_cmds.status MPT3_CMD_RESET)) - issue_reset = 1; + issue_reset = false; goto issue_host_reset; } if (ioc-base_cmds.status MPT3_CMD_REPLY_VALID) -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4] scsi: ufs: add support of generic PHY and ICE in Qualcomm chips
On Thu, Nov 27, 2014 at 05:59:58PM +0200, Yaniv Gardi wrote: In this change we add support to the generic PHY framework. Two UFS phys are implemented: qmp-20nm and qmp-28nm. Also, the files in this change implement the UFS HW (controller PHY) specific behavior in Qualcomm chips. Relocation of a few header files is needed in order to expose routines and data structures between PHY driver and UFS driver. Also, this change include the implementation of Inline Crypto Engine (ICE) in Qualcomm chips. This whole patch is a mess. It does way to many things in one patch, and it doesn't explain enough of it. Please explain why you need it. Especially as the PHY API is a generic phy abstraction, so having to share defintions between the provider and consumer seems wrong. Even if you need some shared bits keep them to an absolute minium insted of moving so much out of the driver directory. Also if at all possible keep the shared data in a single header under include/linux instead of having lots of global headers in a deep directory structure. Second split this into patches that do a single things, and explain why you're doing each: 1) header move if/as needed 2) add 20nm phy driver 3) add 28nm phy driver 4) add ufs-qcom driver 5) add ufs-qcom-ice support and so on. -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Tagged overlapped commands
On 1 December 2014 at 12:24, Andrew Brooks a...@sat.dundee.ac.uk wrote: I'm having trouble writing to an LTO-5 tape drive connected via Adaptec 1405 Writing aborts with this in syslog: st0: Sense Key : Aborted Command [current] st0: Add. Sense: Tagged overlapped commands (task tag 0) If I enable debugging I get the following, does it help narrow down the problem? 14:02:25 kernel: [ 1372.991912] mv_sas.c 2067:phy 1 ctrl sts=0x00089800. 14:02:25 kernel: [ 1372.991914] mv_sas.c 2069:phy 1 irq sts = 0x01001001 14:02:25 kernel: [ 1372.995158] mv_sas.c 1957:Release slot [0] tag[0], task [88021e2161c0]: 14:02:25 kernel: [ 1373.488140] st0: Error 1 (driver bt 0x0, host bt 0x1). 14:02:25 kernel: [ 1373.488432] mv_sas.c 753:SAS port 0 does not attachdevice. 14:02:25 kernel: [ 1373.490299] st0: Error 1 (driver bt 0x0, host bt 0x1). 14:02:25 kernel: [ 1373.490302] st0: Error on write filemark. 14:02:25 kernel: [ 1373.506689] mv_sas.c 753:SAS port 0 does not attachdevice. 14:02:25 kernel: [ 1373.506707] st0: Error 1 (driver bt 0x0, host bt 0x1). 14:02:27 kernel: [ 1375.392013] mv_sas.c 2005:phy1 Removed Device 14:02:27 kernel: [ 1375.395238] mv_sas.c 1353:found dev[0:1] is gone. 14:02:30 kernel: [ 1379.172027] mv_sas.c 2069:phy 1 irq sts = 0x0085 14:02:30 kernel: [ 1379.172033] mv_sas.c 2118:notify plug in on phy[1] 14:02:30 kernel: [ 1379.176012] mv_sas.c 1181:phy 1 attach dev info is 80001 14:02:30 kernel: [ 1379.176012] mv_sas.c 1183:phy 1 attach sas addr is 7c325301a0100150 14:02:30 kernel: [ 1379.176012] mv_sas.c 277:phy 1 byte dmaded. 14:02:30 kernel: [ 1379.261430] sas: phy-2:1 added to port-2:0, phy_mask:0x2 (500110a00153327c) 14:02:30 kernel: [ 1379.261433] mv_sas.c 1218:set wide port phy map 2 14:02:30 kernel: [ 1379.291229] sas: DOING DISCOVERY on port 0, pid:17 14:02:30 kernel: [ 1379.292725] scsi 2:0:1:0: Sequential-Access HP Ultrium 5-SCSI Z64D PQ: 0 ANSI: 6 14:02:30 kernel: [ 1379.296458] st 2:0:1:0: Attached scsi tape st0 14:02:30 kernel: [ 1379.296462] st 2:0:1:0: st0: try direct i/o: yes (alignment 4 B) 14:02:30 kernel: [ 1379.296531] st 2:0:1:0: Attached scsi generic sg2 type 1 14:02:30 kernel: [ 1379.297314] sas: DONE DISCOVERY on port 0, pid:17, result:0 14:02:35 kernel: [ 1384.176006] mv_sas.c 2053:Get signature time out, reset phy 1 14:02:35 kernel: [ 1384.176020] mv_sas.c 2067:phy 1 ctrl sts=0x00089800. 14:02:35 kernel: [ 1384.176024] mv_sas.c 2069:phy 1 irq sts = 0x1001 14:02:36 kernel: [ 1384.672106] mv_sas.c 2069:phy 1 irq sts = 0x0100109F 14:02:36 kernel: [ 1384.676094] mv_sas.c 2118:notify plug in on phy[1] 14:02:36 kernel: [ 1384.676094] mv_sas.c 2143:plugin interrupt but phy1 is gone 14:02:36 kernel: [ 1385.168221] mv_sas.c 753:SAS port 0 does not attachdevice. 14:02:37 kernel: [ 1386.172012] mv_sas.c 753:SAS port 0 does not attachdevice. 14:02:38 kernel: [ 1386.496002] mv_sas.c 1181:phy 1 attach dev info is 80001 14:02:38 kernel: [ 1386.496002] mv_sas.c 1183:phy 1 attach sas addr is 7c325301a0100150 14:02:38 kernel: [ 1386.496002] mv_sas.c 277:phy 1 byte dmaded. 14:02:38 kernel: [ 1386.551563] mv_sas.c 1218:set wide port phy map 2 14:02:38 kernel: [ 1386.561489] sas: sas_form_port: phy1 belongs to port0 already(1)! 14:02:38 kernel: [ 1386.551563] mv_sas.c 2011:phy1 Attached Device -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RESEND 4/5] ipr: Set scsi_level correctly for disk arrays
On 12/04/2014 03:25 AM, Christoph Hellwig wrote: Do you want me to apply this patch ASAP while waiting for the kexec ACK? Both patches 1 and 4 can be pulled in while we wait for Eric's ack. Thanks, Brian -- Brian King Power Linux I/O IBM Linux Technology Center -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Tagged overlapped commands
On Mon, 2014-12-01 at 12:24 +, Andrew Brooks wrote: Hi I'm having trouble writing to an LTO-5 tape drive connected via Adaptec 1405 Writing aborts with this in syslog: st0: Sense Key : Aborted Command [current] st0: Add. Sense: Tagged overlapped commands (task tag 0) Both the drive and adapter have the latest firmware. I've tried ubuntu 12.04 (3.2.0-70) and the latest fedora 20.1. Does anyone have any ideas on how to troubleshoot and fix this? The error message likely means that the tape device had more than one command outstanding at once (i.e. one command was sent while the current command was still pending). It could also mean that a tag got re-used (same tag issued while command with that tag was outstanding) but for a tape I think the former is more likely. Is the queue depth set to one for the device? James -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Scst-devel] New qla2x00tgt Driver Question
On Dec 3, 11:38pm, Duane Grigsby wrote: } Subject: Re: [Scst-devel] New qla2x00tgt Driver Question Hi Greg, Hi Duane, hope your day is starting out well. I looked at your logs and also reviewed the PLOGI handling in Trunk-SCST.15. We found a issue with PLOGI/PRLI cleanup handling that I'm addressing. Whatever fixes will get pushed upstream with the qla2xxx and scst-qla2xxx.git. Very good, I'm glad we were able to cast some illumination on this issue. If you could copy me on the fix I would be happy to roll it into the 3.10.x branch which we maintain for all of our storage infrastructure and put it into our test harness. I'm sure you saw the note from Vlad in which he feels the deferred ABORT messages we are seeing before a block device goes offline during NEXUS_LOSS_SESS handling have nothing to do with SCST SCSI core. Hopefully your fix will address whatever is getting lost in the shuffle on that front. Once we get that issue addressed we will put the fix into a second test harness to see if it addresses the holy grail of all this which is the catastrophic VMFS corruption which we have documented on adapter resets. duane Best wishes for a productive afternoon. Greg }-- End of excerpt from Duane Grigsby As always, Dr. G.W. Wettstein, Ph.D. Enjellic Systems Development, LLC. 4206 N. 19th Ave. Specializing in information infra-structure Fargo, ND 58102development. PH: 701-281-1686 FAX: 701-281-3949 EMAIL: g...@enjellic.com -- Sweeny's Law: The length of a progress report is inversely proportional to the amount of progress. -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] scsi_scan: Send TEST UNIT READY to LUN0 before LUN scanning
REPORT_LUN_SCAN does not report any outstanding unit attention
condition as per SAM. However, there are some target implementations
which might not be fully initialized by the time we're starting
the report lun scan.
For these targets we end up getting a default entry
(or even a partially filled one).
And as we're not able to process the REPORT LUN DATA HAS CHANGED
unit attention correctly we'll be missing out some LUNs altogether.
To handle these conditions properly I've added a new blacklist
flag 'BLIST_TEST_LUN0' which will send a TEST UNIT READY
and wait until the unit attention condition goes away.
We cannot make this the default as some other target
implementations rely on the scanning code to complete even though the
firmware might not be fully initialized.
Cc: Martthias Roessler matthias.roess...@ts.fujitsu.com
Signed-off-by: Hannes Reinecke h...@suse.de
---
drivers/scsi/scsi_devinfo.c | 1 +
drivers/scsi/scsi_scan.c| 88 ++---
include/scsi/scsi_devinfo.h | 2 ++
3 files changed, 78 insertions(+), 13 deletions(-)
diff --git a/drivers/scsi/scsi_devinfo.c b/drivers/scsi/scsi_devinfo.c
index 49014a1..4f446e3 100644
--- a/drivers/scsi/scsi_devinfo.c
+++ b/drivers/scsi/scsi_devinfo.c
@@ -166,6 +166,7 @@ static struct {
{easyRAID, X6P, NULL, BLIST_NOREPORTLUN},
{easyRAID, F8, NULL, BLIST_NOREPORTLUN},
{FSC, CentricStor, *, BLIST_SPARSELUN | BLIST_LARGELUN},
+ {FUJITSU, ETERNUS_DX, *, BLIST_TEST_LUN0 },
{Generic, USB SD Reader, 1.00, BLIST_FORCELUN | BLIST_INQUIRY_36},
{Generic, USB Storage-SMC, 0180, BLIST_FORCELUN |
BLIST_INQUIRY_36},
{Generic, USB Storage-SMC, 0207, BLIST_FORCELUN |
BLIST_INQUIRY_36},
diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c
index 0af7133..ca39e32 100644
--- a/drivers/scsi/scsi_scan.c
+++ b/drivers/scsi/scsi_scan.c
@@ -119,6 +119,13 @@ MODULE_PARM_DESC(inq_timeout,
Timeout (in seconds) waiting for devices to answer INQUIRY.
Default is 20. Some devices may need more; most need less.);
+static unsigned int scsi_scan_timeout = SCSI_TIMEOUT/HZ + 58;
+
+module_param_named(scan_timeout, scsi_scan_timeout, uint, S_IRUGO|S_IWUSR);
+MODULE_PARM_DESC(scan_timeout,
+Timeout (in seconds) waiting for devices to become ready
+ after INQUIRY. Default is 60.);
+
/* This lock protects only this list */
static DEFINE_SPINLOCK(async_scan_lock);
static LIST_HEAD(scanning_hosts);
@@ -719,19 +726,6 @@ static int scsi_probe_lun(struct scsi_device *sdev,
unsigned char *inq_result,
}
/*
-* Related to the above issue:
-*
-* XXX Devices (disk or all?) should be sent a TEST UNIT READY,
-* and if not ready, sent a START_STOP to start (maybe spin up) and
-* then send the INQUIRY again, since the INQUIRY can change after
-* a device is initialized.
-*
-* Ideally, start a device if explicitly asked to do so. This
-* assumes that a device is spun up on power on, spun down on
-* request, and then spun up on request.
-*/
-
- /*
* The scanning code needs to know the scsi_level, even if no
* device is attached at LUN 0 (SCSI_SCAN_TARGET_PRESENT) so
* non-zero LUNs can be scanned.
@@ -756,6 +750,65 @@ static int scsi_probe_lun(struct scsi_device *sdev,
unsigned char *inq_result,
}
/**
+ * scsi_test_lun - waiting for a LUN to become ready
+ * @sdev: scsi_device to test
+ *
+ * Description:
+ * Wait for the lun associated with @sdev to become ready
+ *
+ * Send a TEST UNIT READY to detect any unit attention conditions.
+ * Retry TEST UNIT READY for up to @scsi_scan_timeout if the
+ * returned sense key is 02/04/01 (Not ready, Logical Unit is
+ * in process of becoming ready)
+ **/
+static int
+scsi_test_lun(struct scsi_device *sdev)
+{
+ struct scsi_sense_hdr sshdr;
+ int res = SCSI_SCAN_TARGET_PRESENT;
+ int tur_result;
+ unsigned long tur_timeout = jiffies + scsi_scan_timeout * HZ;
+
+ /* Skip for older devices */
+ if (sdev-scsi_level = SCSI_3)
+ return SCSI_SCAN_LUN_PRESENT;
+
+ /*
+* Wait for the device to become ready.
+*
+* Some targets take some time before the firmware is
+* fully initialized, during which time they might not
+* be able to fill out any REPORT_LUN command correctly.
+* And as we're not capable of handling the
+* INQUIRY DATA CHANGED unit attention correctly we'd
+* rather wait here.
+*/
+ do {
+ tur_result = scsi_test_unit_ready(sdev, SCSI_TIMEOUT,
+ 3, sshdr);
+ if (!tur_result) {
+ res = SCSI_SCAN_LUN_PRESENT;
+ break;
+ }
+ if
Re: [PATCH] scsi_debug: fix compare and write errors
On Wed, 2014-11-26 at 12:45 -0500, Douglas Gilbert wrote: From: Douglas Gilbert dgilb...@interlog.com Date: Wed, 26 Nov 2014 12:33:48 -0500 Subject: [PATCH] scsi_debug fix compare and write errors Kernel build tools pointed out a memory leak so that has been fixed and its error paths strengthened with a goto. Testing showed compare and write was only working for lba=0; correcting the length of the LBA field fixed that. --- drivers/scsi/scsi_debug.c | 31 --- 1 file changed, 16 insertions(+), 15 deletions(-) Signed-off-by: Douglas Gilbert dgilb...@interlog.com Looks fine to me. Reviewed-by: Ewan D. Milne emi...@redhat.com -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] scsi_debug: improve driver description in Kconfig
On Wed, 2014-11-26 at 14:55 -0500, Douglas Gilbert wrote: From: Douglas Gilbert dgilb...@interlog.com Date: Wed, 26 Nov 2014 14:41:55 -0500 Subject: [PATCH] scsi_debug improve driver description in Kconfig Try to give a more accurate driver description and some extra useful information in less lines. --- drivers/scsi/Kconfig | 17 - 1 file changed, 8 insertions(+), 9 deletions(-) Signed-off-by: Douglas Gilbert dgilb...@interlog.com Reviewed-by: Ewan D. Milne emi...@redhat.com -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/5] scsi_debug: add Capacity Changed Unit Attention
On Mon, 2014-11-24 at 23:05 -0500, Douglas Gilbert wrote: From: Douglas Gilbert dgilb...@interlog.com Date: Mon, 24 Nov 2014 20:27:51 -0500 Subject: [PATCH 3/5] add Capacity Changed Unit Attention Via sysfs the virtual_gb scsi_debug parameter can be changed while LUs are in use. If that changes, the 'Capacity data has changed' Unit Attention is queued on all LUs. --- drivers/scsi/scsi_debug.c | 28 1 file changed, 24 insertions(+), 4 deletions(-) Signed-off-by: Douglas Gilbert dgilb...@interlog.com I found a couple of things with this patch that should be fixed, I'll send patches to correct them, plus a couple of other changes while I'm at it. -Ewan -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/4] scsi_debug: Unit Attention fixes/enhancements
From: Ewan D. Milne emi...@redhat.com This patch series fixes a couple of problems in the code to generate UAs when virtual_gb is changed, and adds the generation of a UA when max_luns is changed. It also adds the generation of a UA when a WRITE BUFFER command is issued. Patches were generated against jejb for-next branch, with Doug Gilbert's earlier patches applied. Ewan D. Milne (4): scsi_debug: Fixed missing break; in SDEBUG_UA_CAPACITY_CHANGED case scsi_debug: Added taking of sdebug_host_list_lock when changing capacity scsi_debug: Add REPORTED LUNS DATA HAS CHANGED Unit Attention scsi_debug: Implement WRITE BUFFER command drivers/scsi/scsi_debug.c | 131 -- 1 file changed, 128 insertions(+), 3 deletions(-) -- 1.7.11.7 -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] scsi_debug: Add REPORTED LUNS DATA HAS CHANGED Unit Attention
From: Ewan D. Milne emi...@redhat.com
Generate a REPORTED LUNS DATA HAS CHANGED Unit Attention if
sysfs max_luns is used to change the number of scsi_debug LUNs.
This is only done if scsi_debug_scsi_level is SPC-3 or above.
Additionally, implement SPC-4 behavior which only generates
this Unit Attention on the first LUN on the target to receive
a command after the change. This condition is cleared when
a REPORT LUNS command is received.
Signed-off-by: Ewan D. Milne emi...@redhat.com
---
drivers/scsi/scsi_debug.c | 56 ++-
1 file changed, 55 insertions(+), 1 deletion(-)
diff --git a/drivers/scsi/scsi_debug.c b/drivers/scsi/scsi_debug.c
index 1a11466..648abf2 100644
--- a/drivers/scsi/scsi_debug.c
+++ b/drivers/scsi/scsi_debug.c
@@ -80,6 +80,8 @@ static const char *scsi_debug_version_date = 20141022;
#define INVALID_FIELD_IN_PARAM_LIST 0x26
#define UA_RESET_ASC 0x29
#define UA_CHANGED_ASC 0x2a
+#define TARGET_CHANGED_ASC 0x3f
+#define LUNS_CHANGED_ASCQ 0x0e
#define INSUFF_RES_ASC 0x55
#define INSUFF_RES_ASCQ 0x3
#define POWER_ON_RESET_ASCQ 0x0
@@ -181,7 +183,8 @@ static const char *scsi_debug_version_date = 20141022;
#define SDEBUG_UA_BUS_RESET 1
#define SDEBUG_UA_MODE_CHANGED 2
#define SDEBUG_UA_CAPACITY_CHANGED 3
-#define SDEBUG_NUM_UAS 4
+#define SDEBUG_UA_LUNS_CHANGED 4
+#define SDEBUG_NUM_UAS 5
/* for check_readiness() */
#define UAS_ONLY 1 /* check for UAs only */
@@ -783,6 +786,22 @@ static int scsi_debug_ioctl(struct scsi_device *dev, int
cmd, void __user *arg)
/* return -ENOTTY; // correct return but upsets fdisk */
}
+static int clear_luns_changed_on_target(struct sdebug_dev_info *devip)
+{
+ struct sdebug_host_info *sdhp;
+ struct sdebug_dev_info *dp;
+
+ spin_lock(sdebug_host_list_lock);
+ list_for_each_entry(sdhp, sdebug_host_list, host_list) {
+ list_for_each_entry(dp, sdhp-dev_info_list, dev_list) {
+ if ((devip-sdbg_host == dp-sdbg_host)
+ (devip-target == dp-target))
+ clear_bit(SDEBUG_UA_LUNS_CHANGED, dp-uas_bm);
+ }
+ }
+ spin_unlock(sdebug_host_list_lock);
+}
+
static int check_readiness(struct scsi_cmnd *SCpnt, int uas_only,
struct sdebug_dev_info * devip)
{
@@ -818,6 +837,23 @@ static int check_readiness(struct scsi_cmnd *SCpnt, int
uas_only,
if (debug)
cp = capacity data changed;
break;
+ case SDEBUG_UA_LUNS_CHANGED:
+ /*
+* SPC-3 behavior is to report a UNIT ATTENTION with
+* ASC/ASCQ REPORTED LUNS DATA HAS CHANGED on every LUN
+* on the target, until a REPORT LUNS command is
+* received. SPC-4 behavior is to report it only once.
+* NOTE: scsi_debug_scsi_level does not use the same
+* values as struct scsi_device-scsi_level.
+*/
+ if (scsi_debug_scsi_level = 6) /* SPC-4 and above */
+ clear_luns_changed_on_target(devip);
+ mk_sense_buffer(SCpnt, UNIT_ATTENTION,
+ TARGET_CHANGED_ASC,
+ LUNS_CHANGED_ASCQ);
+ if (debug)
+ cp = reported luns data has changed;
+ break;
default:
pr_warn(%s: unexpected unit attention code=%d\n,
__func__, k);
@@ -3229,6 +3265,7 @@ static int resp_report_luns(struct scsi_cmnd * scp,
unsigned char arr[SDEBUG_RLUN_ARR_SZ];
unsigned char * max_addr;
+ clear_luns_changed_on_target(devip);
alloc_len = cmd[9] + (cmd[8] 8) + (cmd[7] 16) + (cmd[6] 24);
shortish = (alloc_len 4);
if (shortish || (select_report 2)) {
@@ -4369,10 +4406,27 @@ static ssize_t max_luns_store(struct device_driver
*ddp, const char *buf,
size_t count)
{
int n;
+ bool changed;
if ((count 0) (1 == sscanf(buf, %d, n)) (n = 0)) {
+ changed = (scsi_debug_max_luns != n);
scsi_debug_max_luns = n;
sdebug_max_tgts_luns();
+ if (changed (scsi_debug_scsi_level = 5)) { /* = SPC-3 */
+ struct sdebug_host_info *sdhp;
+ struct sdebug_dev_info *dp;
+
+ spin_lock(sdebug_host_list_lock);
+ list_for_each_entry(sdhp, sdebug_host_list,
+ host_list) {
+ list_for_each_entry(dp, sdhp-dev_info_list,
+ dev_list) {
+
[PATCH 2/4] scsi_debug: Added taking of sdebug_host_list_lock when changing capacity
From: Ewan D. Milne emi...@redhat.com
All other traversals of the sdebug_host_list take the lock.
Signed-off-by: Ewan D. Milne emi...@redhat.com
---
drivers/scsi/scsi_debug.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/scsi/scsi_debug.c b/drivers/scsi/scsi_debug.c
index 397cc10..1a11466 100644
--- a/drivers/scsi/scsi_debug.c
+++ b/drivers/scsi/scsi_debug.c
@@ -4439,6 +4439,7 @@ static ssize_t virtual_gb_store(struct device_driver
*ddp, const char *buf,
struct sdebug_host_info *sdhp;
struct sdebug_dev_info *dp;
+ spin_lock(sdebug_host_list_lock);
list_for_each_entry(sdhp, sdebug_host_list,
host_list) {
list_for_each_entry(dp, sdhp-dev_info_list,
@@ -4447,6 +4448,7 @@ static ssize_t virtual_gb_store(struct device_driver
*ddp, const char *buf,
dp-uas_bm);
}
}
+ spin_unlock(sdebug_host_list_lock);
}
return count;
}
--
1.7.11.7
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] scsi_debug: Implement WRITE BUFFER command
From: Ewan D. Milne emi...@redhat.com
Accept the WRITE BUFFER command and do nothing other than
set the appropriate microcode has been changed UA on the LU.
From an earlier patch by Doug Gilbert.
Signed-off-by: Ewan D. Milne emi...@redhat.com
---
drivers/scsi/scsi_debug.c | 74 +--
1 file changed, 71 insertions(+), 3 deletions(-)
diff --git a/drivers/scsi/scsi_debug.c b/drivers/scsi/scsi_debug.c
index 648abf2..5ac04d6 100644
--- a/drivers/scsi/scsi_debug.c
+++ b/drivers/scsi/scsi_debug.c
@@ -93,6 +93,8 @@ static const char *scsi_debug_version_date = 20141022;
#define THRESHOLD_EXCEEDED 0x5d
#define LOW_POWER_COND_ON 0x5e
#define MISCOMPARE_VERIFY_ASC 0x1d
+#define MICROCODE_CHANGED_ASCQ 0x1 /* with TARGET_CHANGED_ASC */
+#define MICROCODE_CHANGED_WO_RESET_ASCQ 0x16
/* Additional Sense Code Qualifier (ASCQ) */
#define ACK_NAK_TO 0x3
@@ -184,7 +186,9 @@ static const char *scsi_debug_version_date = 20141022;
#define SDEBUG_UA_MODE_CHANGED 2
#define SDEBUG_UA_CAPACITY_CHANGED 3
#define SDEBUG_UA_LUNS_CHANGED 4
-#define SDEBUG_NUM_UAS 5
+#define SDEBUG_UA_MICROCODE_CHANGED 5 /* simulate firmware change */
+#define SDEBUG_UA_MICROCODE_CHANGED_WO_RESET 6
+#define SDEBUG_NUM_UAS 7
/* for check_readiness() */
#define UAS_ONLY 1 /* check for UAs only */
@@ -330,6 +334,7 @@ static int resp_write_same_10(struct scsi_cmnd *, struct
sdebug_dev_info *);
static int resp_write_same_16(struct scsi_cmnd *, struct sdebug_dev_info *);
static int resp_xdwriteread_10(struct scsi_cmnd *, struct sdebug_dev_info *);
static int resp_comp_write(struct scsi_cmnd *, struct sdebug_dev_info *);
+static int resp_write_buffer(struct scsi_cmnd *, struct sdebug_dev_info *);
struct opcode_info_t {
u8 num_attached;/* 0 if this is it (i.e. a leaf); use 0xff
@@ -484,8 +489,9 @@ static const struct opcode_info_t
opcode_info_arr[SDEB_I_LAST_ELEMENT + 1] = {
{0, 0x53, 0, F_D_IN | F_D_OUT | FF_DIRECT_IO, resp_xdwriteread_10,
NULL, {10, 0xff, 0xff, 0xff, 0xff, 0xff, 0x1f, 0xff, 0xff, 0xc7,
0, 0, 0, 0, 0, 0} },
- {0, 0, 0, F_INV_OP | FF_RESPOND, NULL, NULL, /* WRITE_BUFFER */
- {0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0} },
+ {0, 0x3b, 0, F_D_OUT_MAYBE, resp_write_buffer, NULL,
+ {10, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xc7, 0, 0,
+0, 0, 0, 0} }, /* WRITE_BUFFER */
{1, 0x41, 0, F_D_OUT_MAYBE | FF_DIRECT_IO, resp_write_same_10,
write_same_iarr, {10, 0xff, 0xff, 0xff, 0xff, 0xff, 0x1f, 0xff,
0xff, 0xc7, 0, 0, 0, 0, 0, 0} },
@@ -837,6 +843,19 @@ static int check_readiness(struct scsi_cmnd *SCpnt, int
uas_only,
if (debug)
cp = capacity data changed;
break;
+ case SDEBUG_UA_MICROCODE_CHANGED:
+ mk_sense_buffer(SCpnt, UNIT_ATTENTION,
+TARGET_CHANGED_ASC, MICROCODE_CHANGED_ASCQ);
+ if (debug)
+ cp = microcode has been changed;
+ break;
+ case SDEBUG_UA_MICROCODE_CHANGED_WO_RESET:
+ mk_sense_buffer(SCpnt, UNIT_ATTENTION,
+ TARGET_CHANGED_ASC,
+ MICROCODE_CHANGED_WO_RESET_ASCQ);
+ if (debug)
+ cp = microcode has been changed without reset;
+ break;
case SDEBUG_UA_LUNS_CHANGED:
/*
* SPC-3 behavior is to report a UNIT ATTENTION with
@@ -3070,6 +3089,55 @@ resp_write_same_16(struct scsi_cmnd *scp, struct
sdebug_dev_info *devip)
return resp_write_same(scp, lba, num, ei_lba, unmap, ndob);
}
+/* Note the mode field is in the same position as the (lower) service action
+ * field. For the Report supported operation codes command, SPC-4 suggests
+ * each mode of this command should be reported separately; for future. */
+static int
+resp_write_buffer(struct scsi_cmnd *scp, struct sdebug_dev_info *devip)
+{
+ u8 *cmd = scp-cmnd;
+ struct scsi_device *sdp = scp-device;
+ struct sdebug_dev_info *dp;
+ u8 mode;
+
+ mode = cmd[1] 0x1f;
+ switch (mode) {
+ case 0x4: /* download microcode (MC) and activate (ACT) */
+ /* set UAs on this device only */
+ set_bit(SDEBUG_UA_BUS_RESET, devip-uas_bm);
+ set_bit(SDEBUG_UA_MICROCODE_CHANGED, devip-uas_bm);
+ break;
+ case 0x5: /* download MC, save and ACT */
+ set_bit(SDEBUG_UA_MICROCODE_CHANGED_WO_RESET, devip-uas_bm);
+ break;
+ case 0x6: /* download MC with offsets and ACT */
+ /* set UAs on most devices (LUs) in this
[PATCH 1/4] scsi_debug: Fixed missing break; in SDEBUG_UA_CAPACITY_CHANGED case
From: Ewan D. Milne emi...@redhat.com This eliminates a superfluous log message when the capacity is changed: check_readiness: unexpected unit attention code=3 Signed-off-by: Ewan D. Milne emi...@redhat.com --- drivers/scsi/scsi_debug.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/scsi/scsi_debug.c b/drivers/scsi/scsi_debug.c index aa4b6b8..397cc10 100644 --- a/drivers/scsi/scsi_debug.c +++ b/drivers/scsi/scsi_debug.c @@ -817,6 +817,7 @@ static int check_readiness(struct scsi_cmnd *SCpnt, int uas_only, UA_CHANGED_ASC, CAPACITY_CHANGED_ASCQ); if (debug) cp = capacity data changed; + break; default: pr_warn(%s: unexpected unit attention code=%d\n, __func__, k); -- 1.7.11.7 -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] scsi_scan: Send TEST UNIT READY to LUN0 before LUN scanning
-Original Message-
From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi-
ow...@vger.kernel.org] On Behalf Of Hannes Reinecke
Sent: Thursday, 04 December, 2014 10:39 AM
...
/**
+ * scsi_test_lun - waiting for a LUN to become ready
+ * @sdev:scsi_device to test
+ *
+ * Description:
+ * Wait for the lun associated with @sdev to become ready
+ *
+ * Send a TEST UNIT READY to detect any unit attention conditions.
+ * Retry TEST UNIT READY for up to @scsi_scan_timeout if the
+ * returned sense key is 02/04/01 (Not ready, Logical Unit is
+ * in process of becoming ready)
+ **/
+static int
+scsi_test_lun(struct scsi_device *sdev)
+{
+ struct scsi_sense_hdr sshdr;
+ int res = SCSI_SCAN_TARGET_PRESENT;
+ int tur_result;
+ unsigned long tur_timeout = jiffies + scsi_scan_timeout * HZ;
+
+ /* Skip for older devices */
+ if (sdev-scsi_level = SCSI_3)
+ return SCSI_SCAN_LUN_PRESENT;
+
+ /*
+ * Wait for the device to become ready.
+ *
+ * Some targets take some time before the firmware is
+ * fully initialized, during which time they might not
+ * be able to fill out any REPORT_LUN command correctly.
+ * And as we're not capable of handling the
+ * INQUIRY DATA CHANGED unit attention correctly we'd
+ * rather wait here.
+ */
+ do {
+ tur_result = scsi_test_unit_ready(sdev, SCSI_TIMEOUT,
+ 3, sshdr);
+ if (!tur_result) {
+ res = SCSI_SCAN_LUN_PRESENT;
+ break;
+ }
+ if ((driver_byte(tur_result) DRIVER_SENSE)
+ scsi_sense_valid(sshdr)) {
+ SCSI_LOG_SCAN_BUS(3, sdev_printk(KERN_INFO, sdev,
+ scsi_scan: tur returned %02x/%02x/%02x\n,
+ sshdr.sense_key, sshdr.asc, sshdr.ascq));
+ if (sshdr.sense_key == NOT_READY
+ sshdr.asc == 0x04 sshdr.ascq == 0x01) {
+ /* Logical Unit is in process
+ * of becoming ready */
+ msleep(100);
+ continue;
+ }
+ }
In SAS, you may see these after power on or after sending a
START STOP UNIT command with START=1, as the controller or
expander is performing staggered spinup:
04h/11h LOGICAL UNIT NOT READY, NOTIFY (ENABLE SPINUP) REQUIRED
Once the drive receives NOTIFY (ENABLE SPINUP), then it starts
reporting this until spinup is done:
04h/01h LOGICAL UNIT IS IN PROCESS OF BECOMING READY
If this function is intended for general wait for ready use,
then it should sit through both codes.
If this function is only intended for drives that violate the
rule to always be capable of returning REPORT LUNS data
indicating LUN 0, it's hard to guess if 04h/11h could also
appear.
---
Rob ElliottHP Server Storage
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Scst-devel] New qla2x00tgt Driver Question
Yes, we¹ll copy you. duane On 12/4/14, 8:21 AM, Dr. Greg Wettstein g...@wind.enjellic.com wrote: On Dec 3, 11:38pm, Duane Grigsby wrote: } Subject: Re: [Scst-devel] New qla2x00tgt Driver Question Hi Greg, Hi Duane, hope your day is starting out well. I looked at your logs and also reviewed the PLOGI handling in Trunk-SCST.15. We found a issue with PLOGI/PRLI cleanup handling that I'm addressing. Whatever fixes will get pushed upstream with the qla2xxx and scst-qla2xxx.git. Very good, I'm glad we were able to cast some illumination on this issue. If you could copy me on the fix I would be happy to roll it into the 3.10.x branch which we maintain for all of our storage infrastructure and put it into our test harness. I'm sure you saw the note from Vlad in which he feels the deferred ABORT messages we are seeing before a block device goes offline during NEXUS_LOSS_SESS handling have nothing to do with SCST SCSI core. Hopefully your fix will address whatever is getting lost in the shuffle on that front. Once we get that issue addressed we will put the fix into a second test harness to see if it addresses the holy grail of all this which is the catastrophic VMFS corruption which we have documented on adapter resets. duane Best wishes for a productive afternoon. Greg }-- End of excerpt from Duane Grigsby As always, Dr. G.W. Wettstein, Ph.D. Enjellic Systems Development, LLC. 4206 N. 19th Ave. Specializing in information infra-structure Fargo, ND 58102development. PH: 701-281-1686 FAX: 701-281-3949 EMAIL: g...@enjellic.com -- Sweeny's Law: The length of a progress report is inversely proportional to the amount of progress. attachment: winmail.dat
Re: [PATCH qla2xxx] Race in handling rport deletion in Qlogic driver during recovery causes panic
On Thu, 4 Dec 2014, Christoph Hellwig wrote: On Tue, Nov 25, 2014 at 09:16:42AM -0500, Laurence Oberman wrote: When we have an rport disconnect we race during rport deletion and re-connection resulting in a panic. When we do this, we call fc_remote_port_del() just before we do the calls to re-establish the session with the FC transport with fc_remote_port_add() and then fc_remote_port_rolechg(). If we remove the call to fc_remote_port_del() before re-establishing the connection this prevents the race. This patch has resolved this for multiple customers via test kernels. Suggested by Chad Dupuis, implemented and tested by Laurence Oberman. Chad, can you review this one? Or do you plan to send it to me with the next qla2xxx update? Note that the 3.19 merge window is about to end. This looks good. Thanks. Acked-by: Chad Dupuis chad.dup...@qlogic.com -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] scsi_scan: Send TEST UNIT READY to LUN0 before LUN scanning
On Thu, 2014-12-04 at 17:39 +0100, Hannes Reinecke wrote:
[...]
diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c
index 0af7133..ca39e32 100644
--- a/drivers/scsi/scsi_scan.c
+++ b/drivers/scsi/scsi_scan.c
@@ -119,6 +119,13 @@ MODULE_PARM_DESC(inq_timeout,
Timeout (in seconds) waiting for devices to answer INQUIRY.
Default is 20. Some devices may need more; most need less.);
+static unsigned int scsi_scan_timeout = SCSI_TIMEOUT/HZ + 58;
+
+module_param_named(scan_timeout, scsi_scan_timeout, uint, S_IRUGO|S_IWUSR);
+MODULE_PARM_DESC(scan_timeout,
+ Timeout (in seconds) waiting for devices to become ready
+ after INQUIRY. Default is 60.);
+
/* This lock protects only this list */
static DEFINE_SPINLOCK(async_scan_lock);
static LIST_HEAD(scanning_hosts);
@@ -719,19 +726,6 @@ static int scsi_probe_lun(struct scsi_device *sdev,
unsigned char *inq_result,
}
/*
- * Related to the above issue:
- *
- * XXX Devices (disk or all?) should be sent a TEST UNIT READY,
- * and if not ready, sent a START_STOP to start (maybe spin up) and
- * then send the INQUIRY again, since the INQUIRY can change after
- * a device is initialized.
You're not sending a start_stop unit, so why is this being deleted? Any
unstarted unit will still return initialization command required and may
or may not return lun data.
- *
- * Ideally, start a device if explicitly asked to do so. This
- * assumes that a device is spun up on power on, spun down on
- * request, and then spun up on request.
- */
-
- /*
* The scanning code needs to know the scsi_level, even if no
* device is attached at LUN 0 (SCSI_SCAN_TARGET_PRESENT) so
* non-zero LUNs can be scanned.
@@ -756,6 +750,65 @@ static int scsi_probe_lun(struct scsi_device *sdev,
unsigned char *inq_result,
}
/**
+ * scsi_test_lun - waiting for a LUN to become ready
+ * @sdev:scsi_device to test
+ *
+ * Description:
+ * Wait for the lun associated with @sdev to become ready
+ *
+ * Send a TEST UNIT READY to detect any unit attention conditions.
+ * Retry TEST UNIT READY for up to @scsi_scan_timeout if the
+ * returned sense key is 02/04/01 (Not ready, Logical Unit is
+ * in process of becoming ready)
+ **/
+static int
+scsi_test_lun(struct scsi_device *sdev)
+{
+ struct scsi_sense_hdr sshdr;
+ int res = SCSI_SCAN_TARGET_PRESENT;
+ int tur_result;
+ unsigned long tur_timeout = jiffies + scsi_scan_timeout * HZ;
+
+ /* Skip for older devices */
+ if (sdev-scsi_level = SCSI_3)
+ return SCSI_SCAN_LUN_PRESENT;
+
+ /*
+ * Wait for the device to become ready.
+ *
+ * Some targets take some time before the firmware is
+ * fully initialized, during which time they might not
+ * be able to fill out any REPORT_LUN command correctly.
+ * And as we're not capable of handling the
+ * INQUIRY DATA CHANGED unit attention correctly we'd
+ * rather wait here.
Can't we just fix that? All you need is rescan to re-read the inquiry
data.
+ */
+ do {
+ tur_result = scsi_test_unit_ready(sdev, SCSI_TIMEOUT,
+ 3, sshdr);
+ if (!tur_result) {
+ res = SCSI_SCAN_LUN_PRESENT;
+ break;
+ }
+ if ((driver_byte(tur_result) DRIVER_SENSE)
+ scsi_sense_valid(sshdr)) {
+ SCSI_LOG_SCAN_BUS(3, sdev_printk(KERN_INFO, sdev,
+ scsi_scan: tur returned %02x/%02x/%02x\n,
+ sshdr.sense_key, sshdr.asc, sshdr.ascq));
If we're waiting 60s and coming in here every 100ms we'll get 600 of
these in the log ... that's going to drown out anything that came before
it.
+ if (sshdr.sense_key == NOT_READY
+ sshdr.asc == 0x04 sshdr.ascq == 0x01) {
+ /* Logical Unit is in process
+ * of becoming ready */
+ msleep(100);
+ continue;
+ }
+ }
+ res = SCSI_SCAN_LUN_PRESENT;
Aren't you missing a break here? Otherwise how does an unexpected
return code from the test unit ready do anything other than loop around
dumping log messages until 60s have expired.
+ } while (time_before_eq(jiffies, tur_timeout));
+ return res;
+}
+
+/**
* scsi_add_lun - allocate and fully initialze a scsi_device
* @sdev:holds information to be stored in the new scsi_device
* @inq_result: holds the result of a previous INQUIRY to the LUN
@@ -1159,6 +1212,15 @@ static int scsi_probe_and_add_lun(struct scsi_target
*starget,
Re: [PATCH 2/4] [SCSI] Blacklist RSOC for Microsoft iSCSI target devices
On 12/3/14, 8:18 PM, Martin K. Petersen wrote:
The Microsoft iSCSI target does not support REPORT SUPPORTED OPERATION
CODES. Blacklist these devices so we don't attempt to send the command.
Signed-off-by: Martin K. Petersen martin.peter...@oracle.com
Reported-by: j...@deti74.ru
Cc: Mike Christie micha...@cs.wisc.edu
Cc: sta...@vger.kernel.org # v3.10+
---
drivers/scsi/scsi_devinfo.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/scsi/scsi_devinfo.c b/drivers/scsi/scsi_devinfo.c
index 8c228e049bb6..db42c37e1230 100644
--- a/drivers/scsi/scsi_devinfo.c
+++ b/drivers/scsi/scsi_devinfo.c
@@ -210,6 +210,7 @@ static struct {
{Medion, Flash XL MMC/SD, 2.6D, BLIST_FORCELUN},
{MegaRAID, LD, NULL, BLIST_FORCELUN},
{MICROP, 4110, NULL, BLIST_NOTQ},
+ {MSFT, Virtual HD, NULL, BLIST_NO_RSOC},
{MYLEX, DACARMRB, *, BLIST_REPORTLUN2},
{nCipher, Fastness Crypto, NULL, BLIST_FORCELUN},
{NAKAMICH, MJ-4.8S, NULL, BLIST_FORCELUN | BLIST_SINGLELUN},
Thanks Martin.
Tested-by: Mike Christie micha...@cs.wisc.edu
In case other people test this patch, I wanted to warn people that the
MS iSCSI target does the same sequence (sends reject PDU then drops the
connection on us) for any command it does not support. We end up seeing
the same problem for other commands. For example, some distros have
tools that send CDB 0x85 during initialization, and the MS target will
fail on that in the same way we saw here.
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] [SCSI] Blacklist RSOC for Microsoft iSCSI target devices
Mike == Mike Christie micha...@cs.wisc.edu writes: Mike In case other people test this patch, I wanted to warn people that Mike the MS iSCSI target does the same sequence (sends reject PDU then Mike drops the connection on us) for any command it does not Mike support. We end up seeing the same problem for other commands. Ick. Have you pinged MS about this again recently? Doesn't sound like we'd be the only ones tripping over something like this. -- Martin K. Petersen Oracle Linux Engineering -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Scst-devel] New qla2x00tgt Driver Question
Dr. Greg Wettstein wrote on 12/03/2014 11:42 PM: On Dec 3, 8:59pm, Vladislav Bolkhovitin wrote: } Subject: Re: [Scst-devel] New qla2x00tgt Driver Question Dr. Greg Wettstein wrote on 12/03/2014 12:46 PM: Secondly, Vlad, we have been running additional testing for the last two days and we have logs from the SCST core which I am including below which suggests that the SCST core target code excessively stalls or mishandles an ABORT while processing a NEXUS_LOSS_SESS TMF. Regardless of your feelings about the target driver code in the kernel we need to make sure there is not some subtle regression in the core SCST code paths during TMF processing. I don't see any problem on the SCST core level in the logs. Fair enough, thanks for taking a look. I though it was somewhat strange to see deferred ABORT's on I/O being done to RAM based block devices as there is little or no I/O latency. In our testing, this regression always occurs on TMF function 6 processing and this was also the case in Marc's report. The comment that one of the other posters made that this was secondary to slow backstorage didn't match the characteristics of our test environment. For TM processing backend and frontend (target) sides are equal, so the longest side processing is what that defines your TM processing time. Vlad -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] scsi_scan: Send TEST UNIT READY to LUN0 before LUN scanning
On 12/04/2014 09:00 PM, Elliott, Robert (Server Storage) wrote:
-Original Message-
From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi-
ow...@vger.kernel.org] On Behalf Of Hannes Reinecke
Sent: Thursday, 04 December, 2014 10:39 AM
...
/**
+ * scsi_test_lun - waiting for a LUN to become ready
+ * @sdev: scsi_device to test
+ *
+ * Description:
+ * Wait for the lun associated with @sdev to become ready
+ *
+ * Send a TEST UNIT READY to detect any unit attention conditions.
+ * Retry TEST UNIT READY for up to @scsi_scan_timeout if the
+ * returned sense key is 02/04/01 (Not ready, Logical Unit is
+ * in process of becoming ready)
+ **/
+static int
+scsi_test_lun(struct scsi_device *sdev)
+{
+struct scsi_sense_hdr sshdr;
+int res = SCSI_SCAN_TARGET_PRESENT;
+int tur_result;
+unsigned long tur_timeout = jiffies + scsi_scan_timeout * HZ;
+
+/* Skip for older devices */
+if (sdev-scsi_level = SCSI_3)
+return SCSI_SCAN_LUN_PRESENT;
+
+/*
+ * Wait for the device to become ready.
+ *
+ * Some targets take some time before the firmware is
+ * fully initialized, during which time they might not
+ * be able to fill out any REPORT_LUN command correctly.
+ * And as we're not capable of handling the
+ * INQUIRY DATA CHANGED unit attention correctly we'd
+ * rather wait here.
+ */
+do {
+tur_result = scsi_test_unit_ready(sdev, SCSI_TIMEOUT,
+ 3, sshdr);
+if (!tur_result) {
+res = SCSI_SCAN_LUN_PRESENT;
+break;
+}
+if ((driver_byte(tur_result) DRIVER_SENSE)
+scsi_sense_valid(sshdr)) {
+SCSI_LOG_SCAN_BUS(3, sdev_printk(KERN_INFO, sdev,
+scsi_scan: tur returned %02x/%02x/%02x\n,
+sshdr.sense_key, sshdr.asc, sshdr.ascq));
+if (sshdr.sense_key == NOT_READY
+sshdr.asc == 0x04 sshdr.ascq == 0x01) {
+/* Logical Unit is in process
+ * of becoming ready */
+msleep(100);
+continue;
+}
+}
In SAS, you may see these after power on or after sending a
START STOP UNIT command with START=1, as the controller or
expander is performing staggered spinup:
04h/11h LOGICAL UNIT NOT READY, NOTIFY (ENABLE SPINUP) REQUIRED
Once the drive receives NOTIFY (ENABLE SPINUP), then it starts
reporting this until spinup is done:
04h/01h LOGICAL UNIT IS IN PROCESS OF BECOMING READY
If this function is intended for general wait for ready use,
then it should sit through both codes.
If this function is only intended for drives that violate the
rule to always be capable of returning REPORT LUNS data
indicating LUN 0, it's hard to guess if 04h/11h could also
appear.
Oh, but the point is they do _NOT_ violate the rule.
They follow SAM to the letter, and return a dummy LUN inventory with
just LUN0. Once the firmware is ready it sets an 'REPORT LUN DATA
CHANGED' UA. But the SCSI stack never acts on that UA,
and the subsequent LUNs will never scanned.
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries Storage
h...@suse.de +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 21284 (AG Nürnberg)
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
