Re: [PATCH v2 3/3] arcmsr: changes driver version number
On 11/25/2015 04:40 AM, Ching Huang wrote: > From: Ching Huang > > Changes driver version number. > > Signed-of-by: Ching Huang > > --- > > diff -uprN a/drivers/scsi/arcmsr/arcmsr.h b/drivers/scsi/arcmsr/arcmsr.h > --- a/drivers/scsi/arcmsr/arcmsr.h2015-11-25 10:52:13.33447 +0800 > +++ b/drivers/scsi/arcmsr/arcmsr.h2015-10-19 15:57:08.0 +0800 > @@ -52,7 +52,7 @@ struct device_attribute; > #define ARCMSR_MAX_FREECCB_NUM 320 > #define ARCMSR_MAX_OUTSTANDING_CMD 255 > #endif > -#define ARCMSR_DRIVER_VERSION"v1.30.00.04-20140919" > +#define ARCMSR_DRIVER_VERSION"v1.30.00.21-20151019" > #define ARCMSR_SCSI_INITIATOR_ID > 255 > #define ARCMSR_MAX_XFER_SECTORS > 512 > #define ARCMSR_MAX_XFER_SECTORS_B > 4096 > > Reviewed-by: Hannes Reinecke Cheers, Hannes -- Dr. Hannes ReineckezSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton 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 v2 2/3] arcmsr: adds code for support areca new adapter ARC1203
On 11/25/2015 04:25 AM, Ching Huang wrote:
> From: Ching Huang
>
> Support areca new PCIe to SATA RAID adapter ARC1203
>
> Signed-of-by: Ching Huang
>
> ---
>
> diff -uprN a/drivers/scsi/arcmsr/arcmsr.h b/drivers/scsi/arcmsr/arcmsr.h
> --- a/drivers/scsi/arcmsr/arcmsr.h2015-11-25 10:52:16.28647 +0800
> +++ b/drivers/scsi/arcmsr/arcmsr.h2015-11-25 10:52:13.33447 +0800
> @@ -74,6 +74,9 @@ struct device_attribute;
> #ifndef PCI_DEVICE_ID_ARECA_1214
> #define PCI_DEVICE_ID_ARECA_12140x1214
> #endif
> +#ifndef PCI_DEVICE_ID_ARECA_1203
> + #define PCI_DEVICE_ID_ARECA_12030x1203
> +#endif
> /*
>
> **
> **
> @@ -245,6 +248,12 @@ struct FIRMWARE_INFO
> /* window of "instruction flags" from iop to driver */
> #define ARCMSR_IOP2DRV_DOORBELL 0x00020408
> #define ARCMSR_IOP2DRV_DOORBELL_MASK 0x0002040C
> +/* window of "instruction flags" from iop to driver */
> +#define ARCMSR_IOP2DRV_DOORBELL_1203 0x00021870
> +#define ARCMSR_IOP2DRV_DOORBELL_MASK_1203 0x00021874
> +/* window of "instruction flags" from driver to iop */
> +#define ARCMSR_DRV2IOP_DOORBELL_1203 0x00021878
> +#define ARCMSR_DRV2IOP_DOORBELL_MASK_1203 0x0002187C
> /* ARECA FLAG LANGUAGE */
> /* ioctl transfer */
> #define ARCMSR_IOP2DRV_DATA_WRITE_OK 0x0001
> diff -uprN a/drivers/scsi/arcmsr/arcmsr_hba.c
> b/drivers/scsi/arcmsr/arcmsr_hba.c
> --- a/drivers/scsi/arcmsr/arcmsr_hba.c2015-11-24 11:35:26.0
> +0800
> +++ b/drivers/scsi/arcmsr/arcmsr_hba.c2015-11-24 18:58:40.640226000
> +0800
> @@ -114,6 +114,7 @@ static void arcmsr_hardware_reset(struct
> static const char *arcmsr_info(struct Scsi_Host *);
> static irqreturn_t arcmsr_interrupt(struct AdapterControlBlock *acb);
> static void arcmsr_free_irq(struct pci_dev *, struct AdapterControlBlock *);
> +static void arcmsr_wait_firmware_ready(struct AdapterControlBlock *acb);
> static int arcmsr_adjust_disk_queue_depth(struct scsi_device *sdev, int
> queue_depth)
> {
> if (queue_depth > ARCMSR_MAX_CMD_PERLUN)
> @@ -157,6 +158,8 @@ static struct pci_device_id arcmsr_devic
> .driver_data = ACB_ADAPTER_TYPE_B},
> {PCI_DEVICE(PCI_VENDOR_ID_ARECA, PCI_DEVICE_ID_ARECA_1202),
> .driver_data = ACB_ADAPTER_TYPE_B},
> + {PCI_DEVICE(PCI_VENDOR_ID_ARECA, PCI_DEVICE_ID_ARECA_1203),
> + .driver_data = ACB_ADAPTER_TYPE_B},
> {PCI_DEVICE(PCI_VENDOR_ID_ARECA, PCI_DEVICE_ID_ARECA_1210),
> .driver_data = ACB_ADAPTER_TYPE_A},
> {PCI_DEVICE(PCI_VENDOR_ID_ARECA, PCI_DEVICE_ID_ARECA_1214),
> @@ -2621,7 +2624,7 @@ static bool arcmsr_hbaA_get_config(struc
> }
> static bool arcmsr_hbaB_get_config(struct AdapterControlBlock *acb)
> {
> - struct MessageUnit_B *reg = acb->pmuB;
> + struct MessageUnit_B *reg;
> struct pci_dev *pdev = acb->pdev;
> void *dma_coherent;
> dma_addr_t dma_coherent_handle;
> @@ -2649,10 +2652,17 @@ static bool arcmsr_hbaB_get_config(struc
> acb->dma_coherent2 = dma_coherent;
> reg = (struct MessageUnit_B *)dma_coherent;
> acb->pmuB = reg;
> - reg->drv2iop_doorbell= (uint32_t __iomem *)((unsigned
> long)acb->mem_base0 + ARCMSR_DRV2IOP_DOORBELL);
> - reg->drv2iop_doorbell_mask = (uint32_t __iomem *)((unsigned
> long)acb->mem_base0 + ARCMSR_DRV2IOP_DOORBELL_MASK);
> - reg->iop2drv_doorbell = (uint32_t __iomem *)((unsigned
> long)acb->mem_base0 + ARCMSR_IOP2DRV_DOORBELL);
> - reg->iop2drv_doorbell_mask = (uint32_t __iomem *)((unsigned
> long)acb->mem_base0 + ARCMSR_IOP2DRV_DOORBELL_MASK);
> + if (acb->pdev->device == PCI_DEVICE_ID_ARECA_1203) {
> + reg->drv2iop_doorbell = (uint32_t __iomem *)((unsigned
> long)acb->mem_base0 + ARCMSR_DRV2IOP_DOORBELL_1203);
> + reg->drv2iop_doorbell_mask = (uint32_t __iomem *)((unsigned
> long)acb->mem_base0 + ARCMSR_DRV2IOP_DOORBELL_MASK_1203);
> + reg->iop2drv_doorbell = (uint32_t __iomem *)((unsigned
> long)acb->mem_base0 + ARCMSR_IOP2DRV_DOORBELL_1203);
> + reg->iop2drv_doorbell_mask = (uint32_t __iomem *)((unsigned
> long)acb->mem_base0 + ARCMSR_IOP2DRV_DOORBELL_MASK_1203);
> + } else {
> + reg->drv2iop_doorbell= (uint32_t __iomem *)((unsigned
> long)acb->mem_base0 + ARCMSR_DRV2IOP_DOORBELL);
> + reg->drv2iop_doorbell_mask = (uint32_t __iomem *)((unsigned
> long)acb->mem_base0 + ARCMSR_DRV2IOP_DOORBELL_MASK);
> + reg->iop2drv_doorbell = (uint32_t __iomem *)((unsigned
> long)acb->mem_base0 + ARCMSR_IOP2DRV_DOORBELL);
> + reg->iop2drv_doorbell_mask = (uint32_t __iomem *)((unsigned
> long)acb->mem_base0 + ARCMSR_IOP2DRV_DOORBELL_MASK);
> + }
> reg->message_wbuffer = (uint32_t __iomem *)((unsigned
> long)acb->mem_base1 + ARCMSR_M
Re: [PATCH v2 1/3] arcmsr: fixed getting wrong configuration data
On 11/25/2015 04:21 AM, Ching Huang wrote: > From: Ching Huang > > Fixed getting wrong configuration data of adapter type B and type D. > > Signed-of-by: Ching Huang > > --- Reviewed-by: Hannes Reinecke Cheers, Hannes -- Dr. Hannes ReineckezSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton 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 2/9] IB: add a proper completion queue abstraction
On Tue, Nov 24, 2015 at 06:47:14PM -0800, Caitlin Bestler wrote: > Acknowledge packet for the last packet of the request has been > committed to the wire (including the appropriate fields for RDMA > READ response). > The target side cannot generate a response before it receives the request. > The target side verbs cannot generate the completion before the acknowledge > packet has been > committed to the wire. Sure, but, I keep saying this, the responder behavior is largely irrelevant to what the target is able/required to do. > Therefore the initiating side cannot receive a response before the write > operation has completed. Wrong. The ladder diagram would be Requestor Responder Responder Verbs SEND1 ---> Process X- ACK (lost) > recv1 CQ <--- send2 WQE recv2 CQE < SEND2 Packet [..] send1 CQE < ACK (resent) The Ack may be lost, causing the send CQE to arrive after the recv CQE, even though the responder did everything in a specific order. The fundamental issue is that the responder cannot detect the lost ACK. The PSN of the ACK packet is part of the Requestor's PSN space, not part of the Responders: 9.7.5.1.1 GENERATING PSNs FOR ACKNOWLEDGE MESSAGES C9-95: For responses to SEND requests or RDMA WRITE requests the responder shall insert in the PSN field of the response the PSN of the most recent request packet being acknowledged. Or stated another way, the value of the AckReq bit in SEND1 has no impact on the contents of the SEND2 packet - thus there is no way for the requestor to detect the loss of the ACK and hold off delivering recv2 CQE. Jason -- 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 3/3] arcmsr: changes driver version number
From: Ching Huang Changes driver version number. Signed-of-by: Ching Huang --- diff -uprN a/drivers/scsi/arcmsr/arcmsr.h b/drivers/scsi/arcmsr/arcmsr.h --- a/drivers/scsi/arcmsr/arcmsr.h 2015-11-25 10:52:13.33447 +0800 +++ b/drivers/scsi/arcmsr/arcmsr.h 2015-10-19 15:57:08.0 +0800 @@ -52,7 +52,7 @@ struct device_attribute; #define ARCMSR_MAX_FREECCB_NUM 320 #define ARCMSR_MAX_OUTSTANDING_CMD 255 #endif -#define ARCMSR_DRIVER_VERSION "v1.30.00.04-20140919" +#define ARCMSR_DRIVER_VERSION "v1.30.00.21-20151019" #define ARCMSR_SCSI_INITIATOR_ID 255 #define ARCMSR_MAX_XFER_SECTORS 512 #define ARCMSR_MAX_XFER_SECTORS_B 4096 -- 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 2/3] arcmsr: adds code for support areca new adapter ARC1203
From: Ching Huang
Support areca new PCIe to SATA RAID adapter ARC1203
Signed-of-by: Ching Huang
---
diff -uprN a/drivers/scsi/arcmsr/arcmsr.h b/drivers/scsi/arcmsr/arcmsr.h
--- a/drivers/scsi/arcmsr/arcmsr.h 2015-11-25 10:52:16.28647 +0800
+++ b/drivers/scsi/arcmsr/arcmsr.h 2015-11-25 10:52:13.33447 +0800
@@ -74,6 +74,9 @@ struct device_attribute;
#ifndef PCI_DEVICE_ID_ARECA_1214
#define PCI_DEVICE_ID_ARECA_12140x1214
#endif
+#ifndef PCI_DEVICE_ID_ARECA_1203
+ #define PCI_DEVICE_ID_ARECA_12030x1203
+#endif
/*
**
**
@@ -245,6 +248,12 @@ struct FIRMWARE_INFO
/* window of "instruction flags" from iop to driver */
#define ARCMSR_IOP2DRV_DOORBELL 0x00020408
#define ARCMSR_IOP2DRV_DOORBELL_MASK 0x0002040C
+/* window of "instruction flags" from iop to driver */
+#define ARCMSR_IOP2DRV_DOORBELL_1203 0x00021870
+#define ARCMSR_IOP2DRV_DOORBELL_MASK_1203 0x00021874
+/* window of "instruction flags" from driver to iop */
+#define ARCMSR_DRV2IOP_DOORBELL_1203 0x00021878
+#define ARCMSR_DRV2IOP_DOORBELL_MASK_1203 0x0002187C
/* ARECA FLAG LANGUAGE */
/* ioctl transfer */
#define ARCMSR_IOP2DRV_DATA_WRITE_OK 0x0001
diff -uprN a/drivers/scsi/arcmsr/arcmsr_hba.c b/drivers/scsi/arcmsr/arcmsr_hba.c
--- a/drivers/scsi/arcmsr/arcmsr_hba.c 2015-11-24 11:35:26.0 +0800
+++ b/drivers/scsi/arcmsr/arcmsr_hba.c 2015-11-24 18:58:40.640226000 +0800
@@ -114,6 +114,7 @@ static void arcmsr_hardware_reset(struct
static const char *arcmsr_info(struct Scsi_Host *);
static irqreturn_t arcmsr_interrupt(struct AdapterControlBlock *acb);
static void arcmsr_free_irq(struct pci_dev *, struct AdapterControlBlock *);
+static void arcmsr_wait_firmware_ready(struct AdapterControlBlock *acb);
static int arcmsr_adjust_disk_queue_depth(struct scsi_device *sdev, int
queue_depth)
{
if (queue_depth > ARCMSR_MAX_CMD_PERLUN)
@@ -157,6 +158,8 @@ static struct pci_device_id arcmsr_devic
.driver_data = ACB_ADAPTER_TYPE_B},
{PCI_DEVICE(PCI_VENDOR_ID_ARECA, PCI_DEVICE_ID_ARECA_1202),
.driver_data = ACB_ADAPTER_TYPE_B},
+ {PCI_DEVICE(PCI_VENDOR_ID_ARECA, PCI_DEVICE_ID_ARECA_1203),
+ .driver_data = ACB_ADAPTER_TYPE_B},
{PCI_DEVICE(PCI_VENDOR_ID_ARECA, PCI_DEVICE_ID_ARECA_1210),
.driver_data = ACB_ADAPTER_TYPE_A},
{PCI_DEVICE(PCI_VENDOR_ID_ARECA, PCI_DEVICE_ID_ARECA_1214),
@@ -2621,7 +2624,7 @@ static bool arcmsr_hbaA_get_config(struc
}
static bool arcmsr_hbaB_get_config(struct AdapterControlBlock *acb)
{
- struct MessageUnit_B *reg = acb->pmuB;
+ struct MessageUnit_B *reg;
struct pci_dev *pdev = acb->pdev;
void *dma_coherent;
dma_addr_t dma_coherent_handle;
@@ -2649,10 +2652,17 @@ static bool arcmsr_hbaB_get_config(struc
acb->dma_coherent2 = dma_coherent;
reg = (struct MessageUnit_B *)dma_coherent;
acb->pmuB = reg;
- reg->drv2iop_doorbell= (uint32_t __iomem *)((unsigned
long)acb->mem_base0 + ARCMSR_DRV2IOP_DOORBELL);
- reg->drv2iop_doorbell_mask = (uint32_t __iomem *)((unsigned
long)acb->mem_base0 + ARCMSR_DRV2IOP_DOORBELL_MASK);
- reg->iop2drv_doorbell = (uint32_t __iomem *)((unsigned
long)acb->mem_base0 + ARCMSR_IOP2DRV_DOORBELL);
- reg->iop2drv_doorbell_mask = (uint32_t __iomem *)((unsigned
long)acb->mem_base0 + ARCMSR_IOP2DRV_DOORBELL_MASK);
+ if (acb->pdev->device == PCI_DEVICE_ID_ARECA_1203) {
+ reg->drv2iop_doorbell = (uint32_t __iomem *)((unsigned
long)acb->mem_base0 + ARCMSR_DRV2IOP_DOORBELL_1203);
+ reg->drv2iop_doorbell_mask = (uint32_t __iomem *)((unsigned
long)acb->mem_base0 + ARCMSR_DRV2IOP_DOORBELL_MASK_1203);
+ reg->iop2drv_doorbell = (uint32_t __iomem *)((unsigned
long)acb->mem_base0 + ARCMSR_IOP2DRV_DOORBELL_1203);
+ reg->iop2drv_doorbell_mask = (uint32_t __iomem *)((unsigned
long)acb->mem_base0 + ARCMSR_IOP2DRV_DOORBELL_MASK_1203);
+ } else {
+ reg->drv2iop_doorbell= (uint32_t __iomem *)((unsigned
long)acb->mem_base0 + ARCMSR_DRV2IOP_DOORBELL);
+ reg->drv2iop_doorbell_mask = (uint32_t __iomem *)((unsigned
long)acb->mem_base0 + ARCMSR_DRV2IOP_DOORBELL_MASK);
+ reg->iop2drv_doorbell = (uint32_t __iomem *)((unsigned
long)acb->mem_base0 + ARCMSR_IOP2DRV_DOORBELL);
+ reg->iop2drv_doorbell_mask = (uint32_t __iomem *)((unsigned
long)acb->mem_base0 + ARCMSR_IOP2DRV_DOORBELL_MASK);
+ }
reg->message_wbuffer = (uint32_t __iomem *)((unsigned
long)acb->mem_base1 + ARCMSR_MESSAGE_WBUFFER);
reg->message_rbuffer = (uint32_t __iomem *)((unsigned
long)acb->mem_base1 + ARCMSR_MESSAGE_RBUFFER);
reg->message_rwbuffer = (uint32_t __iomem *)((unsi
[PATCH v2 1/3] arcmsr: fixed getting wrong configuration data
From: Ching Huang
Fixed getting wrong configuration data of adapter type B and type D.
Signed-of-by: Ching Huang
---
diff -uprN a/drivers/scsi/arcmsr/arcmsr_hba.c b/drivers/scsi/arcmsr/arcmsr_hba.c
--- a/drivers/scsi/arcmsr/arcmsr_hba.c 2015-11-23 16:25:22.0 +0800
+++ b/drivers/scsi/arcmsr/arcmsr_hba.c 2015-11-24 11:35:26.0 +0800
@@ -2694,15 +2694,15 @@ static bool arcmsr_hbaB_get_config(struc
acb->firm_model,
acb->firm_version);
- acb->signature = readl(®->message_rwbuffer[1]);
+ acb->signature = readl(®->message_rwbuffer[0]);
/*firm_signature,1,00-03*/
- acb->firm_request_len = readl(®->message_rwbuffer[2]);
+ acb->firm_request_len = readl(®->message_rwbuffer[1]);
/*firm_request_len,1,04-07*/
- acb->firm_numbers_queue = readl(®->message_rwbuffer[3]);
+ acb->firm_numbers_queue = readl(®->message_rwbuffer[2]);
/*firm_numbers_queue,2,08-11*/
- acb->firm_sdram_size = readl(®->message_rwbuffer[4]);
+ acb->firm_sdram_size = readl(®->message_rwbuffer[3]);
/*firm_sdram_size,3,12-15*/
- acb->firm_hd_channels = readl(®->message_rwbuffer[5]);
+ acb->firm_hd_channels = readl(®->message_rwbuffer[4]);
/*firm_ide_channels,4,16-19*/
acb->firm_cfg_version = readl(®->message_rwbuffer[25]);
/*firm_cfg_version,25,100-103*/
/*firm_ide_channels,4,16-19*/
@@ -2880,15 +2880,15 @@ static bool arcmsr_hbaD_get_config(struc
iop_device_map++;
count--;
}
- acb->signature = readl(®->msgcode_rwbuffer[1]);
+ acb->signature = readl(®->msgcode_rwbuffer[0]);
/*firm_signature,1,00-03*/
- acb->firm_request_len = readl(®->msgcode_rwbuffer[2]);
+ acb->firm_request_len = readl(®->msgcode_rwbuffer[1]);
/*firm_request_len,1,04-07*/
- acb->firm_numbers_queue = readl(®->msgcode_rwbuffer[3]);
+ acb->firm_numbers_queue = readl(®->msgcode_rwbuffer[2]);
/*firm_numbers_queue,2,08-11*/
- acb->firm_sdram_size = readl(®->msgcode_rwbuffer[4]);
+ acb->firm_sdram_size = readl(®->msgcode_rwbuffer[3]);
/*firm_sdram_size,3,12-15*/
- acb->firm_hd_channels = readl(®->msgcode_rwbuffer[5]);
+ acb->firm_hd_channels = readl(®->msgcode_rwbuffer[4]);
/*firm_hd_channels,4,16-19*/
acb->firm_cfg_version = readl(®->msgcode_rwbuffer[25]);
pr_notice("Areca RAID Controller%d: Model %s, F/W %s\n",
--
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 22/71] ncr5380: Eliminate selecting state
On Tue, 24 Nov 2015, Ondrej Zary wrote:
> On Wednesday 18 November 2015 09:35:17 Finn Thain wrote:
> > Linux v2.1.105 changed the algorithm for polling for the BSY signal
> > in NCR5380_select() and NCR5380_main().
> >
> > Presently, this code has a bug. Back then, NCR5380_set_timer(hostdata, 1)
> > meant reschedule main() after sleeping for 10 ms. Repeated 25 times this
> > provided the recommended 250 ms selection time-out delay. This got broken
> > when HZ became configurable.
> >
> > We could fix this but there's no need to reschedule the main loop. This
> > BSY polling presently happens when the NCR5380_main() work queue item
> > calls NCR5380_select(), which in turn schedules NCR5380_main(), which
> > calls NCR5380_select() again, and so on.
> >
> > This algorithm is a deviation from the simpler one in atari_NCR5380.c.
> > The extra complexity and state is pointless. There's no reason to
> > stop selection half-way and return to to the main loop when the main
> > loop can do nothing useful until selection completes.
> >
> > So just poll for BSY. We can sleep while polling now that we have a
> > suitable workqueue.
>
> Bisecting slow module initialization pointed to this commit.
That's disappointing. This patch removed some nasty code. Anyway, thanks
for taking the trouble to bisect.
>
> Before this commit (2 seconds):
> [ 60.317374] scsi host2: Generic NCR5380/NCR53C400 SCSI, io_port 0x0,
> n_io_port 0, base 0xd8000, irq 0, can_queue 16, cmd_per_lun 2, sg_tablesize
> 128, this_id 7, flags { NCR53C400 }, USLEEP_POLL 3, USLEEP_SLEEP 50, options
> { AUTOPROBE_IRQ PSEUDO_DMA }
> [ 60.780715] scsi 2:0:1:0: Direct-Access QUANTUM LP240S GM240S01X 4.6
> PQ: 0 ANSI: 2 CCS
> [ 62.606260] sd 2:0:1:0: Attached scsi generic sg1 type 0
>
>
> After this commit (22 seconds):
> [ 137.511711] scsi host2: Generic NCR5380/NCR53C400 SCSI, io_port 0x0,
> n_io_port 0, base 0xd8000, irq 0, can_queue 16, cmd_per_lun 2, sg_tablesize
> 128, this_id 7, flags { NCR53C400 }, USLEEP_POLL 3, USLEEP_SLEEP 50, options
> { AUTOPROBE_IRQ PSEUDO_DMA }
> [ 145.028532] clocksource: timekeeping watchdog: Marking clocksource 'tsc'
> as unstable because the skew is too large:
> [ 145.029767] clocksource: 'acpi_pm' wd_now: a49738
> wd_last: f4da04 mask: ff
> [ 145.029828] clocksource: 'tsc' cs_now: 2ea624698e
> cs_last: 2c710aa17f mask:
> [ 145.032733] clocksource: Switched to clocksource acpi_pm
I figured that it was okay to sleep from an unbound CPU-intensive
workqueue but doing so seems to cause problems. (See also patch 66/71
"Fix soft lockups".)
Perhaps a kthread is needed instead of a workqueue? (This workqueue
already has it's own kthread, but top shows that it doesn't accrue CPU
time.)
> [ 145.236951] scsi 2:0:1:0: Direct-Access QUANTUM LP240S GM240S01X 4.6
> PQ: 0 ANSI: 2 CCS
> [ 159.959308] sd 2:0:1:0: Attached scsi generic sg1 type 0
>
>
This problem doesn't show up on my hardware, and I'd like to know where
those 22 seconds are being spent. Would you please apply the entire series
and add,
#define NDEBUG (NDEBUG_ARBITRATION | NDEBUG_SELECTION | NDEBUG_MAIN)
to the top of g_NCR5380.c and send me the messages logged during modprobe?
--
--
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 0/3] arcmsr: support areca new adapter ARC1203
From: Ching Huang Patch 1 fixes getting wrong configuration data. Pacth 2 adds codes to support new adapter ARC1203. Patch 3 changes driver version number. -- -- 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] arcmsr: support areca new adapter ARC1203
On Tue, 2015-11-24 at 16:07 +0100, Hannes Reinecke wrote: > On 11/24/2015 09:00 AM, Ching Huang wrote: > > From: Ching Huang > > > > Patch 1 fixes getting wrong configuration data. > > > > Pacth 2 adds codes to support new adapter ARC1203. > > Patch 3 changes driver version number. > Please split off the driver version update into a separate patch and > add it as the last patch in the series. > Otherwise it'll be hard to keep track of which patch belongs to > which version. > Thanks. > > Cheers, > > Hannes > OK. So I have patch 3 as above. I will resend v2 all 3 patches later. Thanks, Ching > -- 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/71] More fixes, cleanup and modernization for NCR5380 drivers
On Tue, 24 Nov 2015, Ondrej Zary wrote: > On Tuesday 24 November 2015 10:13:17 Finn Thain wrote: > > > > On Tue, 24 Nov 2015, Ondrej Zary wrote: > > > > > On Tuesday 24 November 2015, Finn Thain wrote: > > > > > > > > On Mon, 23 Nov 2015, Ondrej Zary wrote: > > > > > > > > > > > > > > PDMA seems to be broken in multiple ways. NCR5380_pread cannot > > > > > process less than 128 bytes. In fact, 53C400 datasheet says that > > > > > it's HW limitation: non-modulo-128-byte transfers should use > > > > > PIO. > > > > > > > > > > Adding > > > > > transfersize = round_down(transfersize, 128); > > > > > to generic_NCR5380_dma_xfer_len() improves the situation a bit. > > > > > > > > > > After modprobe, some small reads (8, 4, 24 and 64 bytes) are > > > > > done using PIO, then eight 512-byte reads using PDMA and then it > > > > > fails on a 254-byte read. First 128 bytes are read using PDMA > > > > > and the next PDMA operation hangs waiting forever for the host > > > > > buffer to be ready. > > > > > > > > > > > > > A 128-byte PDMA receive followed by 126-byte PDMA receive? I don't > > > > see how that is possible given round_down(126, 128) == 0. Was this > > > > the actual 'len' argument to NCR5380_pread() in g_NCR5380.c? > > > > > > No 126-byte PDMA. The 126 bytes were probably lost (or mixed with > > > the next read?). > > [...] > > > The next read was also 254 bytes so another 128-byte PDMA transfer. > > > > > > Then modified NCR5380_information_transfer() to transfer the > > > remaining data (126 bytes in this case) using PIO. It did not help, > > > the next PDMA transfer failed too. > > > > > > > AFAICT, no change to NCR5380_information_transfer() should be needed. > > It was always meant to cope with the need to split a transfer between > > (P)DMA and PIO. > > Instead of fixing split transfers, simply forced everything > non-modulo-128 to PIO: The need to split a transfer arises from early chip errata relating to DMA and the workarounds for them (see the comments in the source). That's why I believe that the driver was meant to be cope with this. But I don't have any experimental evidence for it. I'm almost certain that these errata aren't applicable to your hardware. So I don't have any reason to think that your card will allow part of a transfer to be performed with PDMA and the rest with PIO. So I don't really object to the patch. But I don't understand the need for it either: I have no idea what state the driver, chip and scsi bus were in when the 126-byte PIO transfer failed. If the PIO transfer didn't succeed then the entire command should have failed. > --- a/drivers/scsi/g_NCR5380.c > +++ b/drivers/scsi/g_NCR5380.c > @@ -703,6 +703,10 @@ static int generic_NCR5380_dma_xfer_len(struct scsi_cmnd > *cmd) > !(cmd->SCp.this_residual % transfersize)) > transfersize = 32 * 1024; > > + /* 53C400 datasheet: non-modulo-128-byte transfers should use PIO */ Do you have a download link for this datasheet? > + if (transfersize % 128) > + transfersize = 0; > + > return transfersize; > } > > It seems to work and greatly improves performance: > # hdparm -t --direct /dev/sdb > > /dev/sdb: > Timing O_DIRECT disk reads: 4 MB in 4.84 seconds = 846.15 kB/sec > Sounds about right... -- -- 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] scsi: gdth: replace struct timeval with ktime_get_real_seconds()
struct timeval will overflow on 32-bit systems in y2038 and is being
removed from the kernel. Replace the use of struct timeval and
do_gettimeofday() with ktime_get_real_seconds() which provides a 64-bit
seconds value and is y2038 safe.
gdth driver requires changes in two areas:
1) gdth_store_event() loads two u32 timestamp fields for ioctl GDTIOCTL_EVENT
These timestamp fields are part of struct gdth_evt_str used for passing
event data to userspace. At the first instance of an event we do
(first_stamp=last_stamp="current time"). If that same event repeats,
we do (last_stamp="current time") AND increment same_count to indicate
how many times the event has repeated since first_stamp.
This patch replaces the use of timeval and do_gettimeofday() with
ktime_get_real_seconds() cast to u32 to extend the timestamp fields
to y2106.
Beyond y2106, the userspace tools (ie. RAID controller monitors) can
work around the time rollover and this driver would still not need to
change.
Alternative: The alternative approach is to introduce a new ioctl in gdth
with the u32 time fields defined as u64. This would require userspace
changes now, but not in y2106.
2) gdth_show_info() calculates elapsed time using u32 first_stamp
It is adding events with timestamps to a seq_file. Timestamps are
calculated as the "current time" minus the first_stamp.
This patch replaces the use of timeval and do_gettimeofday() with
ktime_get_real_seconds() cast to u32 to calculate the timestamp.
This elapsed time calculation is safe even when the time wraps (beyond
y2106) due to how unsigned subtraction works. A comment has been added
to the code to indicate this safety.
Alternative: This piece itself doesn't warrant an alternative, but
if we do introduce a new structure & ioctl with u64 timestamps, this
would change accordingly.
Signed-off-by: Alison Schofield
---
Changes in v2:
- remove unnecessary ktime.h includes
- add comment in code to explain elapsed time calculation
- add detail and alternatives to changelog
drivers/scsi/gdth.c | 7 ++-
drivers/scsi/gdth_proc.c | 11 ---
2 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/scsi/gdth.c b/drivers/scsi/gdth.c
index 71e1380..0a76774 100644
--- a/drivers/scsi/gdth.c
+++ b/drivers/scsi/gdth.c
@@ -2838,7 +2838,6 @@ static gdth_evt_str *gdth_store_event(gdth_ha_str *ha,
u16 source,
u16 idx, gdth_evt_data *evt)
{
gdth_evt_str *e;
-struct timeval tv;
/* no GDTH_LOCK_HA() ! */
TRACE2(("gdth_store_event() source %d idx %d\n", source, idx));
@@ -2854,8 +2853,7 @@ static gdth_evt_str *gdth_store_event(gdth_ha_str *ha,
u16 source,
!strcmp((char *)&ebuffer[elastidx].event_data.event_string,
(char *)&evt->event_string {
e = &ebuffer[elastidx];
-do_gettimeofday(&tv);
-e->last_stamp = tv.tv_sec;
+ e->last_stamp = (u32)ktime_get_real_seconds();
++e->same_count;
} else {
if (ebuffer[elastidx].event_source != 0) { /* entry not free ? */
@@ -2871,8 +2869,7 @@ static gdth_evt_str *gdth_store_event(gdth_ha_str *ha,
u16 source,
e = &ebuffer[elastidx];
e->event_source = source;
e->event_idx = idx;
-do_gettimeofday(&tv);
-e->first_stamp = e->last_stamp = tv.tv_sec;
+ e->first_stamp = e->last_stamp = (u32)ktime_get_real_seconds();
e->same_count = 1;
e->event_data = *evt;
e->application = 0;
diff --git a/drivers/scsi/gdth_proc.c b/drivers/scsi/gdth_proc.c
index e66e997..be609db 100644
--- a/drivers/scsi/gdth_proc.c
+++ b/drivers/scsi/gdth_proc.c
@@ -148,7 +148,6 @@ int gdth_show_info(struct seq_file *m, struct Scsi_Host
*host)
gdth_cmd_str *gdtcmd;
gdth_evt_str *estr;
char hrec[161];
-struct timeval tv;
char *buf;
gdth_dskstat_str *pds;
@@ -540,8 +539,14 @@ int gdth_show_info(struct seq_file *m, struct Scsi_Host
*host)
if (estr->event_data.eu.driver.ionode == ha->hanum &&
estr->event_source == ES_ASYNC) {
gdth_log_event(&estr->event_data, hrec);
-do_gettimeofday(&tv);
-sec = (int)(tv.tv_sec - estr->first_stamp);
+
+ /*
+* Elapsed seconds subtraction with unsigned operands is
+* safe from wrap around in year 2106. Executes as:
+* operand a + (2's complement operand b) + 1
+*/
+
+ sec = (int)((u32)ktime_get_real_seconds() - estr->first_stamp);
if (sec < 0) sec = 0;
seq_printf(m," date- %02d:%02d:%02d\t%s\n",
sec/3600, sec%3600/60, sec%60, hrec);
--
2.1.4
--
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] Fix a bdi reregistration race, v2
On 11/24/2015 03:13 PM, Christoph Hellwig wrote: What sort of re-registration is this? Seems like we should only release the minor number once the bdi is released. Hello Christoph, As you most likely know the BDI device name for disks is based on the device major and minor number: $ ls -l /dev/sda brw-rw 1 root disk 8, 0 Nov 24 14:53 /dev/sda $ ls -l /sys/block/sda/bdi lrwxrwxrwx 1 root root 0 Nov 24 15:17 /sys/block/sda/bdi -> ../../../../../../../../virtual/bdi/8:0 So if a driver stops using a (major, minor) number pair and the same device number is reused before the bdi device has been released the warning mentioned in the patch description at the start of this thread is triggered. This patch fixes that race by removing the bdi device from sysfs during the __scsi_remove_device() call instead of when the bdi device is released. Bart. -- 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] Fix a bdi reregistration race, v2
What sort of re-registration is this? Seems like we should only release the minor number once the bdi is released. -- 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] Fix a memory leak in scsi_host_dev_release()
On 11/18/2015 02:56 PM, Bart Van Assche wrote:
> Avoid that kmemleak reports the following memory leak if a
> SCSI LLD calls scsi_host_alloc() and scsi_host_put() but neither
> scsi_host_add() nor scsi_host_remove(). The following shell
> command triggers that scenario:
>
> for ((i=0; i<2; i++)); do
> srp_daemon -oac |
> while read line; do
> echo $line >/sys/class/infiniband_srp/srp-mlx4_0-1/add_target
> done
> done
>
> unreferenced object 0x88021b24a220 (size 8):
> comm "srp_daemon", pid 56421, jiffies 4295006762 (age 4240.750s)
> hex dump (first 8 bytes):
> 68 6f 73 74 35 38 00 a5 host58..
> backtrace:
> [] kmemleak_alloc+0x7a/0xc0
> [] __kmalloc_track_caller+0xfe/0x160
> [] kvasprintf+0x5b/0x90
> [] kvasprintf_const+0x8d/0xb0
> [] kobject_set_name_vargs+0x3c/0xa0
> [] dev_set_name+0x3c/0x40
> [] scsi_host_alloc+0x327/0x4b0
> [] srp_create_target+0x4e/0x8a0 [ib_srp]
> [] dev_attr_store+0x1b/0x20
> [] sysfs_kf_write+0x4a/0x60
> [] kernfs_fop_write+0x14e/0x180
> [] __vfs_write+0x2f/0xf0
> [] vfs_write+0xa4/0x100
> [] SyS_write+0x54/0xc0
> [] entry_SYSCALL_64_fastpath+0x12/0x6f
>
> Signed-off-by: Bart Van Assche
> Cc: Christoph Hellwig
> Cc: Hannes Reinecke
> Cc: stable
> ---
> drivers/scsi/hosts.c | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/drivers/scsi/hosts.c b/drivers/scsi/hosts.c
> index 323982f..82ac1cd 100644
> --- a/drivers/scsi/hosts.c
> +++ b/drivers/scsi/hosts.c
> @@ -333,6 +333,17 @@ static void scsi_host_dev_release(struct device *dev)
> kfree(queuedata);
> }
>
> + if (shost->shost_state == SHOST_CREATED) {
> + /*
> + * Free the shost_dev device name here if scsi_host_alloc()
> + * and scsi_host_put() have been called but neither
> + * scsi_host_add() nor scsi_host_remove() has been called.
> + * This avoids that the memory allocated for the shost_dev
> + * name is leaked.
> + */
> + kfree(dev_name(&shost->shost_dev));
> + }
> +
> scsi_destroy_command_freelist(shost);
> if (shost_use_blk_mq(shost)) {
> if (shost->tag_set.tags)
>
Reviewed-by: Lee Duncan
--
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/71] More fixes, cleanup and modernization for NCR5380 drivers
On Tuesday 24 November 2015 10:13:17 Finn Thain wrote: > > On Tue, 24 Nov 2015, Ondrej Zary wrote: > > > On Tuesday 24 November 2015, Finn Thain wrote: > > > > > > On Mon, 23 Nov 2015, Ondrej Zary wrote: > > > > > > > > > > > PDMA seems to be broken in multiple ways. NCR5380_pread cannot > > > > process less than 128 bytes. In fact, 53C400 datasheet says that > > > > it's HW limitation: non-modulo-128-byte transfers should use PIO. > > > > > > > > Adding > > > > transfersize = round_down(transfersize, 128); > > > > to generic_NCR5380_dma_xfer_len() improves the situation a bit. > > > > > > > > After modprobe, some small reads (8, 4, 24 and 64 bytes) are done > > > > using PIO, then eight 512-byte reads using PDMA and then it fails on > > > > a 254-byte read. First 128 bytes are read using PDMA and the next > > > > PDMA operation hangs waiting forever for the host buffer to be > > > > ready. > > > > > > > > > > A 128-byte PDMA receive followed by 126-byte PDMA receive? I don't see > > > how that is possible given round_down(126, 128) == 0. Was this the > > > actual 'len' argument to NCR5380_pread() in g_NCR5380.c? > > > > No 126-byte PDMA. The 126 bytes were probably lost (or mixed with the > > next read?). > > When you said, the "PDMA operation hangs waiting forever", I figured that > you had hit an infinite loop in NCR5380_pread()... but now I'm lost. > > My main concern here is to confirm that I didn't break anything e.g. with > patch 24 or 41. It would be nice to know that this hang is not the result > of a new bug. > > > The next read was also 254 bytes so another 128-byte PDMA transfer. > > > > Then modified NCR5380_information_transfer() to transfer the remaining > > data (126 bytes in this case) using PIO. It did not help, the next PDMA > > transfer failed too. > > > > AFAICT, no change to NCR5380_information_transfer() should be needed. It > was always meant to cope with the need to split a transfer between (P)DMA > and PIO. Instead of fixing split transfers, simply forced everything non-modulo-128 to PIO: --- a/drivers/scsi/g_NCR5380.c +++ b/drivers/scsi/g_NCR5380.c @@ -703,6 +703,10 @@ static int generic_NCR5380_dma_xfer_len(struct scsi_cmnd *cmd) !(cmd->SCp.this_residual % transfersize)) transfersize = 32 * 1024; + /* 53C400 datasheet: non-modulo-128-byte transfers should use PIO */ + if (transfersize % 128) + transfersize = 0; + return transfersize; } It seems to work and greatly improves performance: # hdparm -t --direct /dev/sdb /dev/sdb: Timing O_DIRECT disk reads: 4 MB in 4.84 seconds = 846.15 kB/sec -- Ondrej Zary -- 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/3] block: Add badblock management for gendisks
On Tue, Nov 24, 2015 at 12:10 PM, Verma, Vishal L wrote: > On Tue, 2015-11-24 at 14:14 -0500, Jeff Moyer wrote: >> >> I'm not sure whether it makes sense to continue without badblock >> management for the RAID code. I was hoping Neil would comment on >> that. >> >> -Jeff > > Not sure I follow? I believe I've kept all the badblocks functionality > RAID already had.. > > > On a related note, something I observed when testing with md: > > md's badblock list is per-device, and can be seen at: > /sys/block/md0/md/dev-pmem0/bad_blocks > > Now if we have badblocks in the gendisks too, there is also: > /sys/block/pmem0/bad_blocks > > The two are separate 'accounts' maintained by separate drivers (md for > the former, and pmem for the latter). This can potentially be > confusing.. > > Should we consolidate the two, i.e. make md (re)use the gendisk > badblocks for its purposes too? If we get agreement that tracking bad blocks at the gendisk is useful for more than just nvdimms then yes, I think it makes sense to move md bad_blocks to the gendisk layer. That is provided we can add a symlink to make the move transparent to existing md userspace tooling. The use cases I can envision being useful for other disks is: 1/ Bypassing / avoiding known bad blocks on disks / drivers that inject long completion latency for error handling. 2/ Simulating bad blocks for disks that can't store them locally. Similar to the md use case, if one encounters errors restoring a disk image from a backup it's useful to have the option to record the error in a bad block list and keep going. -- 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] scsi_debug: fix prevent_allow+verify regressions
> "Doug" == Douglas Gilbert writes: Doug> Ruediger Meier observed a regression with the PREVENT ALLOW MEDIUM Doug> REMOVAL command in lk 3.19: Doug> http://www.spinics.net/lists/util-linux-ng/msg11448.html Applied to 4.4. -- 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: [PATCH 2/3] block: Add badblock management for gendisks
On Tue, 2015-11-24 at 14:14 -0500, Jeff Moyer wrote: > > I'm not sure whether it makes sense to continue without badblock > management for the RAID code. I was hoping Neil would comment on > that. > > -Jeff Not sure I follow? I believe I've kept all the badblocks functionality RAID already had.. On a related note, something I observed when testing with md: md's badblock list is per-device, and can be seen at: /sys/block/md0/md/dev-pmem0/bad_blocks Now if we have badblocks in the gendisks too, there is also: /sys/block/pmem0/bad_blocks The two are separate 'accounts' maintained by separate drivers (md for the former, and pmem for the latter). This can potentially be confusing.. Should we consolidate the two, i.e. make md (re)use the gendisk badblocks for its purposes too? -Vishal
Re: [PATCH V2] st: fix potential null pointer dereference.
> On 18.11.2015, at 16.32, Maurizio Lombardi wrote: > > If cdev_add() returns an error, the code calls > cdev_del() passing the STm->cdevs[rew] pointer as parameter; > the problem is that the pointer has not been initialized yet. > > This patch fixes the problem by moving the STm->cdevs[rew] pointer > initialization before the call to cdev_add(). > It also sets STm->devs[rew] and STm->cdevs[rew] to NULL in > case of failure. > > Signed-off-by: Maurizio Lombardi Acked-by: Kai Mäkisara Thanks, Kai -- 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] qla2xxx: Fix regression introduced by configFS changes
Reviewed-by: Christoph Hellwig -- 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: kernel BUG at drivers/scsi/scsi_lib.c:1096!
On 11/23/2015 10:21 AM, Ming Lei wrote:
On Mon, 23 Nov 2015 10:46:20 +0800
Ming Lei wrote:
Hi Mark,
On Mon, Nov 23, 2015 at 9:50 AM, Mark Salter wrote:
On Mon, 2015-11-23 at 08:36 +0800, Ming Lei wrote:
On Mon, Nov 23, 2015 at 7:20 AM, Mark Salter wrote:
On Sun, 2015-11-22 at 00:56 +0800, Ming Lei wrote:
On Sat, 21 Nov 2015 12:30:14 +0100
Laurent Dufour wrote:
On 20/11/2015 13:10, Michael Ellerman wrote:
On Thu, 2015-11-19 at 00:23 -0800, Christoph Hellwig wrote:
It's pretty much guaranteed a block layer bug, most likely in the
merge bios to request infrastucture where we don't obey the merging
limits properly.
Does either of you have a known good and first known bad kernel?
Not me, I've only hit it one or two times. All I can say is I have hit it in
4.4-rc1.
Laurent, can you narrow it down at all?
It seems that the panic is triggered by the commit bdced438acd8 ("block:
setup bi_phys_segments after splitting") which has been pulled by the
merge d9734e0d1ccf ("Merge branch 'for-4.4/core' of
git://git.kernel.dk/linux-block").
My system is panicing promptly when running a kernel built at
d9734e0d1ccf, while reverting the commit bdced438acd8, it can run hours
without panicing.
This being said, I can't explain what's going wrong.
May Ming shed some light here ?
Laurent, looks there is one bug in blk_bio_segment_split(), would you
mind testing the following patch to see if it fixes your issue?
---
From 6fc701231dcc000bc8bc4b9105583380d9aa31f4 Mon Sep 17 00:00:00 2001
From: Ming Lei
Date: Sun, 22 Nov 2015 00:47:13 +0800
Subject: [PATCH] block: fix segment split
Inside blk_bio_segment_split(), previous bvec pointer('bvprvp')
always points to the iterator local variable, which is obviously
wrong, so fix it by pointing to the local variable of 'bvprv'.
Signed-off-by: Ming Lei
---
block/blk-merge.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/block/blk-merge.c b/block/blk-merge.c
index de5716d8..f2efe8a 100644
--- a/block/blk-merge.c
+++ b/block/blk-merge.c
@@ -98,7 +98,7 @@ static struct bio *blk_bio_segment_split(struct request_queue
*q,
seg_size += bv.bv_len;
bvprv = bv;
- bvprvp = &bv;
+ bvprvp = &bvprv;
sectors += bv.bv_len >> 9;
continue;
}
@@ -108,7 +108,7 @@ new_segment:
nsegs++;
bvprv = bv;
- bvprvp = &bv;
+ bvprvp = &bvprv;
seg_size = bv.bv_len;
sectors += bv.bv_len >> 9;
}
I'm still hitting the BUG even with this patch applied on top of 4.4-rc1.
OK, looks there are still other bugs, care to share us how to reproduce
it on arm64?
thanks,
Ming
Unfortunately, the best reproducer I have is to boot the platform. I have seen
the
BUG a few times post-boot, but I don't have a consistant reproducer. I am using
upstream 4.4-rc1 with this config:
http://people.redhat.com/msalter/fh_defconfig
With 4.4-rc1 on an APM Mustang platform, I see the BUG about once every 6-7
boots.
On an AMD Seattle platform, about every 9 boots.
Thanks for the input, and I will try to reproduce the issue on mustang with
your kernel config.
I can reproduce the issue on mustang, and looks I may understand the story now.
When 64K page size is used on arm64, and the default segment size of block
is 65536, then one segment should only include one page at most.
Commit bdced438acd83a(block: setup bi_phys_segments after splitting) does not
compute bio->bi_seg_front_size and bio->bi_seg_back_size, then one less segment
may be obtained because blk_phys_contig_segment() thought the last bvec in 1st
bio and the 1st bvec in the 2nd bio is in one physical segment, so cause the
regression.
Looks the following patch can fix the issue by figuring bio->bi_seg_front_size
and bio->bi_seg_back_size in blk_bio_segment_split().
Mark, thanks again for providing the reproduction steps, and could you run your
test to see if it can fix your issue?
---
From 86b5f33d48715c1150fdcfd9a76e495e7aa913aa Mon Sep 17 00:00:00 2001
From: Ming Lei
Date: Mon, 23 Nov 2015 20:27:23 +0800
Subject: [PATCH 2/2] blk-merge: fix blk_bio_segment_split
Commit bdced438acd83a(block: setup bi_phys_segments after
splitting) introduces function of computing bio->bi_phys_segments
during bio splitting.
Unfortunately both bio->bi_seg_front_size and bio->bi_seg_back_size
arn't computed, so too many physical segments may be obtained
for one request since both the two are used to check if one segment
across two bios can be possible.
This patch fixes the issue by computing the two variables in
blk_bio_segment_split().
Reported-by: Michael Ellerman
Reported-by: Mark Salter
Fixes: bdced438acd83a(block: setup bi_phys_segments after splitting)
Signed-off-by: Ming Lei
---
block/blk-merge.c | 22 +++---
1 file changed, 19 insertions(+), 3 deletions(-)
diff
Re: [PATCH 1/3] badblocks: Add core badblock management code
On 11/20/2015 05:49 PM, Vishal Verma wrote: Take the core badblocks implementation from md, and make it generally available. This follows the same style as kernel implementations of linked lists, rb-trees etc, where you can have a structure that can be embedded anywhere, and accessor functions to manipulate the data. The only changes in this copy of the code are ones to generalize function/variable names from md-specific ones. Also add init and free functions. Split this into a .c file with the code. -- Jens Axboe -- 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/3] block: Add badblock management for gendisks
"Verma, Vishal L" writes: > On Tue, 2015-11-24 at 10:34 -0500, Jeff Moyer wrote: >> Vishal Verma writes: >> >> > NVDIMM devices, which can behave more like DRAM rather than block >> > devices, may develop bad cache lines, or 'poison'. A block device >> > exposed by the pmem driver can then consume poison via a read (or >> > write), and cause a machine check. On platforms without machine >> > check recovery features, this would mean a crash. >> > >> > The block device maintaining a runtime list of all known sectors >> > that >> > have poison can directly avoid this, and also provide a path forward >> > to enable proper handling/recovery for DAX faults on such a device. >> > >> > Use the new badblock management interfaces to add a badblocks list >> > to >> > gendisks. >> >> Because disk_alloc_badblocks can fail, you need to check for a NULL >> disk->bb in all of the utility functions you've defined. >> > > Thanks, Jeff - I'll fix this. I have a handful of other fixes queued up > too, will send out a v2 soon. I'm not sure whether it makes sense to continue without badblock management for the RAID code. I was hoping Neil would comment on that. -Jeff -- 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 22/71] ncr5380: Eliminate selecting state
On Wednesday 18 November 2015 09:35:17 Finn Thain wrote:
> Linux v2.1.105 changed the algorithm for polling for the BSY signal
> in NCR5380_select() and NCR5380_main().
>
> Presently, this code has a bug. Back then, NCR5380_set_timer(hostdata, 1)
> meant reschedule main() after sleeping for 10 ms. Repeated 25 times this
> provided the recommended 250 ms selection time-out delay. This got broken
> when HZ became configurable.
>
> We could fix this but there's no need to reschedule the main loop. This
> BSY polling presently happens when the NCR5380_main() work queue item
> calls NCR5380_select(), which in turn schedules NCR5380_main(), which
> calls NCR5380_select() again, and so on.
>
> This algorithm is a deviation from the simpler one in atari_NCR5380.c.
> The extra complexity and state is pointless. There's no reason to
> stop selection half-way and return to to the main loop when the main
> loop can do nothing useful until selection completes.
>
> So just poll for BSY. We can sleep while polling now that we have a
> suitable workqueue.
Bisecting slow module initialization pointed to this commit.
Before this commit (2 seconds):
[ 60.317374] scsi host2: Generic NCR5380/NCR53C400 SCSI, io_port 0x0,
n_io_port 0, base 0xd8000, irq 0, can_queue 16, cmd_per_lun 2, sg_tablesize
128, this_id 7, flags { NCR53C400 }, USLEEP_POLL 3, USLEEP_SLEEP 50, options {
AUTOPROBE_IRQ PSEUDO_DMA }
[ 60.780715] scsi 2:0:1:0: Direct-Access QUANTUM LP240S GM240S01X 4.6
PQ: 0 ANSI: 2 CCS
[ 62.606260] sd 2:0:1:0: Attached scsi generic sg1 type 0
After this commit (22 seconds):
[ 137.511711] scsi host2: Generic NCR5380/NCR53C400 SCSI, io_port 0x0,
n_io_port 0, base 0xd8000, irq 0, can_queue 16, cmd_per_lun 2, sg_tablesize
128, this_id 7, flags { NCR53C400 }, USLEEP_POLL 3, USLEEP_SLEEP 50, options {
AUTOPROBE_IRQ PSEUDO_DMA }
[ 145.028532] clocksource: timekeeping watchdog: Marking clocksource 'tsc' as
unstable because the skew is too large:
[ 145.029767] clocksource: 'acpi_pm' wd_now: a49738
wd_last: f4da04 mask: ff
[ 145.029828] clocksource: 'tsc' cs_now: 2ea624698e
cs_last: 2c710aa17f mask:
[ 145.032733] clocksource: Switched to clocksource acpi_pm
[ 145.236951] scsi 2:0:1:0: Direct-Access QUANTUM LP240S GM240S01X 4.6
PQ: 0 ANSI: 2 CCS
[ 159.959308] sd 2:0:1:0: Attached scsi generic sg1 type 0
--
Ondrej Zary
--
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/3] block: Add badblock management for gendisks
On Tue, 2015-11-24 at 10:34 -0500, Jeff Moyer wrote:
> Vishal Verma writes:
>
> > NVDIMM devices, which can behave more like DRAM rather than block
> > devices, may develop bad cache lines, or 'poison'. A block device
> > exposed by the pmem driver can then consume poison via a read (or
> > write), and cause a machine check. On platforms without machine
> > check recovery features, this would mean a crash.
> >
> > The block device maintaining a runtime list of all known sectors
> > that
> > have poison can directly avoid this, and also provide a path forward
> > to enable proper handling/recovery for DAX faults on such a device.
> >
> > Use the new badblock management interfaces to add a badblocks list
> > to
> > gendisks.
>
> Because disk_alloc_badblocks can fail, you need to check for a NULL
> disk->bb in all of the utility functions you've defined.
>
Thanks, Jeff - I'll fix this. I have a handful of other fixes queued up
too, will send out a v2 soon.
-VishalN�r��yb�X��ǧv�^�){.n�+{���"�{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj"��!�i
Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers
On Tuesday 24 November 2015 13:03:17 Ondrej Zary wrote: > On Tuesday 24 November 2015, Finn Thain wrote: > > > > On Tue, 24 Nov 2015, Ondrej Zary wrote: > > > > > On Tuesday 24 November 2015, Finn Thain wrote: > > > > > > > > On Mon, 23 Nov 2015, Ondrej Zary wrote: > > > > > > > > > > > > > > PDMA seems to be broken in multiple ways. NCR5380_pread cannot > > > > > process less than 128 bytes. In fact, 53C400 datasheet says that > > > > > it's HW limitation: non-modulo-128-byte transfers should use PIO. > > > > > > > > > > Adding > > > > > transfersize = round_down(transfersize, 128); > > > > > to generic_NCR5380_dma_xfer_len() improves the situation a bit. > > > > > > > > > > After modprobe, some small reads (8, 4, 24 and 64 bytes) are done > > > > > using PIO, then eight 512-byte reads using PDMA and then it fails on > > > > > a 254-byte read. First 128 bytes are read using PDMA and the next > > > > > PDMA operation hangs waiting forever for the host buffer to be > > > > > ready. > > > > > > > > > > > > > A 128-byte PDMA receive followed by 126-byte PDMA receive? I don't see > > > > how that is possible given round_down(126, 128) == 0. Was this the > > > > actual 'len' argument to NCR5380_pread() in g_NCR5380.c? > > > > > > No 126-byte PDMA. The 126 bytes were probably lost (or mixed with the > > > next read?). > > > > When you said, the "PDMA operation hangs waiting forever", I figured that > > you had hit an infinite loop in NCR5380_pread()... but now I'm lost. > > The first 128-byte PDMA ended successfully (ignoring what happened to the > remaining 126 bytes), then a next request for 254 bytes came. This resulted > in a new 128-byte PDMA and that hanged (in one of its possibly infinite loops > without a timeout). > > > My main concern here is to confirm that I didn't break anything e.g. with > > patch 24 or 41. It would be nice to know that this hang is not the result > > of a new bug. > > PDMA was already broken before so it's hard to tell. I can try to modify > the unpatched driver to see if PDMA is broken the same way. Just tested the driver without your patches and it's broken exactly the same way. -- Ondrej Zary -- 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] qla2xxx: Fix regression introduced by configFS changes
this patch fixes following regression
# targetcli
[Errno 13] Permission denied:
'/sys/kernel/config/target/qla2xxx/21:00:00:0e:1e:08:c7:20/tpgt_1/enable'
Fixes: 2eafd72939fd ("target: use per-attribute show and store methods")
Signed-off-by: Himanshu Madhani
Signed-off-by: Giridhar Malavali
Cc: Christoph Hellwig
Cc: Nicholas Bellinger
---
drivers/scsi/qla2xxx/tcm_qla2xxx.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/scsi/qla2xxx/tcm_qla2xxx.c
b/drivers/scsi/qla2xxx/tcm_qla2xxx.c
index 3ba2e95..81af294 100644
--- a/drivers/scsi/qla2xxx/tcm_qla2xxx.c
+++ b/drivers/scsi/qla2xxx/tcm_qla2xxx.c
@@ -902,7 +902,7 @@ static ssize_t tcm_qla2xxx_tpg_fabric_prot_type_show(struct
config_item *item,
return sprintf(page, "%d\n", tpg->tpg_attrib.fabric_prot_type);
}
-CONFIGFS_ATTR_WO(tcm_qla2xxx_tpg_, enable);
+CONFIGFS_ATTR(tcm_qla2xxx_tpg_, enable);
CONFIGFS_ATTR_RO(tcm_qla2xxx_tpg_, dynamic_sessions);
CONFIGFS_ATTR(tcm_qla2xxx_tpg_, fabric_prot_type);
--
1.7.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 2/9] IB: add a proper completion queue abstraction
On Tue, Nov 24, 2015 at 10:08:39AM -0700, c...@asomi.com wrote: >>> My recollection of the IB verbs is that they were unlikely to have >>> overlooked something like that. If it did slip through then there >>> should be an errata. >>verbs reflects the wire protocol and the wire protocol has no way to >>create a linkage between the send and recv sides of a RC QP. It is not >>a spec bug, there is no errata. > >No, verbs do not reflect the link layer. Verbs fulfill the contract >with the end user - especially when the hardware cannot. Are you serious? You think verbs should specify things that cannot actually be implemented? IB verbs doesn't do that. >Reporting a completion of a receive without having guaranteed >that the acknowledgement will be sent before anything >subsequently submitted is failing to implement a reliable >connection. As I've said repeatedly, the side receiving the request has no impact on this issue. Requiring it to generate an ack before delivering the recv completion *does nothing* to guarantee ordering on the other side in IB. The network can always drop the ack, and the receiver cannot tell. I disagree that RC has anything to do with this causal ordering issue, this is not a property described in the IB spec for RC. >One of the hardware designs I worked with over a decade ago >actually had *two* completion queues, one from the left brain (receive) >and the other from the right brain (transmit). Nevertheless we >presented All verbs hardware has to have these two flows. >a unified completion queue that followed ordering rules. We were not >"reflecting" the hardware, we were implementing an interface in a >combination of hardware and software. And how did you detect lost acks at the reciever to make this an actual guarentee? Maybe TCP can do this but IB cannot. I honestly don't know why you think verbs has this requirement. It is not in the IB spec, and can't be implemented by IB hardware. If one of the other flavours of verbs has this, then fine, but it is not part of the *Linux* verbs flavour. > I cannot think of a reason why that would not work here. Simply do > not report a completion to the user before guaranteeing that the > acks will be transmitted. I've already explained three times why this is not enough for IB. >What would you do if the next user action had been to close the >connection? Would the acks have been lost? No acks will be lost. The IB termination process requires the closing side to drain it's sendq and stop injecting new traffic before sending the CM close message. The other must also drain the sendq before replying. This handshake ensures the QP is quiescent and all in flight traffic completed before the QP is destroyed. IB basically shifts the lingering close into the CM arena, where it costs less, and allows the QP and associated HW resources to be destroyed quickly. Jason -- 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/3] block: Add badblock management for gendisks
Vishal Verma writes:
> NVDIMM devices, which can behave more like DRAM rather than block
> devices, may develop bad cache lines, or 'poison'. A block device
> exposed by the pmem driver can then consume poison via a read (or
> write), and cause a machine check. On platforms without machine
> check recovery features, this would mean a crash.
>
> The block device maintaining a runtime list of all known sectors that
> have poison can directly avoid this, and also provide a path forward
> to enable proper handling/recovery for DAX faults on such a device.
>
> Use the new badblock management interfaces to add a badblocks list to
> gendisks.
Because disk_alloc_badblocks can fail, you need to check for a NULL
disk->bb in all of the utility functions you've defined.
Cheers,
Jeff
>
> Signed-off-by: Vishal Verma
> ---
> block/genhd.c | 64
> +++
> include/linux/genhd.h | 6 +
> 2 files changed, 70 insertions(+)
>
> diff --git a/block/genhd.c b/block/genhd.c
> index 0c706f3..4209c32 100644
> --- a/block/genhd.c
> +++ b/block/genhd.c
> @@ -20,6 +20,7 @@
> #include
> #include
> #include
> +#include
>
> #include "blk.h"
>
> @@ -505,6 +506,20 @@ static int exact_lock(dev_t devt, void *data)
> return 0;
> }
>
> +static void disk_alloc_badblocks(struct gendisk *disk)
> +{
> + disk->bb = kzalloc(sizeof(disk->bb), GFP_KERNEL);
> + if (!disk->bb) {
> + pr_warn("%s: failed to allocate space for badblocks\n",
> + disk->disk_name);
> + return;
> + }
> +
> + if (badblocks_init(disk->bb, 1))
> + pr_warn("%s: failed to initialize badblocks\n",
> + disk->disk_name);
> +}
> +
> static void register_disk(struct gendisk *disk)
> {
> struct device *ddev = disk_to_dev(disk);
> @@ -609,6 +624,7 @@ void add_disk(struct gendisk *disk)
> disk->first_minor = MINOR(devt);
>
> disk_alloc_events(disk);
> + disk_alloc_badblocks(disk);
>
> /* Register BDI before referencing it from bdev */
> bdi = &disk->queue->backing_dev_info;
> @@ -657,6 +673,9 @@ void del_gendisk(struct gendisk *disk)
> blk_unregister_queue(disk);
> blk_unregister_region(disk_devt(disk), disk->minors);
>
> + badblocks_free(disk->bb);
> + kfree(disk->bb);
> +
> part_stat_set_all(&disk->part0, 0);
> disk->part0.stamp = 0;
>
> @@ -670,6 +689,48 @@ void del_gendisk(struct gendisk *disk)
> }
> EXPORT_SYMBOL(del_gendisk);
>
> +/*
> + * The gendisk usage of badblocks does not track acknowledgements for
> + * badblocks. We always assume they are acknowledged.
> + */
> +int disk_check_badblocks(struct gendisk *disk, sector_t s, int sectors,
> +sector_t *first_bad, int *bad_sectors)
> +{
> + return badblocks_check(disk->bb, s, sectors, first_bad, bad_sectors);
> +}
> +EXPORT_SYMBOL(disk_check_badblocks);
> +
> +int disk_set_badblocks(struct gendisk *disk, sector_t s, int sectors)
> +{
> + return badblocks_set(disk->bb, s, sectors, 1);
> +}
> +EXPORT_SYMBOL(disk_set_badblocks);
> +
> +int disk_clear_badblocks(struct gendisk *disk, sector_t s, int sectors)
> +{
> + return badblocks_clear(disk->bb, s, sectors);
> +}
> +EXPORT_SYMBOL(disk_clear_badblocks);
> +
> +/* sysfs access to bad-blocks list. */
> +static ssize_t disk_badblocks_show(struct device *dev,
> + struct device_attribute *attr,
> + char *page)
> +{
> + struct gendisk *disk = dev_to_disk(dev);
> +
> + return badblocks_show(disk->bb, page, 0);
> +}
> +
> +static ssize_t disk_badblocks_store(struct device *dev,
> + struct device_attribute *attr,
> + const char *page, size_t len)
> +{
> + struct gendisk *disk = dev_to_disk(dev);
> +
> + return badblocks_store(disk->bb, page, len, 0);
> +}
> +
> /**
> * get_gendisk - get partitioning information for a given device
> * @devt: device to get partitioning information for
> @@ -988,6 +1049,8 @@ static DEVICE_ATTR(discard_alignment, S_IRUGO,
> disk_discard_alignment_show,
> static DEVICE_ATTR(capability, S_IRUGO, disk_capability_show, NULL);
> static DEVICE_ATTR(stat, S_IRUGO, part_stat_show, NULL);
> static DEVICE_ATTR(inflight, S_IRUGO, part_inflight_show, NULL);
> +static DEVICE_ATTR(badblocks, S_IRUGO | S_IWUSR, disk_badblocks_show,
> + disk_badblocks_store);
> #ifdef CONFIG_FAIL_MAKE_REQUEST
> static struct device_attribute dev_attr_fail =
> __ATTR(make-it-fail, S_IRUGO|S_IWUSR, part_fail_show, part_fail_store);
> @@ -1009,6 +1072,7 @@ static struct attribute *disk_attrs[] = {
> &dev_attr_capability.attr,
> &dev_attr_stat.attr,
> &dev_attr_inflight.attr,
> + &dev_attr_badblocks.attr,
> #ifdef CONFIG_FAIL_MAKE_REQUEST
> &dev_attr_fail.attr,
> #endif
> diff --git a/include/linux/genhd
Re: [PATCH 00/18] ALUA device handler update, part 1
On 11/23/2015 05:18 PM, Bart Van Assche wrote: > > > On 11/23/2015 08:10 AM, Hannes Reinecke wrote: >> On 11/20/2015 11:58 PM, Bart Van Assche wrote: [ .. ] >>> BTW, not all storage arrays need STPG retries. Some arrays are able >>> to process an STPG command quickly (this means within a few >>> seconds). >>> >>> A previous discussion about this topic is available e.g. at >>> http://thread.gmane.org/gmane.linux.scsi/105340/focus=105601. >>> >> Well, one could argue that the whole point of this patchset is to >> allow you to serialize STPGs :-) >> >> We definitely need to serialize STPGs for the same target port >> group; the current implementation is far too limited to take that >> into account. >> >> But the main problem I'm facing with the current implementation is >> that we cannot handle retries. An RTPG or an STPG might fail, at >> which point we need to re-run RTPG to figure out the current status. >> (We also need to send RTPGs when we receive an "ALUA state changed" >> UA, but that's slightly beside the point). >> The retry cannot be send directly, as we're evaluating the status >> from end_io context. So to instantiate a retry we need to move it >> over to a workqueue. >> >> Or, at least, that's the solution I'm able to come up with. >> If you have other ideas it'd be most welcome. > > Hello Hannes, > > I agree that retries have to be handled from workqueue context > instead of end_io context. But in workqueue context we can choose > whether to submit the retry synchronously or asynchronously. Unless > I overlooked something I don't see why the retry should be submitted > synchronously. > Good point. Sure we can do this; the primary difference would be whether the workqueue is ordered or not. An unordered workqueue would be resulting in not serializing retries, hence achieving pretty much what you asked. Cheers, Hannes -- Dr. Hannes ReineckezSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton 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 RESEND] scsi_debug: fix prevent_allow+verify regressions
On Sun, 2015-11-22 at 12:11 -0500, Douglas Gilbert wrote: > Ruediger Meier observed a regression with the PREVENT ALLOW > MEDIUM REMOVAL command in lk 3.19: >http://www.spinics.net/lists/util-linux-ng/msg11448.html > > Inspection indicated the same regression with VERIFY(10). > > The patch is against lk 3.19.3 and also works with lk 4.3.0 . > With this patch both commands are accepted and do nothing. > > ChangeLog: >- fix the lk 3.19 regression so that the PREVENT ALLOW > MEDIUM REMOVAL command is supported once again >- same fix for VERIFY(10) > > Signed-off-by: Douglas Gilbert Reviewed-by: Ewan D. Milne -- 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 0/3] scsi: reduce CONFIG_SCSI_CONSTANTS=y impact by 8k
On 11/24/2015 10:42 AM, Rasmus Villemoes wrote:
> This reduces the impact of choosing CONFIG_SCSI_CONSTANTS by about 8KB.
>
> 2dd951ecd511 ("scsi: Conditionally compile in constants.c") updated
> the Kconfig help text from 12KB to 75KB. The 12K predated git so was
> certainly outdated. But I'm not sure where the 75K comes from; using
> size(1) on a defconfig (with/without this config option) vmlinux shows
> a difference of about 47K, and 39K after these patches are applied. In
> any case, I've left the Kconfig text alone, since I'm not sure I'm
> counting the same way the 75K was computed (I'm fairly certain of the
> 8K delta, however).
>
> Tested with a trivial module calling scsi_extd_sense_format with a few
> random known codes and comparing the result to the expected value.
>
> v2: prepend patch to unsplit a few string literals for greppability,
> leave the NULL sentinel in the .c file in 2/3 (it's removed in 3/3
> either way).
>
> Rasmus Villemoes (3):
> scsi: make some Additional Sense strings more grep'able
> scsi: move Additional Sense Codes to separate file
> scsi: reduce CONFIG_SCSI_CONSTANTS=y impact by 8k
>
> drivers/scsi/constants.c | 859
> ++---
> drivers/scsi/sense_codes.h | 826 +++
> 2 files changed, 847 insertions(+), 838 deletions(-)
> create mode 100644 drivers/scsi/sense_codes.h
>
For the whole series:
Reviewed-by: Hannes Reinecke
Cheers,
Hannes
--
Dr. Hannes ReineckezSeries & Storage
h...@suse.de +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
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] arcmsr: support areca new adapter ARC1203
On 11/24/2015 09:00 AM, Ching Huang wrote: > From: Ching Huang > > Patch 1 fixes getting wrong configuration data. > > Pacth 2 adds codes to support new adapter ARC1203. > Please split off the driver version update into a separate patch and add it as the last patch in the series. Otherwise it'll be hard to keep track of which patch belongs to which version. Thanks. Cheers, Hannes -- Dr. Hannes ReineckezSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton 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 RESEND] scsi_debug: fix prevent_allow+verify regressions
On 11/22/2015 06:11 PM, Douglas Gilbert wrote: > Ruediger Meier observed a regression with the PREVENT ALLOW > MEDIUM REMOVAL command in lk 3.19: > http://www.spinics.net/lists/util-linux-ng/msg11448.html > > Inspection indicated the same regression with VERIFY(10). > > The patch is against lk 3.19.3 and also works with lk 4.3.0 . > With this patch both commands are accepted and do nothing. > > ChangeLog: > - fix the lk 3.19 regression so that the PREVENT ALLOW > MEDIUM REMOVAL command is supported once again > - same fix for VERIFY(10) > > Signed-off-by: Douglas Gilbert Reviewed-by: Hannes Reinecke Cheers, Hannes -- Dr. Hannes ReineckezSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton 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] scsi: use sector_div instead of do_div
On 11/20/2015 05:38 PM, Arnd Bergmann wrote:
> do_div is the wrong way to divide a sector_t, as it is less
> efficient when sector_t is 32-bit wide. With the upcoming
> do_div optimizations, the kernel starts warning about this:
>
> drivers/scsi/scsi_debug.c: In function 'dif_store':
> include/asm-generic/div64.h:207:28: warning: comparison of distinct pointer
> types lacks a cast
>
> This changes the code to use sector_div instead, which always
> produces optimal code.
>
> Signed-off-by: Arnd Bergmann
> ---
> Found on the ARM randconfig build today, after I merged Nico's patches
> for linux-next
>
> diff --git a/drivers/scsi/scsi_debug.c b/drivers/scsi/scsi_debug.c
> index dfcc45bb03b1..ec622ba9864a 100644
> --- a/drivers/scsi/scsi_debug.c
> +++ b/drivers/scsi/scsi_debug.c
> @@ -678,7 +678,7 @@ static void *fake_store(unsigned long long lba)
>
> static struct sd_dif_tuple *dif_store(sector_t sector)
> {
> - sector = do_div(sector, sdebug_store_sectors);
> + sector = sector_div(sector, sdebug_store_sectors);
>
> return dif_storep + sector;
> }
> @@ -2780,7 +2780,7 @@ static unsigned long lba_to_map_index(sector_t lba)
> lba += scsi_debug_unmap_granularity -
> scsi_debug_unmap_alignment;
> }
> - do_div(lba, scsi_debug_unmap_granularity);
> + sector_div(lba, scsi_debug_unmap_granularity);
>
> return lba;
> }
>
Reviewed-by: Hannes Reinecke
Cheers,
Hannes
--
Dr. Hannes ReineckezSeries & Storage
h...@suse.de +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
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] Fix a memory leak in scsi_host_dev_release()
On 19/11/2015 00:56, Bart Van Assche wrote: Avoid that kmemleak reports the following memory leak if a SCSI LLD calls scsi_host_alloc() and scsi_host_put() but neither scsi_host_add() nor scsi_host_remove(). The following shell command triggers that scenario: Looks good, Reviewed-by: Sagi Grimberg -- 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: hisi_sas: remove dependency on of_irq_count
On Thu, Nov 19, 2015 at 6:23 AM, John Garry wrote:
> Originally the driver would use of_irq_count to
> calculate how much memory is required for storing the
> interrupt names, since the number of interrupt sources
> for the controller is variable.
> Since of_irq_count cannot be used by the driver, use
> fixed names.
>
> Signed-off-by: John Garry
> Signed-off-by: Zhangfei Gao
Acked-by: Rob Herring
>
> diff --git a/drivers/scsi/hisi_sas/hisi_sas.h
> b/drivers/scsi/hisi_sas/hisi_sas.h
> index 5b790c9..30a9ab9 100644
> --- a/drivers/scsi/hisi_sas/hisi_sas.h
> +++ b/drivers/scsi/hisi_sas/hisi_sas.h
> @@ -38,8 +38,6 @@
> #define HISI_SAS_MAX_SSP_RESP_SZ (sizeof(struct ssp_frame_hdr) + 1024)
> #define HISI_SAS_MAX_SMP_RESP_SZ 1028
>
> -#define HISI_SAS_NAME_LEN 32
> -
> struct hisi_hba;
>
> enum {
> @@ -178,7 +176,6 @@ struct hisi_hba {
>
> int queue_count;
> int queue;
> - char*int_names;
> struct hisi_sas_slot*slot_prep;
>
> struct dma_pool *sge_page_pool;
> diff --git a/drivers/scsi/hisi_sas/hisi_sas_main.c
> b/drivers/scsi/hisi_sas/hisi_sas_main.c
> index 1377625..2929018 100644
> --- a/drivers/scsi/hisi_sas/hisi_sas_main.c
> +++ b/drivers/scsi/hisi_sas/hisi_sas_main.c
> @@ -1160,7 +1160,6 @@ static struct Scsi_Host *hisi_sas_shost_alloc(struct
> platform_device *pdev,
> struct device *dev = &pdev->dev;
> struct device_node *np = pdev->dev.of_node;
> struct property *sas_addr_prop;
> - int num;
>
> shost = scsi_host_alloc(&hisi_sas_sht, sizeof(*hisi_hba));
> if (!shost)
> @@ -1197,13 +1196,6 @@ static struct Scsi_Host *hisi_sas_shost_alloc(struct
> platform_device *pdev,
> if (of_property_read_u32(np, "queue-count", &hisi_hba->queue_count))
> goto err_out;
>
> - num = of_irq_count(np);
> - hisi_hba->int_names = devm_kcalloc(dev, num,
> - HISI_SAS_NAME_LEN,
> - GFP_KERNEL);
> - if (!hisi_hba->int_names)
> - goto err_out;
> -
> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> hisi_hba->regs = devm_ioremap_resource(dev, res);
> if (IS_ERR(hisi_hba->regs))
> diff --git a/drivers/scsi/hisi_sas/hisi_sas_v1_hw.c
> b/drivers/scsi/hisi_sas/hisi_sas_v1_hw.c
> index e29b7c7..0ed2f92 100644
> --- a/drivers/scsi/hisi_sas/hisi_sas_v1_hw.c
> +++ b/drivers/scsi/hisi_sas/hisi_sas_v1_hw.c
> @@ -1660,18 +1660,6 @@ static irqreturn_t fatal_axi_int_v1_hw(int irq, void
> *p)
> return IRQ_HANDLED;
> }
>
> -static const char phy_int_names[HISI_SAS_PHY_INT_NR][32] = {
> - {"Bcast"},
> - {"Phy Up"},
> - {"Abnormal"},
> -};
> -
> -static const char cq_int_name[32] = "cq";
> -static const char fatal_int_name[HISI_SAS_FATAL_INT_NR][32] = {
> - "fatal ecc",
> - "fatal axi"
> -};
> -
> static irq_handler_t phy_interrupts[HISI_SAS_PHY_INT_NR] = {
> int_bcast_v1_hw,
> int_phyup_v1_hw,
> @@ -1687,7 +1675,6 @@ static int interrupt_init_v1_hw(struct hisi_hba
> *hisi_hba)
> {
> struct device *dev = &hisi_hba->pdev->dev;
> struct device_node *np = dev->of_node;
> - char *int_names = hisi_hba->int_names;
> int i, j, irq, rc, idx;
>
> if (!np)
> @@ -1706,13 +1693,8 @@ static int interrupt_init_v1_hw(struct hisi_hba
> *hisi_hba)
> return -ENOENT;
> }
>
> - (void)snprintf(&int_names[idx * HISI_SAS_NAME_LEN],
> - HISI_SAS_NAME_LEN,
> - "%s %s:%d", dev_name(dev),
> - phy_int_names[j], i);
> rc = devm_request_irq(dev, irq, phy_interrupts[j], 0,
> - &int_names[idx * HISI_SAS_NAME_LEN],
> - phy);
> + DRV_NAME " phy", phy);
> if (rc) {
> dev_err(dev, "irq init: could not request "
> "phy interrupt %d, rc=%d\n",
> @@ -1730,12 +1712,9 @@ static int interrupt_init_v1_hw(struct hisi_hba
> *hisi_hba)
> idx);
> return -ENOENT;
> }
> - (void)snprintf(&int_names[idx * HISI_SAS_NAME_LEN],
> - HISI_SAS_NAME_LEN,
> - "%s %s:%d", dev_name(dev), cq_int_name, i);
> +
> rc = devm_request_irq(dev, irq, cq_interrupt_v1_hw, 0,
> - &int_names[idx * HISI_SAS_NAME_LEN],
> - &hisi_hba->cq[i]);
> + DRV_NAME " cq", &hisi_hba->cq[i]);
> if (rc) {
> dev_err(dev, "irq init: could not
Re: [PATCH 2/9] IB: add a proper completion queue abstraction
On 11/24/2015 2:03 AM, Jason Gunthorpe wrote: On Mon, Nov 23, 2015 at 06:35:28PM -0800, Caitlin Bestler wrote: Are there actual HCAs that make this mistake? All IB HCAs have this behavior and require apps to see a send CQ completion before making any statements about the state of the send Q or buffers handed over to the HCA. Tom and I have seen this in real systems under proper stress conditions. [Which is why I am so certain about this, because when I first hit it years ago I dug into the spec and figured out it was not a HW bug I was looking at] To be clear, I saw the reply-completion-before-request-completion on Windows, not Linux, but the principle is identical. It's simply a fact of life on a multiprocessor, unless you want to throw in locks and synchronization rules that drivers have to follow to enforce ordered completions across queues. Which trust me, you don't. In Windows SMB Direct, we added reference counts around pretty much every verb interaction associated with each upper layer operation, and did not retire them until all refcounts went to zero. It is excruciatingly correct yet performs incredibly well. Tom. -- 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: [RFC PATCH scsi] aacraid: aac_release_resources() can be static
Reviewed-by: Mahesh Rajashekhara
-Original Message-
From: kbuild test robot [mailto:fengguang...@intel.com]
Sent: Tuesday, November 10, 2015 11:29 AM
To: Mahesh Rajashekhara
Cc: kbuild-...@01.org; linux-scsi@vger.kernel.org; James Bottomley; Tomas
Henzl; Murthy Bhat; Karthikeya Sunkesula
Subject: [RFC PATCH scsi] aacraid: aac_release_resources() can be static
Signed-off-by: Fengguang Wu
---
linit.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/scsi/aacraid/linit.c b/drivers/scsi/aacraid/linit.c index
37375cf..7724583f 100644
--- a/drivers/scsi/aacraid/linit.c
+++ b/drivers/scsi/aacraid/linit.c
@@ -1318,7 +1318,7 @@ static int aac_probe_one(struct pci_dev *pdev, const
struct pci_device_id *id) }
#if (defined(CONFIG_PM))
-void aac_release_resources(struct aac_dev *aac)
+static void aac_release_resources(struct aac_dev *aac)
{
int i;
--
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] Fix a memory leak in scsi_host_dev_release()
On Wed, 2015-11-18 at 14:56 -0800, Bart Van Assche wrote:
> Avoid that kmemleak reports the following memory leak if a
> SCSI LLD calls scsi_host_alloc() and scsi_host_put() but neither
> scsi_host_add() nor scsi_host_remove(). The following shell
> command triggers that scenario:
>
> for ((i=0; i<2; i++)); do
> srp_daemon -oac |
> while read line; do
> echo $line >/sys/class/infiniband_srp/srp-mlx4_0-1/add_target
> done
> done
>
> unreferenced object 0x88021b24a220 (size 8):
> comm "srp_daemon", pid 56421, jiffies 4295006762 (age 4240.750s)
> hex dump (first 8 bytes):
> 68 6f 73 74 35 38 00 a5 host58..
> backtrace:
> [] kmemleak_alloc+0x7a/0xc0
> [] __kmalloc_track_caller+0xfe/0x160
> [] kvasprintf+0x5b/0x90
> [] kvasprintf_const+0x8d/0xb0
> [] kobject_set_name_vargs+0x3c/0xa0
> [] dev_set_name+0x3c/0x40
> [] scsi_host_alloc+0x327/0x4b0
> [] srp_create_target+0x4e/0x8a0 [ib_srp]
> [] dev_attr_store+0x1b/0x20
> [] sysfs_kf_write+0x4a/0x60
> [] kernfs_fop_write+0x14e/0x180
> [] __vfs_write+0x2f/0xf0
> [] vfs_write+0xa4/0x100
> [] SyS_write+0x54/0xc0
> [] entry_SYSCALL_64_fastpath+0x12/0x6f
>
> Signed-off-by: Bart Van Assche
> Cc: Christoph Hellwig
> Cc: Hannes Reinecke
> Cc: stable
> ---
> drivers/scsi/hosts.c | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/drivers/scsi/hosts.c b/drivers/scsi/hosts.c
> index 323982f..82ac1cd 100644
> --- a/drivers/scsi/hosts.c
> +++ b/drivers/scsi/hosts.c
> @@ -333,6 +333,17 @@ static void scsi_host_dev_release(struct device
> *dev)
> kfree(queuedata);
> }
>
> + if (shost->shost_state == SHOST_CREATED) {
> + /*
> + * Free the shost_dev device name here if
> scsi_host_alloc()
> + * and scsi_host_put() have been called but neither
> + * scsi_host_add() nor scsi_host_remove() has been
> called.
> + * This avoids that the memory allocated for the
> shost_dev
> + * name is leaked.
> + */
> + kfree(dev_name(&shost->shost_dev));
> + }
> +
> scsi_destroy_command_freelist(shost);
> if (shost_use_blk_mq(shost)) {
> if (shost->tag_set.tags)
Reviewed-by: Johannes Thumshirn
--
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/3] sd: Make discard granularity match logical block size when LBPRZ=1
On Fri, 2015-11-13 at 16:46 -0500, Martin K. Petersen wrote:
> A device may report an OPTIMAL UNMAP GRANULARITY and UNMAP
> GRANULARITY
> ALIGNMENT in the Block Limits VPD. These parameters describe the
> device's internal provisioning allocation units. By default the block
> layer will round and align any discard requests based on these
> limits.
>
> If a device reports LBPRZ=1 to guarantee zeroes after discard,
> however,
> it is imperative that the block layer does not leave out any parts of
> the requested block range. Otherwise the device can not do the
> required
> zeroing of any partial allocation units and this can lead to data
> corruption.
>
> Since the dm thinp personality relies on the block layer's current
> behavior and is unable to deal with partial discard blocks we work
> around the problem by setting the granularity to match the logical
> block
> size when LBPRZ is enabled.
>
> Signed-off-by: Martin K. Petersen
> ---
> drivers/scsi/sd.c | 23 ++-
> 1 file changed, 18 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
> index 3f370228bf31..c322969026bc 100644
> --- a/drivers/scsi/sd.c
> +++ b/drivers/scsi/sd.c
> @@ -636,11 +636,24 @@ static void sd_config_discard(struct scsi_disk
> *sdkp, unsigned int mode)
> unsigned int max_blocks = 0;
>
> q->limits.discard_zeroes_data = 0;
> - q->limits.discard_alignment = sdkp->unmap_alignment *
> - logical_block_size;
> - q->limits.discard_granularity =
> - max(sdkp->physical_block_size,
> - sdkp->unmap_granularity * logical_block_size);
> +
> + /*
> + * When LBPRZ is reported, discard alignment and granularity
> + * must be fixed to the logical block size. Otherwise the
> block
> + * layer will drop misaligned portions of the request which
> can
> + * lead to data corruption. If LBPRZ is not set, we honor
> the
> + * device preference.
> + */
> + if (sdkp->lbprz) {
> + q->limits.discard_alignment = 0;
> + q->limits.discard_granularity = 1;
> + } else {
> + q->limits.discard_alignment = sdkp->unmap_alignment
> *
> + logical_block_size;
> + q->limits.discard_granularity =
> + max(sdkp->physical_block_size,
> + sdkp->unmap_granularity *
> logical_block_size);
> + }
>
> sdkp->provisioning_mode = mode;
>
Reviewed-by: Johannes Thumshirn
--
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: use sector_div instead of do_div
On 20/11/2015 18:38, Arnd Bergmann wrote: do_div is the wrong way to divide a sector_t, as it is less efficient when sector_t is 32-bit wide. With the upcoming do_div optimizations, the kernel starts warning about this: drivers/scsi/scsi_debug.c: In function 'dif_store': include/asm-generic/div64.h:207:28: warning: comparison of distinct pointer types lacks a cast This changes the code to use sector_div instead, which always produces optimal code. Signed-off-by: Arnd Bergmann Reviewed-by: Sagi Grimberg -- 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: [RFC PATCH scsi] aacraid: aac_release_resources() can be static
On Tue, 2015-11-10 at 13:59 +0800, kbuild test robot wrote:
> Signed-off-by: Fengguang Wu
> ---
> linit.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/scsi/aacraid/linit.c
> b/drivers/scsi/aacraid/linit.c
> index 37375cf..7724583f 100644
> --- a/drivers/scsi/aacraid/linit.c
> +++ b/drivers/scsi/aacraid/linit.c
> @@ -1318,7 +1318,7 @@ static int aac_probe_one(struct pci_dev *pdev,
> const struct pci_device_id *id)
> }
>
> #if (defined(CONFIG_PM))
> -void aac_release_resources(struct aac_dev *aac)
> +static void aac_release_resources(struct aac_dev *aac)
> {
> int i;
>
> --
> 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
Reviewed-by: Johannes Thumshirn
--
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: use sector_div instead of do_div
On Fri, 2015-11-20 at 17:38 +0100, Arnd Bergmann wrote:
> do_div is the wrong way to divide a sector_t, as it is less
> efficient when sector_t is 32-bit wide. With the upcoming
> do_div optimizations, the kernel starts warning about this:
>
> drivers/scsi/scsi_debug.c: In function 'dif_store':
> include/asm-generic/div64.h:207:28: warning: comparison of distinct
> pointer types lacks a cast
>
> This changes the code to use sector_div instead, which always
> produces optimal code.
>
> Signed-off-by: Arnd Bergmann
> ---
> Found on the ARM randconfig build today, after I merged Nico's
> patches
> for linux-next
>
> diff --git a/drivers/scsi/scsi_debug.c b/drivers/scsi/scsi_debug.c
> index dfcc45bb03b1..ec622ba9864a 100644
> --- a/drivers/scsi/scsi_debug.c
> +++ b/drivers/scsi/scsi_debug.c
> @@ -678,7 +678,7 @@ static void *fake_store(unsigned long long lba)
>
> static struct sd_dif_tuple *dif_store(sector_t sector)
> {
> - sector = do_div(sector, sdebug_store_sectors);
> + sector = sector_div(sector, sdebug_store_sectors);
>
> return dif_storep + sector;
> }
> @@ -2780,7 +2780,7 @@ static unsigned long lba_to_map_index(sector_t
> lba)
> lba += scsi_debug_unmap_granularity -
> scsi_debug_unmap_alignment;
> }
> - do_div(lba, scsi_debug_unmap_granularity);
> + sector_div(lba, scsi_debug_unmap_granularity);
>
> return lba;
> }
>
> --
> 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
Reviewed-by: Johannes Thumshirn
--
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 3/3] MAINTAINERS: Add myself as co-maintainer of the SCSI subsystem.
On Fri, 2015-11-13 at 16:46 -0500, Martin K. Petersen wrote: > Signed-off-by: Martin K. Petersen > --- > MAINTAINERS | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 9de185da5f5b..978df6e36ddf 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -9205,8 +9205,10 @@ F: include/scsi/sg.h > > SCSI SUBSYSTEM > M: "James E.J. Bottomley" > -L: linux-scsi@vger.kernel.org > T: git > git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git > +M: "Martin K. Petersen" > +T: git > git://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git > +L: linux-scsi@vger.kernel.org > S: Maintained > F: drivers/scsi/ > F: include/scsi/ Reviewed-by: Johannes Thumshirn -- 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/2] scsi_transport_fc: Introduce scsi_host_{get,put}()
On Fri, 2015-11-20 at 13:33 -0800, Bart Van Assche wrote:
> Use scsi_host_{get,put}() instead of open-coding these functions.
> Compile-tested only.
>
> Signed-off-by: Bart Van Assche
> Cc: Christoph Hellwig
> Cc: Hannes Reinecke
> Cc: James Smart
> Cc: stable
> ---
> drivers/scsi/scsi_transport_fc.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/scsi/scsi_transport_fc.c
> b/drivers/scsi/scsi_transport_fc.c
> index 24eaaf6..8a88226 100644
> --- a/drivers/scsi/scsi_transport_fc.c
> +++ b/drivers/scsi/scsi_transport_fc.c
> @@ -2586,7 +2586,7 @@ fc_rport_final_delete(struct work_struct *work)
> transport_remove_device(dev);
> device_del(dev);
> transport_destroy_device(dev);
> - put_device(&shost->shost_gendev); /* for fc_host-
> >rport list */
> + scsi_host_put(shost); /* for fc_host-
> >rport list */
> put_device(dev);/* for self-
> reference */
> }
>
> @@ -2650,7 +2650,7 @@ fc_rport_create(struct Scsi_Host *shost, int
> channel,
> else
> rport->scsi_target_id = -1;
> list_add_tail(&rport->peers, &fc_host->rports);
> - get_device(&shost->shost_gendev); /* for fc_host-
> >rport list */
> + scsi_host_get(shost); /* for fc_host-
> >rport list */
>
> spin_unlock_irqrestore(shost->host_lock, flags);
>
> @@ -2685,7 +2685,7 @@ delete_rport:
> transport_destroy_device(dev);
> spin_lock_irqsave(shost->host_lock, flags);
> list_del(&rport->peers);
> - put_device(&shost->shost_gendev); /* for fc_host-
> >rport list */
> + scsi_host_put(shost); /* for fc_host-
> >rport list */
> spin_unlock_irqrestore(shost->host_lock, flags);
> put_device(dev->parent);
> kfree(rport);
> @@ -3383,7 +3383,7 @@ fc_vport_setup(struct Scsi_Host *shost, int
> channel, struct device *pdev,
> fc_host->npiv_vports_inuse++;
> vport->number = fc_host->next_vport_number++;
> list_add_tail(&vport->peers, &fc_host->vports);
> - get_device(&shost->shost_gendev); /* for fc_host-
> >vport list */
> + scsi_host_get(shost); /* for fc_host-
> >vport list */
>
> spin_unlock_irqrestore(shost->host_lock, flags);
>
> @@ -3441,7 +3441,7 @@ delete_vport:
> transport_destroy_device(dev);
> spin_lock_irqsave(shost->host_lock, flags);
> list_del(&vport->peers);
> - put_device(&shost->shost_gendev); /* for fc_host-
> >vport list */
> + scsi_host_put(shost); /* for fc_host-
> >vport list */
> fc_host->npiv_vports_inuse--;
> spin_unlock_irqrestore(shost->host_lock, flags);
> put_device(dev->parent);
> @@ -3504,7 +3504,7 @@ fc_vport_terminate(struct fc_vport *vport)
> vport->flags |= FC_VPORT_DELETED;
> list_del(&vport->peers);
> fc_host->npiv_vports_inuse--;
> - put_device(&shost->shost_gendev); /* for fc_host-
> >vport list */
> + scsi_host_put(shost); /* for fc_host-
> >vport list */
> }
> spin_unlock_irqrestore(shost->host_lock, flags);
>
Reviewed-by: Johannes Thumshirn
--
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
Reviews, please
I spent last night cleaning up patchwork. Not entirely done yet but
getting down to a manageable size:
https://patchwork.kernel.org/project/linux-scsi/list/
These are 4.4 fixes that I'd like to get some more reviews for:
scsi_debug: fix prevent_allow+verify regressions
https://patchwork.kernel.org/patch/7676711/
Fix a bdi reregistration race, v2
https://patchwork.kernel.org/patch/7671671/
Revert "scsi: Fix a bdi reregistration race"
https://patchwork.kernel.org/patch/7671661/
[2/2] Fix a memory leak in scsi_host_dev_release()
https://patchwork.kernel.org/patch/7671391/
[1/2] scsi_transport_fc: Introduce scsi_host_{get,put}()
https://patchwork.kernel.org/patch/7671381/
[3/3] MAINTAINERS: Add myself as co-maintainer of the SCSI subsystem.
https://patchwork.kernel.org/patch/7614881/
[2/3] block/sd: Fix device-imposed transfer length limits
https://patchwork.kernel.org/patch/7614871/
[1/3] sd: Make discard granularity match logical block size when LBPRZ=1
https://patchwork.kernel.org/patch/7614861/
And for 4.5 the following ones are low-hanging fruit.
scsi: hisi_sas: remove dependency on of_irq_count
https://patchwork.kernel.org/patch/7656691/
scsi: use sector_div instead of do_div
https://patchwork.kernel.org/patch/7669841/
mvsas: add SGPIO support to Marvell 94xx
https://patchwork.kernel.org/patch/7610411/
aacraid: aac_release_resources() can be static
https://patchwork.kernel.org/patch/7588331/
I staged the reviewed portion of Finn's ncr5380 series last week but it
looks like there is some issues to be worked out. So I'll let that
simmer in a different branch for now.
I will take a look at the ALUA series today. And then there's the
mountain of UFS related patch series...
--
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: [PATCH 18/18] scsi_dh_alua: use scsi_vpd_tpg_id()
On Mon, 2015-11-09 at 16:08 +0100, Hannes Reinecke wrote:
> Signed-off-by: Hannes Reinecke
> ---
> drivers/scsi/device_handler/scsi_dh_alua.c | 39 +---
> --
> 1 file changed, 6 insertions(+), 33 deletions(-)
>
> diff --git a/drivers/scsi/device_handler/scsi_dh_alua.c
> b/drivers/scsi/device_handler/scsi_dh_alua.c
> index abf05b4..20fe981 100644
> --- a/drivers/scsi/device_handler/scsi_dh_alua.c
> +++ b/drivers/scsi/device_handler/scsi_dh_alua.c
> @@ -320,38 +320,10 @@ static int alua_check_tpgs(struct scsi_device
> *sdev)
> */
> static int alua_check_vpd(struct scsi_device *sdev, struct
> alua_dh_data *h)
> {
> - unsigned char *d;
> - unsigned char __rcu *vpd_pg83;
> + int rel_port = -1, group_id;
>
> - rcu_read_lock();
> - if (!rcu_dereference(sdev->vpd_pg83)){
> - rcu_read_unlock();
> - return SCSI_DH_DEV_UNSUPP;
> - }
> -
> - /*
> - * Look for the correct descriptor.
> - */
> - vpd_pg83 = rcu_dereference(sdev->vpd_pg83);
> - d = vpd_pg83 + 4;
> - while (d < vpd_pg83 + sdev->vpd_pg83_len) {
> - switch (d[1] & 0xf) {
> - case 0x4:
> - /* Relative target port */
> - h->rel_port = get_unaligned_be16(&d[6]);
> - break;
> - case 0x5:
> - /* Target port group */
> - h->group_id = get_unaligned_be16(&d[6]);
> - break;
> - default:
> - break;
> - }
> - d += d[3] + 4;
> - }
> - rcu_read_unlock();
> -
> - if (h->group_id == -1) {
> + group_id = scsi_vpd_tpg_id(sdev, &rel_port);
> + if (group_id < 0) {
> /*
> * Internal error; TPGS supported but required
> * VPD identification descriptors not present.
> @@ -360,10 +332,11 @@ static int alua_check_vpd(struct scsi_device
> *sdev, struct alua_dh_data *h)
> sdev_printk(KERN_INFO, sdev,
> "%s: No target port descriptors
> found\n",
> ALUA_DH_NAME);
> - h->state = TPGS_STATE_OPTIMIZED;
> - h->tpgs = TPGS_MODE_NONE;
> return SCSI_DH_DEV_UNSUPP;
> }
> + h->rel_port = rel_port;
> + h->group_id = group_id;
> +
> sdev_printk(KERN_INFO, sdev,
> "%s: port group %02x rel port %02x\n",
> ALUA_DH_NAME, h->group_id, h->rel_port);
Reviewed-by: Johannes Thumshirn
--
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 17/18] scsi: Add scsi_vpd_tpg_id()
On Mon, 2015-11-09 at 16:08 +0100, Hannes Reinecke wrote:
> Implement scsi_vpd_tpg_id() to extract the target
> port group id and the relative port id from
> SCSI VPD page 0x83.
>
> Signed-off-by: Hannes Reinecke
> ---
> drivers/scsi/scsi_lib.c| 48
> ++
> include/scsi/scsi_device.h | 1 +
> 2 files changed, 49 insertions(+)
>
> diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
> index 3cb295c..d12edc8 100644
> --- a/drivers/scsi/scsi_lib.c
> +++ b/drivers/scsi/scsi_lib.c
> @@ -23,6 +23,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -3294,3 +3295,50 @@ next_desig:
> return id_size;
> }
> EXPORT_SYMBOL(scsi_vpd_lun_id);
> +
> +/*
> + * scsi_vpd_tpg_id - return a target port group identifier
> + * @sdev: SCSI device
> + *
> + * Returns the Target Port Group identifier from the information
> + * froom VPD page 0x83 of the device.
> + *
> + * Returns the identifier or error on failure.
> + */
> +int scsi_vpd_tpg_id(struct scsi_device *sdev, int *rel_id)
> +{
> + unsigned char *d;
> + unsigned char __rcu *vpd_pg83;
> + int group_id = -EAGAIN, rel_port = -1;
> +
> + rcu_read_lock();
> + vpd_pg83 = rcu_dereference(sdev->vpd_pg83);
> + if (!vpd_pg83) {
> + rcu_read_unlock();
> + return -ENXIO;
> + }
> +
> + d = sdev->vpd_pg83 + 4;
> + while (d < sdev->vpd_pg83 + sdev->vpd_pg83_len) {
> + switch (d[1] & 0xf) {
> + case 0x4:
> + /* Relative target port */
> + rel_port = get_unaligned_be16(&d[6]);
> + break;
> + case 0x5:
> + /* Target port group */
> + group_id = get_unaligned_be16(&d[6]);
> + break;
> + default:
> + break;
> + }
> + d += d[3] + 4;
> + }
> + rcu_read_unlock();
> +
> + if (group_id >= 0 && rel_id && rel_port != -1)
> + *rel_id = rel_port;
> +
> + return group_id;
> +}
> +EXPORT_SYMBOL(scsi_vpd_tpg_id);
> diff --git a/include/scsi/scsi_device.h b/include/scsi/scsi_device.h
> index 4c49cfa..f63a167 100644
> --- a/include/scsi/scsi_device.h
> +++ b/include/scsi/scsi_device.h
> @@ -416,6 +416,7 @@ static inline int scsi_execute_req(struct
> scsi_device *sdev,
> extern void sdev_disable_disk_events(struct scsi_device *sdev);
> extern void sdev_enable_disk_events(struct scsi_device *sdev);
> extern int scsi_vpd_lun_id(struct scsi_device *, char *, size_t);
> +extern int scsi_vpd_tpg_id(struct scsi_device *, int *);
>
> #ifdef CONFIG_PM
> extern int scsi_autopm_get_device(struct scsi_device *);
Reviewed-by: Johannes Thumshirn
--
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 16/18] scsi: export 'device_id' to sysfs
On Mon, 2015-11-09 at 16:08 +0100, Hannes Reinecke wrote:
> Use scsi_vpd_lun_id() to export the device id to sysfs.
>
> Signed-off-by: Hannes Reinecke
> ---
> drivers/scsi/scsi_sysfs.c | 17 +
> 1 file changed, 17 insertions(+)
>
> diff --git a/drivers/scsi/scsi_sysfs.c b/drivers/scsi/scsi_sysfs.c
> index 7b41b2c..aaa38c2 100644
> --- a/drivers/scsi/scsi_sysfs.c
> +++ b/drivers/scsi/scsi_sysfs.c
> @@ -903,6 +903,22 @@ sdev_show_function(queue_depth, "%d\n");
> static DEVICE_ATTR(queue_depth, S_IRUGO | S_IWUSR,
> sdev_show_queue_depth,
> sdev_store_queue_depth);
>
> +static ssize_t
> +sdev_show_device_id(struct device *dev, struct device_attribute
> *attr,
> + char *buf)
> +{
> + struct scsi_device *sdev = to_scsi_device(dev);
> + ssize_t count;
> +
> + count = scsi_vpd_lun_id(sdev, buf, PAGE_SIZE);
> + if (count > 0) {
> + buf[count] = '\n';
> + count++;
> + }
> + return count;
> +}
> +static DEVICE_ATTR(device_id, S_IRUGO, sdev_show_device_id, NULL);
> +
> #ifdef CONFIG_SCSI_DH
> static ssize_t
> sdev_show_dh_state(struct device *dev, struct device_attribute
> *attr,
> @@ -1026,6 +1042,7 @@ static struct attribute *scsi_sdev_attrs[] = {
> &dev_attr_modalias.attr,
> &dev_attr_queue_depth.attr,
> &dev_attr_queue_type.attr,
> + &dev_attr_device_id.attr,
> #ifdef CONFIG_SCSI_DH
> &dev_attr_dh_state.attr,
> #endif
Reviewed-by: Johannes Thumshirn
--
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 15/18] scsi: Add scsi_vpd_lun_id()
On Mon, 2015-11-09 at 16:08 +0100, Hannes Reinecke wrote:
> Add a function scsi_vpd_lun_id() to return a unique device
> identifcation based on the designation descriptors of
> VPD page 0x83.
>
> As devices might implement several descriptors the order
> of preference is:
> - NAA IEE Registered Extended
> - EUI-64 based 16-byte
> - EUI-64 based 12-byte
> - NAA IEEE Registered
> - NAA IEEE Extended
> A SCSI name string descriptor is preferred to all of them
> if the identification is longer than 16 bytes.
>
> The returned unique device identification will be formatted
> as a SCSI Name string to avoid clashes between different
> designator types.
>
> Reviewed-by: Ewan Milne
> Reviewed-by: Christoph Hellwig
> Signed-off-by: Hannes Reinecke
> ---
> drivers/scsi/scsi_lib.c| 140
> +
> include/scsi/scsi_device.h | 1 +
> 2 files changed, 141 insertions(+)
>
> diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
> index cbfc599..3cb295c 100644
> --- a/drivers/scsi/scsi_lib.c
> +++ b/drivers/scsi/scsi_lib.c
> @@ -3154,3 +3154,143 @@ void sdev_enable_disk_events(struct
> scsi_device *sdev)
> atomic_dec(&sdev->disk_events_disable_depth);
> }
> EXPORT_SYMBOL(sdev_enable_disk_events);
> +
> +/*
> + * scsi_vpd_lun_id - return a unique device identification
> + * @sdev: SCSI device
> + * @id: buffer for the identification
> + * @id_len: length of the buffer
> + *
> + * Copies a unique device identification into @id based
> + * on the information in the VPD page 0x83 of the device.
> + * The string will be formatted as a SCSI name string.
> + *
> + * Returns the length of the identification or error on failure.
> + * If the identifier is longer than the supplied buffer the actual
> + * identifier length is returned and the buffer is not zero-padded.
> + */
> +int scsi_vpd_lun_id(struct scsi_device *sdev, char *id, size_t
> id_len)
> +{
> + u8 cur_id_type = 0xff;
> + u8 cur_id_size = 0;
> + unsigned char *d, *cur_id_str;
> + unsigned char __rcu *vpd_pg83;
> + int id_size = -EINVAL;
> +
> + rcu_read_lock();
> + vpd_pg83 = rcu_dereference(sdev->vpd_pg83);
> + if (!vpd_pg83) {
> + rcu_read_unlock();
> + return -ENXIO;
> + }
> +
> + /*
> + * Look for the correct descriptor.
> + * Order of preference for lun descriptor:
> + * - SCSI name string
> + * - NAA IEEE Registered Extended
> + * - EUI-64 based 16-byte
> + * - EUI-64 based 12-byte
> + * - NAA IEEE Registered
> + * - NAA IEEE Extended
> + * as longer descriptors reduce the likelyhood
> + * of identification clashes.
> + */
> +
> + /* The id string must be at least 20 bytes + terminating
> NULL byte */
> + if (id_len < 21) {
> + rcu_read_unlock();
> + return -EINVAL;
> + }
> +
> + memset(id, 0, id_len);
> + d = vpd_pg83 + 4;
> + while (d < vpd_pg83 + sdev->vpd_pg83_len) {
> + /* Skip designators not referring to the LUN */
> + if ((d[1] & 0x30) != 0x00)
> + goto next_desig;
> +
> + switch (d[1] & 0xf) {
> + case 0x2:
> + /* EUI-64 */
> + if (cur_id_size > d[3])
> + break;
> + /* Prefer NAA IEEE Registered Extended */
> + if (cur_id_type == 0x3 &&
> + cur_id_size == d[3])
> + break;
> + cur_id_size = d[3];
> + cur_id_str = d + 4;
> + cur_id_type = d[1] & 0xf;
> + switch (cur_id_size) {
> + case 8:
> + id_size = snprintf(id, id_len,
> + "eui.%8phN",
> + cur_id_str);
> + break;
> + case 12:
> + id_size = snprintf(id, id_len,
> + "eui.%12phN",
> + cur_id_str);
> + break;
> + case 16:
> + id_size = snprintf(id, id_len,
> + "eui.%16phN",
> + cur_id_str);
> + break;
> + default:
> + cur_id_size = 0;
> + break;
> + }
> + break;
> + case 0x3:
> + /* NAA */
> + if (cur_id_size > d[3])
> + break;
> + cur_id_size = d[3];
> + cur_id_str = d + 4;
> + cur_id_type = d[1] & 0xf;
> +
Re: [PATCH 14/18] scsi_dh_alua: simplify sense code handling
On Mon, 2015-11-09 at 16:08 +0100, Hannes Reinecke wrote:
> Most sense code is already handled in the generic
> code, so we shouldn't be adding special cases here.
> However, when doing so we need to check for
> unit attention whenever we're sending an internal
> command.
>
> Reviewed-by: Ewan Milne
> Reviewed-by: Christoph Hellwig
> Signed-off-by: Hannes Reinecke
> ---
> drivers/scsi/device_handler/scsi_dh_alua.c | 45 +++-
> --
> 1 file changed, 17 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/scsi/device_handler/scsi_dh_alua.c
> b/drivers/scsi/device_handler/scsi_dh_alua.c
> index c9751c9..abf05b4 100644
> --- a/drivers/scsi/device_handler/scsi_dh_alua.c
> +++ b/drivers/scsi/device_handler/scsi_dh_alua.c
> @@ -85,7 +85,6 @@ struct alua_dh_data {
> #define ALUA_POLICY_SWITCH_ALL 1
>
> static char print_alua_state(int);
> -static int alua_check_sense(struct scsi_device *, struct
> scsi_sense_hdr *);
>
> static int realloc_buffer(struct alua_dh_data *h, unsigned len)
> {
> @@ -189,8 +188,13 @@ static void stpg_endio(struct request *req, int
> error)
>
> if (scsi_normalize_sense(h->sense, SCSI_SENSE_BUFFERSIZE,
> &sense_hdr)) {
> - err = alua_check_sense(h->sdev, &sense_hdr);
> - if (err == ADD_TO_MLQUEUE) {
> + if (sense_hdr.sense_key == NOT_READY &&
> + sense_hdr.asc == 0x04 && sense_hdr.ascq == 0x0a)
> {
> + /* ALUA state transition already in progress
> */
> + err = SCSI_DH_OK;
> + goto done;
> + }
> + if (sense_hdr.sense_key == UNIT_ATTENTION) {
> err = SCSI_DH_RETRY;
> goto done;
> }
> @@ -399,28 +403,6 @@ static int alua_check_sense(struct scsi_device
> *sdev,
> * LUN Not Accessible - ALUA state
> transition
> */
> return ADD_TO_MLQUEUE;
> - if (sense_hdr->asc == 0x04 && sense_hdr->ascq ==
> 0x0b)
> - /*
> - * LUN Not Accessible -- Target port in
> standby state
> - */
> - return SUCCESS;
> - if (sense_hdr->asc == 0x04 && sense_hdr->ascq ==
> 0x0c)
> - /*
> - * LUN Not Accessible -- Target port in
> unavailable state
> - */
> - return SUCCESS;
> - if (sense_hdr->asc == 0x04 && sense_hdr->ascq ==
> 0x12)
> - /*
> - * LUN Not Ready -- Offline
> - */
> - return SUCCESS;
> - if (sdev->allow_restart &&
> - sense_hdr->asc == 0x04 && sense_hdr->ascq ==
> 0x02)
> - /*
> - * if the device is not started, we need to
> wake
> - * the error handler to start the motor
> - */
> - return FAILED;
> break;
> case UNIT_ATTENTION:
> if (sense_hdr->asc == 0x29 && sense_hdr->ascq ==
> 0x00)
> @@ -517,9 +499,16 @@ static int alua_rtpg(struct scsi_device *sdev,
> struct alua_dh_data *h, int wait_
> h->flags |= ALUA_RTPG_EXT_HDR_UNSUPP;
> goto retry;
> }
> -
> - err = alua_check_sense(sdev, &sense_hdr);
> - if (err == ADD_TO_MLQUEUE && time_before(jiffies,
> expiry)) {
> + /*
> + * Retry on ALUA state transition or if any
> + * UNIT ATTENTION occurred.
> + */
> + if (sense_hdr.sense_key == NOT_READY &&
> + sense_hdr.asc == 0x04 && sense_hdr.ascq == 0x0a)
> + err = SCSI_DH_RETRY;
> + else if (sense_hdr.sense_key == UNIT_ATTENTION)
> + err = SCSI_DH_RETRY;
> + if (err == SCSI_DH_RETRY && time_before(jiffies,
> expiry)) {
> sdev_printk(KERN_ERR, sdev, "%s: rtpg
> retry\n",
> ALUA_DH_NAME);
> scsi_print_sense_hdr(sdev, ALUA_DH_NAME,
> &sense_hdr);
Reviewed-by: Johannes Thumshirn
--
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 10/18] scsi: remove scsi_show_sense_hdr()
On Mon, 2015-11-09 at 16:08 +0100, Hannes Reinecke wrote: > Last caller is gone, so remove it. > > Reviewed-by: Bart Van Assche > Reviewed-by: Christoph Hellwig > Reviewed-by: Martin K. Petersen > Signed-off-by: Hannes Reinecke > --- > include/scsi/scsi_dbg.h | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/include/scsi/scsi_dbg.h b/include/scsi/scsi_dbg.h > index f8170e9..56710e0 100644 > --- a/include/scsi/scsi_dbg.h > +++ b/include/scsi/scsi_dbg.h > @@ -12,8 +12,6 @@ extern size_t __scsi_format_command(char *, size_t, > const unsigned char *, size_t); > extern void scsi_show_extd_sense(const struct scsi_device *, const > char *, > unsigned char, unsigned char); > -extern void scsi_show_sense_hdr(const struct scsi_device *, const > char *, > - const struct scsi_sense_hdr *); > extern void scsi_print_sense_hdr(const struct scsi_device *, const > char *, > const struct scsi_sense_hdr *); > extern void scsi_print_sense(const struct scsi_cmnd *); Reviewed-by: Johannes Thumshirn -- 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 08/18] scsi_dh_alua: return standard SCSI return codes in submit_rtpg
On Mon, 2015-11-09 at 16:08 +0100, Hannes Reinecke wrote:
> Fixup submit_rtpg() to always return a standard SCSI return code.
>
> Signed-off-by: Hannes Reinecke
> ---
> drivers/scsi/device_handler/scsi_dh_alua.c | 33 +++-
> --
> 1 file changed, 17 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/scsi/device_handler/scsi_dh_alua.c
> b/drivers/scsi/device_handler/scsi_dh_alua.c
> index b817963..50fe87c 100644
> --- a/drivers/scsi/device_handler/scsi_dh_alua.c
> +++ b/drivers/scsi/device_handler/scsi_dh_alua.c
> @@ -138,11 +138,13 @@ static unsigned submit_rtpg(struct scsi_device
> *sdev, struct alua_dh_data *h,
> bool rtpg_ext_hdr_req)
> {
> struct request *rq;
> - int err = SCSI_DH_RES_TEMP_UNAVAIL;
> + int err = 0;
>
> rq = get_alua_req(sdev, h->buff, h->bufflen, READ);
> - if (!rq)
> + if (!rq) {
> + err = DRIVER_BUSY << 24;
> goto done;
> + }
>
> /* Prepare the command. */
> rq->cmd[0] = MAINTENANCE_IN;
> @@ -160,13 +162,9 @@ static unsigned submit_rtpg(struct scsi_device
> *sdev, struct alua_dh_data *h,
> memset(rq->sense, 0, SCSI_SENSE_BUFFERSIZE);
> rq->sense_len = 0;
>
> - err = blk_execute_rq(rq->q, NULL, rq, 1);
> - if (err == -EIO) {
> - sdev_printk(KERN_INFO, sdev,
> - "%s: rtpg failed with %x\n",
> - ALUA_DH_NAME, rq->errors);
> - err = SCSI_DH_IO;
> - }
> + blk_execute_rq(rq->q, NULL, rq, 1);
> + if (rq->errors)
> + err = rq->errors;
> blk_put_request(rq);
> done:
> return err;
> @@ -493,7 +491,7 @@ static int alua_rtpg(struct scsi_device *sdev,
> struct alua_dh_data *h, int wait_
> struct scsi_sense_hdr sense_hdr;
> int len, k, off, valid_states = 0;
> unsigned char *ucp;
> - unsigned err;
> + unsigned err, retval;
> bool rtpg_ext_hdr_req = 1;
> unsigned long expiry, interval = 0;
> unsigned int tpg_desc_tbl_off;
> @@ -505,12 +503,17 @@ static int alua_rtpg(struct scsi_device *sdev,
> struct alua_dh_data *h, int wait_
> expiry = round_jiffies_up(jiffies + h-
> >transition_tmo * HZ);
>
> retry:
> - err = submit_rtpg(sdev, h, rtpg_ext_hdr_req);
> -
> - if (err == SCSI_DH_IO) {
> + retval = submit_rtpg(sdev, h, rtpg_ext_hdr_req);
> + if (retval) {
> if (!scsi_normalize_sense(h->sense,
> SCSI_SENSE_BUFFERSIZE,
> - &sense_hdr))
> + &sense_hdr)) {
> + sdev_printk(KERN_INFO, sdev,
> + "%s: rtpg failed, result %d\n",
> + ALUA_DH_NAME, retval);
> + if (driver_byte(retval) == DRIVER_BUSY)
> + return SCSI_DH_DEV_TEMP_BUSY;
> return SCSI_DH_IO;
> + }
>
> /*
> * submit_rtpg() has failed on existing arrays
> @@ -539,8 +542,6 @@ static int alua_rtpg(struct scsi_device *sdev,
> struct alua_dh_data *h, int wait_
> scsi_print_sense_hdr(sdev, ALUA_DH_NAME,
> &sense_hdr);
> return SCSI_DH_IO;
> }
> - if (err != SCSI_DH_OK)
> - return err;
>
> len = (h->buff[0] << 24) + (h->buff[1] << 16) +
> (h->buff[2] << 8) + h->buff[3] + 4;
Reviewed-by: Johannes Thumshirn
--
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 11/18] scsi_dh_alua: use flag for RTPG extended header
On Mon, 2015-11-09 at 16:08 +0100, Hannes Reinecke wrote:
> We should be using a flag when RTPG extended header is not
> supported, that saves us sending RTPG twice for older arrays.
>
> Reviewed-by: Bart Van Assche
> Reviewed-by: Christoph Hellwig
> Reviewed-by: Martin K. Petersen
> Signed-off-by: Hannes Reinecke
> ---
> drivers/scsi/device_handler/scsi_dh_alua.c | 15 +++
> 1 file changed, 7 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/scsi/device_handler/scsi_dh_alua.c
> b/drivers/scsi/device_handler/scsi_dh_alua.c
> index ea626732..03f8190 100644
> --- a/drivers/scsi/device_handler/scsi_dh_alua.c
> +++ b/drivers/scsi/device_handler/scsi_dh_alua.c
> @@ -59,8 +59,9 @@
> #define ALUA_FAILOVER_TIMEOUT60
> #define ALUA_FAILOVER_RETRIES5
>
> -/* flags passed from user level */
> +/* device handler flags */
> #define ALUA_OPTIMIZE_STPG 1
> +#define ALUA_RTPG_EXT_HDR_UNSUPP 2
>
> struct alua_dh_data {
> int group_id;
> @@ -134,8 +135,7 @@ static struct request *get_alua_req(struct
> scsi_device *sdev,
> * submit_rtpg - Issue a REPORT TARGET GROUP STATES command
> * @sdev: sdev the command should be sent to
> */
> -static unsigned submit_rtpg(struct scsi_device *sdev, struct
> alua_dh_data *h,
> - bool rtpg_ext_hdr_req)
> +static unsigned submit_rtpg(struct scsi_device *sdev, struct
> alua_dh_data *h)
> {
> struct request *rq;
> int err = 0;
> @@ -148,7 +148,7 @@ static unsigned submit_rtpg(struct scsi_device
> *sdev, struct alua_dh_data *h,
>
> /* Prepare the command. */
> rq->cmd[0] = MAINTENANCE_IN;
> - if (rtpg_ext_hdr_req)
> + if (!(h->flags & ALUA_RTPG_EXT_HDR_UNSUPP))
> rq->cmd[1] = MI_REPORT_TARGET_PGS |
> MI_EXT_HDR_PARAM_FMT;
> else
> rq->cmd[1] = MI_REPORT_TARGET_PGS;
> @@ -490,7 +490,6 @@ static int alua_rtpg(struct scsi_device *sdev,
> struct alua_dh_data *h, int wait_
> int len, k, off, valid_states = 0;
> unsigned char *ucp;
> unsigned err, retval;
> - bool rtpg_ext_hdr_req = 1;
> unsigned long expiry, interval = 0;
> unsigned int tpg_desc_tbl_off;
> unsigned char orig_transition_tmo;
> @@ -501,7 +500,7 @@ static int alua_rtpg(struct scsi_device *sdev,
> struct alua_dh_data *h, int wait_
> expiry = round_jiffies_up(jiffies + h-
> >transition_tmo * HZ);
>
> retry:
> - retval = submit_rtpg(sdev, h, rtpg_ext_hdr_req);
> + retval = submit_rtpg(sdev, h);
> if (retval) {
> if (!scsi_normalize_sense(h->sense,
> SCSI_SENSE_BUFFERSIZE,
> &sense_hdr)) {
> @@ -521,10 +520,10 @@ static int alua_rtpg(struct scsi_device *sdev,
> struct alua_dh_data *h, int wait_
> * The retry without rtpg_ext_hdr_req set
> * handles this.
> */
> - if (rtpg_ext_hdr_req == 1 &&
> + if (!(h->flags & ALUA_RTPG_EXT_HDR_UNSUPP) &&
> sense_hdr.sense_key == ILLEGAL_REQUEST &&
> sense_hdr.asc == 0x24 && sense_hdr.ascq == 0) {
> - rtpg_ext_hdr_req = 0;
> + h->flags |= ALUA_RTPG_EXT_HDR_UNSUPP;
> goto retry;
> }
>
Reviewed-by: Johannes Thumshirn
--
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 09/18] scsi_dh_alua: fixup description of stpg_endio()
On Mon, 2015-11-09 at 16:08 +0100, Hannes Reinecke wrote:
> Fixup copy-and-paste error in the description of stpg_endio().
>
> Signed-off-by: Hannes Reinecke
> Reviewed-by: Christoph Hellwig
> Reviewed-by: Martin K. Petersen
> ---
> drivers/scsi/device_handler/scsi_dh_alua.c | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/scsi/device_handler/scsi_dh_alua.c
> b/drivers/scsi/device_handler/scsi_dh_alua.c
> index 50fe87c..ea626732 100644
> --- a/drivers/scsi/device_handler/scsi_dh_alua.c
> +++ b/drivers/scsi/device_handler/scsi_dh_alua.c
> @@ -171,13 +171,11 @@ done:
> }
>
> /*
> - * alua_stpg - Evaluate SET TARGET GROUP STATES
> + * stpg_endio - Evaluate SET TARGET GROUP STATES
> * @sdev: the device to be evaluated
> * @state: the new target group state
> *
> - * Send a SET TARGET GROUP STATES command to the device.
> - * We only have to test here if we should resubmit the command;
> - * any other error is assumed as a failure.
> + * Evaluate a SET TARGET GROUP STATES command response.
> */
> static void stpg_endio(struct request *req, int error)
> {
Reviewed-by: Johannes Thumshirn
--
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/18] scsi_dh_alua: use unaligned access macros
On Mon, 2015-11-09 at 16:08 +0100, Hannes Reinecke wrote:
> Use 'get_unaligned_XX' and 'put_unaligned_XX' instead of
> open-coding it.
>
> Reviewed-by: Martin K. Petersen
> Reviewed-by: Christoph Hellwig
> Signed-off-by: Hannes Reinecke
> ---
> drivers/scsi/device_handler/scsi_dh_alua.c | 23 --
> -
> 1 file changed, 8 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/scsi/device_handler/scsi_dh_alua.c
> b/drivers/scsi/device_handler/scsi_dh_alua.c
> index 03f8190..d54f42e 100644
> --- a/drivers/scsi/device_handler/scsi_dh_alua.c
> +++ b/drivers/scsi/device_handler/scsi_dh_alua.c
> @@ -22,6 +22,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -152,10 +153,7 @@ static unsigned submit_rtpg(struct scsi_device
> *sdev, struct alua_dh_data *h)
> rq->cmd[1] = MI_REPORT_TARGET_PGS |
> MI_EXT_HDR_PARAM_FMT;
> else
> rq->cmd[1] = MI_REPORT_TARGET_PGS;
> - rq->cmd[6] = (h->bufflen >> 24) & 0xff;
> - rq->cmd[7] = (h->bufflen >> 16) & 0xff;
> - rq->cmd[8] = (h->bufflen >> 8) & 0xff;
> - rq->cmd[9] = h->bufflen & 0xff;
> + put_unaligned_be32(h->bufflen, &rq->cmd[6]);
> rq->cmd_len = COMMAND_SIZE(MAINTENANCE_IN);
>
> rq->sense = h->sense;
> @@ -236,8 +234,7 @@ static unsigned submit_stpg(struct alua_dh_data
> *h)
> /* Prepare the data buffer */
> memset(h->buff, 0, stpg_len);
> h->buff[4] = TPGS_STATE_OPTIMIZED & 0x0f;
> - h->buff[6] = (h->group_id >> 8) & 0xff;
> - h->buff[7] = h->group_id & 0xff;
> + put_unaligned_be16(h->group_id, &h->buff[6]);
>
> rq = get_alua_req(sdev, h->buff, stpg_len, WRITE);
> if (!rq)
> @@ -246,10 +243,7 @@ static unsigned submit_stpg(struct alua_dh_data
> *h)
> /* Prepare the command. */
> rq->cmd[0] = MAINTENANCE_OUT;
> rq->cmd[1] = MO_SET_TARGET_PGS;
> - rq->cmd[6] = (stpg_len >> 24) & 0xff;
> - rq->cmd[7] = (stpg_len >> 16) & 0xff;
> - rq->cmd[8] = (stpg_len >> 8) & 0xff;
> - rq->cmd[9] = stpg_len & 0xff;
> + put_unaligned_be32(stpg_len, &rq->cmd[6]);
> rq->cmd_len = COMMAND_SIZE(MAINTENANCE_OUT);
>
> rq->sense = h->sense;
> @@ -343,11 +337,11 @@ static int alua_check_vpd(struct scsi_device
> *sdev, struct alua_dh_data *h)
> switch (d[1] & 0xf) {
> case 0x4:
> /* Relative target port */
> - h->rel_port = (d[6] << 8) + d[7];
> + h->rel_port = get_unaligned_be16(&d[6]);
> break;
> case 0x5:
> /* Target port group */
> - h->group_id = (d[6] << 8) + d[7];
> + h->group_id = get_unaligned_be16(&d[6]);
> break;
> default:
> break;
> @@ -540,8 +534,7 @@ static int alua_rtpg(struct scsi_device *sdev,
> struct alua_dh_data *h, int wait_
> return SCSI_DH_IO;
> }
>
> - len = (h->buff[0] << 24) + (h->buff[1] << 16) +
> - (h->buff[2] << 8) + h->buff[3] + 4;
> + len = get_unaligned_be32(&h->buff[0]) + 4;
>
> if (len > h->bufflen) {
> /* Resubmit with the correct length */
> @@ -576,7 +569,7 @@ static int alua_rtpg(struct scsi_device *sdev,
> struct alua_dh_data *h, int wait_
> k < len;
> k += off, ucp += off) {
>
> - if (h->group_id == (ucp[2] << 8) + ucp[3]) {
> + if (h->group_id == get_unaligned_be16(&ucp[2])) {
> h->state = ucp[0] & 0x0f;
> h->pref = ucp[0] >> 7;
> valid_states = ucp[1];
Reviewed-by: Johannes Thumshirn
--
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 13/18] scsi_dh_alua: rework alua_check_tpgs() to return the tpgs mode
On Mon, 2015-11-09 at 16:08 +0100, Hannes Reinecke wrote:
> Instead of returning an error code in alua_check_tpgs() we should
> rather return the tpgs mode directly and have a cleaner syntax.
>
> Signed-off-by: Hannes Reinecke
> ---
> drivers/scsi/device_handler/scsi_dh_alua.c | 25 +++-
> -
> 1 file changed, 11 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/scsi/device_handler/scsi_dh_alua.c
> b/drivers/scsi/device_handler/scsi_dh_alua.c
> index d54f42e..c9751c9 100644
> --- a/drivers/scsi/device_handler/scsi_dh_alua.c
> +++ b/drivers/scsi/device_handler/scsi_dh_alua.c
> @@ -262,24 +262,23 @@ static unsigned submit_stpg(struct alua_dh_data
> *h)
> * Examine the TPGS setting of the sdev to find out if ALUA
> * is supported.
> */
> -static int alua_check_tpgs(struct scsi_device *sdev, struct
> alua_dh_data *h)
> +static int alua_check_tpgs(struct scsi_device *sdev)
> {
> - int err = SCSI_DH_OK;
> + int tpgs = TPGS_MODE_NONE;
>
> /*
> * ALUA support for non-disk devices is fraught with
> * difficulties, so disable it for now.
> */
> if (sdev->type != TYPE_DISK) {
> - h->tpgs = TPGS_MODE_NONE;
> sdev_printk(KERN_INFO, sdev,
> "%s: disable for non-disk devices\n",
> ALUA_DH_NAME);
> - return SCSI_DH_DEV_UNSUPP;
> + return tpgs;
> }
>
> - h->tpgs = scsi_device_tpgs(sdev);
> - switch (h->tpgs) {
> + tpgs = scsi_device_tpgs(sdev);
> + switch (tpgs) {
> case TPGS_MODE_EXPLICIT|TPGS_MODE_IMPLICIT:
> sdev_printk(KERN_INFO, sdev,
> "%s: supports implicit and explicit
> TPGS\n",
> @@ -296,18 +295,16 @@ static int alua_check_tpgs(struct scsi_device
> *sdev, struct alua_dh_data *h)
> case TPGS_MODE_NONE:
> sdev_printk(KERN_INFO, sdev, "%s: not supported\n",
> ALUA_DH_NAME);
> - err = SCSI_DH_DEV_UNSUPP;
> break;
> default:
> sdev_printk(KERN_INFO, sdev,
> "%s: unsupported TPGS setting %d\n",
> - ALUA_DH_NAME, h->tpgs);
> - h->tpgs = TPGS_MODE_NONE;
> - err = SCSI_DH_DEV_UNSUPP;
> + ALUA_DH_NAME, tpgs);
> + tpgs = TPGS_MODE_NONE;
> break;
> }
>
> - return err;
> + return tpgs;
> }
>
> /*
> @@ -627,10 +624,10 @@ static int alua_rtpg(struct scsi_device *sdev,
> struct alua_dh_data *h, int wait_
> */
> static int alua_initialize(struct scsi_device *sdev, struct
> alua_dh_data *h)
> {
> - int err;
> + int err = SCSI_DH_DEV_UNSUPP;
>
> - err = alua_check_tpgs(sdev, h);
> - if (err != SCSI_DH_OK)
> + h->tpgs = alua_check_tpgs(sdev);
> + if (h->tpgs == TPGS_MODE_NONE)
> goto out;
>
> err = alua_check_vpd(sdev, h);
Reviewed-by: Johannes Thumshirn
--
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 07/18] scsi_dh_alua: use standard logging functions
On Mon, 2015-11-09 at 16:08 +0100, Hannes Reinecke wrote:
> Use standard logging functions instead of hand-crafted ones.
>
> Reviewed-by: Bart Van Assche
> Signed-off-by: Hannes Reinecke
> ---
> drivers/scsi/device_handler/scsi_dh_alua.c | 27 +---
> ---
> 1 file changed, 13 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/scsi/device_handler/scsi_dh_alua.c
> b/drivers/scsi/device_handler/scsi_dh_alua.c
> index 240a5dc..b817963 100644
> --- a/drivers/scsi/device_handler/scsi_dh_alua.c
> +++ b/drivers/scsi/device_handler/scsi_dh_alua.c
> @@ -23,6 +23,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
>
> @@ -194,19 +195,14 @@ static void stpg_endio(struct request *req, int
> error)
>
> if (scsi_normalize_sense(h->sense, SCSI_SENSE_BUFFERSIZE,
> &sense_hdr)) {
> - if (!err) {
> - err = SCSI_DH_IO;
> - goto done;
> - }
> err = alua_check_sense(h->sdev, &sense_hdr);
> if (err == ADD_TO_MLQUEUE) {
> err = SCSI_DH_RETRY;
> goto done;
> }
> - sdev_printk(KERN_INFO, h->sdev,
> - "%s: stpg sense code: %02x/%02x/%02x\n",
> - ALUA_DH_NAME, sense_hdr.sense_key,
> - sense_hdr.asc, sense_hdr.ascq);
> + sdev_printk(KERN_INFO, h->sdev, "%s: stpg failed\n",
> + ALUA_DH_NAME);
> + scsi_print_sense_hdr(h->sdev, ALUA_DH_NAME,
> &sense_hdr);
> err = SCSI_DH_IO;
> } else if (error)
> err = SCSI_DH_IO;
> @@ -532,13 +528,16 @@ static int alua_rtpg(struct scsi_device *sdev,
> struct alua_dh_data *h, int wait_
> }
>
> err = alua_check_sense(sdev, &sense_hdr);
> - if (err == ADD_TO_MLQUEUE && time_before(jiffies,
> expiry))
> + if (err == ADD_TO_MLQUEUE && time_before(jiffies,
> expiry)) {
> + sdev_printk(KERN_ERR, sdev, "%s: rtpg
> retry\n",
> + ALUA_DH_NAME);
> + scsi_print_sense_hdr(sdev, ALUA_DH_NAME,
> &sense_hdr);
> goto retry;
> - sdev_printk(KERN_INFO, sdev,
> - "%s: rtpg sense code %02x/%02x/%02x\n",
> - ALUA_DH_NAME, sense_hdr.sense_key,
> - sense_hdr.asc, sense_hdr.ascq);
> - err = SCSI_DH_IO;
> + }
> + sdev_printk(KERN_ERR, sdev, "%s: rtpg failed\n",
> + ALUA_DH_NAME);
> + scsi_print_sense_hdr(sdev, ALUA_DH_NAME,
> &sense_hdr);
> + return SCSI_DH_IO;
> }
> if (err != SCSI_DH_OK)
> return err;
Reviewed-by: Johannes Thumshirn
--
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 06/18] scsi_dh_alua: sanitze sense code handling
On Mon, 2015-11-09 at 16:08 +0100, Hannes Reinecke wrote:
> The only check for a valid sense code is calling
> scsi_normalize_sense()
> and check the return value. So drop the pointless checks and rely on
> scsi_normalize_sense() to figure out if the sense code is valid.
> With that we can also remove the 'senselen' field.
>
> Reviewed-by: Bart van Assche
> Signed-off-by: Hannes Reinecke
> ---
> drivers/scsi/device_handler/scsi_dh_alua.c | 18 +++---
> 1 file changed, 7 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/scsi/device_handler/scsi_dh_alua.c
> b/drivers/scsi/device_handler/scsi_dh_alua.c
> index c63f304..240a5dc 100644
> --- a/drivers/scsi/device_handler/scsi_dh_alua.c
> +++ b/drivers/scsi/device_handler/scsi_dh_alua.c
> @@ -73,7 +73,6 @@ struct alua_dh_data {
> int bufflen;
> unsigned char transition_tmo;
> unsigned char sense[SCSI_SENSE_BUFFERSIZE];
> - int senselen;
> struct scsi_device *sdev;
> activate_complete callback_fn;
> void*callback_data;
> @@ -158,14 +157,13 @@ static unsigned submit_rtpg(struct scsi_device
> *sdev, struct alua_dh_data *h,
>
> rq->sense = h->sense;
> memset(rq->sense, 0, SCSI_SENSE_BUFFERSIZE);
> - rq->sense_len = h->senselen = 0;
> + rq->sense_len = 0;
>
> err = blk_execute_rq(rq->q, NULL, rq, 1);
> if (err == -EIO) {
> sdev_printk(KERN_INFO, sdev,
> "%s: rtpg failed with %x\n",
> ALUA_DH_NAME, rq->errors);
> - h->senselen = rq->sense_len;
> err = SCSI_DH_IO;
> }
> blk_put_request(rq);
> @@ -194,9 +192,8 @@ static void stpg_endio(struct request *req, int
> error)
> goto done;
> }
>
> - if (req->sense_len > 0) {
> - err = scsi_normalize_sense(h->sense,
> SCSI_SENSE_BUFFERSIZE,
> - &sense_hdr);
> + if (scsi_normalize_sense(h->sense, SCSI_SENSE_BUFFERSIZE,
> + &sense_hdr)) {
> if (!err) {
> err = SCSI_DH_IO;
> goto done;
> @@ -265,7 +262,7 @@ static unsigned submit_stpg(struct alua_dh_data
> *h)
>
> rq->sense = h->sense;
> memset(rq->sense, 0, SCSI_SENSE_BUFFERSIZE);
> - rq->sense_len = h->senselen = 0;
> + rq->sense_len = 0;
> rq->end_io_data = h;
>
> blk_execute_rq_nowait(rq->q, NULL, rq, 1, stpg_endio);
> @@ -514,10 +511,9 @@ static int alua_rtpg(struct scsi_device *sdev,
> struct alua_dh_data *h, int wait_
> retry:
> err = submit_rtpg(sdev, h, rtpg_ext_hdr_req);
>
> - if (err == SCSI_DH_IO && h->senselen > 0) {
> - err = scsi_normalize_sense(h->sense,
> SCSI_SENSE_BUFFERSIZE,
> - &sense_hdr);
> - if (!err)
> + if (err == SCSI_DH_IO) {
> + if (!scsi_normalize_sense(h->sense,
> SCSI_SENSE_BUFFERSIZE,
> + &sense_hdr))
> return SCSI_DH_IO;
>
> /*
Reviewed-by: Johannes Thumshirn
--
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 05/18] scsi_dh_alua: improved logging
On Mon, 2015-11-09 at 16:08 +0100, Hannes Reinecke wrote: > Issue different logging messages if ALUA is not supported > or the TPGS setting is invalid. > > Reviewed-by: Martin K. Petersen > Reviewed-by: Christoph Hellwig > Signed-off-by: Hannes Reinecke > --- > drivers/scsi/device_handler/scsi_dh_alua.c | 10 -- > 1 file changed, 8 insertions(+), 2 deletions(-) > > diff --git a/drivers/scsi/device_handler/scsi_dh_alua.c > b/drivers/scsi/device_handler/scsi_dh_alua.c > index 9b3b2f7..c63f304 100644 > --- a/drivers/scsi/device_handler/scsi_dh_alua.c > +++ b/drivers/scsi/device_handler/scsi_dh_alua.c > @@ -310,12 +310,18 @@ static int alua_check_tpgs(struct scsi_device > *sdev, struct alua_dh_data *h) > sdev_printk(KERN_INFO, sdev, "%s: supports implicit > TPGS\n", > ALUA_DH_NAME); > break; > - default: > - h->tpgs = TPGS_MODE_NONE; > + case TPGS_MODE_NONE: > sdev_printk(KERN_INFO, sdev, "%s: not supported\n", > ALUA_DH_NAME); > err = SCSI_DH_DEV_UNSUPP; > break; > + default: > + sdev_printk(KERN_INFO, sdev, > + "%s: unsupported TPGS setting %d\n", > + ALUA_DH_NAME, h->tpgs); > + h->tpgs = TPGS_MODE_NONE; > + err = SCSI_DH_DEV_UNSUPP; > + break; > } > > return err; Reviewed-by: Johannes Thumshirn -- 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 04/18] scsi_dh_alua: Use vpd_pg83 information
On Mon, 2015-11-09 at 16:08 +0100, Hannes Reinecke wrote:
> The SCSI device now has the VPD page 0x83 information attached,
> so there is no need to query it again.
>
> Reviewed-by: Martin K. Petersen
> Reviewed-by: Christoph Hellwig
> Signed-off-by: Hannes Reinecke
> ---
> drivers/scsi/device_handler/scsi_dh_alua.c | 87 +++-
> --
> 1 file changed, 18 insertions(+), 69 deletions(-)
>
> diff --git a/drivers/scsi/device_handler/scsi_dh_alua.c
> b/drivers/scsi/device_handler/scsi_dh_alua.c
> index 7d01ef0..9b3b2f7 100644
> --- a/drivers/scsi/device_handler/scsi_dh_alua.c
> +++ b/drivers/scsi/device_handler/scsi_dh_alua.c
> @@ -131,43 +131,6 @@ static struct request *get_alua_req(struct
> scsi_device *sdev,
> }
>
> /*
> - * submit_vpd_inquiry - Issue an INQUIRY VPD page 0x83 command
> - * @sdev: sdev the command should be sent to
> - */
> -static int submit_vpd_inquiry(struct scsi_device *sdev, struct
> alua_dh_data *h)
> -{
> - struct request *rq;
> - int err = SCSI_DH_RES_TEMP_UNAVAIL;
> -
> - rq = get_alua_req(sdev, h->buff, h->bufflen, READ);
> - if (!rq)
> - goto done;
> -
> - /* Prepare the command. */
> - rq->cmd[0] = INQUIRY;
> - rq->cmd[1] = 1;
> - rq->cmd[2] = 0x83;
> - rq->cmd[4] = h->bufflen;
> - rq->cmd_len = COMMAND_SIZE(INQUIRY);
> -
> - rq->sense = h->sense;
> - memset(rq->sense, 0, SCSI_SENSE_BUFFERSIZE);
> - rq->sense_len = h->senselen = 0;
> -
> - err = blk_execute_rq(rq->q, NULL, rq, 1);
> - if (err == -EIO) {
> - sdev_printk(KERN_INFO, sdev,
> - "%s: evpd inquiry failed with %x\n",
> - ALUA_DH_NAME, rq->errors);
> - h->senselen = rq->sense_len;
> - err = SCSI_DH_IO;
> - }
> - blk_put_request(rq);
> -done:
> - return err;
> -}
> -
> -/*
> * submit_rtpg - Issue a REPORT TARGET GROUP STATES command
> * @sdev: sdev the command should be sent to
> */
> @@ -359,43 +322,29 @@ static int alua_check_tpgs(struct scsi_device
> *sdev, struct alua_dh_data *h)
> }
>
> /*
> - * alua_vpd_inquiry - Evaluate INQUIRY vpd page 0x83
> + * alua_check_vpd - Evaluate INQUIRY vpd page 0x83
> * @sdev: device to be checked
> *
> * Extract the relative target port and the target port group
> * descriptor from the list of identificators.
> */
> -static int alua_vpd_inquiry(struct scsi_device *sdev, struct
> alua_dh_data *h)
> +static int alua_check_vpd(struct scsi_device *sdev, struct
> alua_dh_data *h)
> {
> - int len;
> - unsigned err;
> unsigned char *d;
> + unsigned char __rcu *vpd_pg83;
>
> - retry:
> - err = submit_vpd_inquiry(sdev, h);
> -
> - if (err != SCSI_DH_OK)
> - return err;
> -
> - /* Check if vpd page exceeds initial buffer */
> - len = (h->buff[2] << 8) + h->buff[3] + 4;
> - if (len > h->bufflen) {
> - /* Resubmit with the correct length */
> - if (realloc_buffer(h, len)) {
> - sdev_printk(KERN_WARNING, sdev,
> - "%s: kmalloc buffer failed\n",
> - ALUA_DH_NAME);
> - /* Temporary failure, bypass */
> - return SCSI_DH_DEV_TEMP_BUSY;
> - }
> - goto retry;
> + rcu_read_lock();
> + if (!rcu_dereference(sdev->vpd_pg83)){
> + rcu_read_unlock();
> + return SCSI_DH_DEV_UNSUPP;
> }
>
> /*
> - * Now look for the correct descriptor.
> + * Look for the correct descriptor.
> */
> - d = h->buff + 4;
> - while (d < h->buff + len) {
> + vpd_pg83 = rcu_dereference(sdev->vpd_pg83);
> + d = vpd_pg83 + 4;
> + while (d < vpd_pg83 + sdev->vpd_pg83_len) {
> switch (d[1] & 0xf) {
> case 0x4:
> /* Relative target port */
> @@ -410,6 +359,7 @@ static int alua_vpd_inquiry(struct scsi_device
> *sdev, struct alua_dh_data *h)
> }
> d += d[3] + 4;
> }
> + rcu_read_unlock();
>
> if (h->group_id == -1) {
> /*
> @@ -422,14 +372,13 @@ static int alua_vpd_inquiry(struct scsi_device
> *sdev, struct alua_dh_data *h)
> ALUA_DH_NAME);
> h->state = TPGS_STATE_OPTIMIZED;
> h->tpgs = TPGS_MODE_NONE;
> - err = SCSI_DH_DEV_UNSUPP;
> - } else {
> - sdev_printk(KERN_INFO, sdev,
> - "%s: port group %02x rel port %02x\n",
> - ALUA_DH_NAME, h->group_id, h->rel_port);
> + return SCSI_DH_DEV_UNSUPP;
> }
> + sdev_printk(KERN_INFO, sdev,
> + "%s: port group %02x rel port %02x\n",
> + ALUA_DH_NAME, h->group_id, h->rel_port);
>
> - return err;
> + return 0;
> }
>
> static char print_alua_state(int state)
> @@ -692,7 +641,7 @@ static i
Re: [PATCH 03/18] scsi_dh_alua: Disable ALUA handling for non-disk devices
On Mon, 2015-11-09 at 16:08 +0100, Hannes Reinecke wrote:
> Non-disk devices might support ALUA, but the firmware
> implementation is untested and frequently broken.
> As we're don't actually need it disable ALUA support
> for non-disk device for now.
>
> Signed-off-by: Hannes Reinecke
> Reviewed-by: Bart Van Assche
> Reviewed-by: Christoph Hellwig
> Reviewed-by: Martin K. Petersen
> ---
> drivers/scsi/device_handler/scsi_dh_alua.c | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/drivers/scsi/device_handler/scsi_dh_alua.c
> b/drivers/scsi/device_handler/scsi_dh_alua.c
> index cc2773b..7d01ef0 100644
> --- a/drivers/scsi/device_handler/scsi_dh_alua.c
> +++ b/drivers/scsi/device_handler/scsi_dh_alua.c
> @@ -320,6 +320,18 @@ static int alua_check_tpgs(struct scsi_device
> *sdev, struct alua_dh_data *h)
> {
> int err = SCSI_DH_OK;
>
> + /*
> + * ALUA support for non-disk devices is fraught with
> + * difficulties, so disable it for now.
> + */
> + if (sdev->type != TYPE_DISK) {
> + h->tpgs = TPGS_MODE_NONE;
> + sdev_printk(KERN_INFO, sdev,
> + "%s: disable for non-disk devices\n",
> + ALUA_DH_NAME);
> + return SCSI_DH_DEV_UNSUPP;
> + }
> +
> h->tpgs = scsi_device_tpgs(sdev);
> switch (h->tpgs) {
> case TPGS_MODE_EXPLICIT|TPGS_MODE_IMPLICIT:
Reviewed-by: Johannes Thumshirn
--
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/18] scsi_dh: move 'dh_state' sysfs attribute to generic code
On Mon, 2015-11-09 at 16:08 +0100, Hannes Reinecke wrote:
> As scsi_dh.c is now always compiled in we should be moving
> the 'dh_state' attribute to the generic code.
>
> Reviewed-by: Christoph Hellwig
> Signed-off-by: Hannes Reinecke
> ---
> drivers/scsi/scsi_dh.c| 68 +--
>
> drivers/scsi/scsi_sysfs.c | 58
>
> 2 files changed, 59 insertions(+), 67 deletions(-)
>
> diff --git a/drivers/scsi/scsi_dh.c b/drivers/scsi/scsi_dh.c
> index 0a2168e..57ad0f3 100644
> --- a/drivers/scsi/scsi_dh.c
> +++ b/drivers/scsi/scsi_dh.c
> @@ -153,76 +153,11 @@ static void scsi_dh_handler_detach(struct
> scsi_device *sdev)
> module_put(sdev->handler->module);
> }
>
> -/*
> - * Functions for sysfs attribute 'dh_state'
> - */
> -static ssize_t
> -store_dh_state(struct device *dev, struct device_attribute *attr,
> - const char *buf, size_t count)
> -{
> - struct scsi_device *sdev = to_scsi_device(dev);
> - struct scsi_device_handler *scsi_dh;
> - int err = -EINVAL;
> -
> - if (sdev->sdev_state == SDEV_CANCEL ||
> - sdev->sdev_state == SDEV_DEL)
> - return -ENODEV;
> -
> - if (!sdev->handler) {
> - /*
> - * Attach to a device handler
> - */
> - scsi_dh = scsi_dh_lookup(buf);
> - if (!scsi_dh)
> - return err;
> - err = scsi_dh_handler_attach(sdev, scsi_dh);
> - } else {
> - if (!strncmp(buf, "detach", 6)) {
> - /*
> - * Detach from a device handler
> - */
> - sdev_printk(KERN_WARNING, sdev,
> - "can't detach handler %s.\n",
> - sdev->handler->name);
> - err = -EINVAL;
> - } else if (!strncmp(buf, "activate", 8)) {
> - /*
> - * Activate a device handler
> - */
> - if (sdev->handler->activate)
> - err = sdev->handler->activate(sdev,
> NULL, NULL);
> - else
> - err = 0;
> - }
> - }
> -
> - return err<0?err:count;
> -}
> -
> -static ssize_t
> -show_dh_state(struct device *dev, struct device_attribute *attr,
> char *buf)
> -{
> - struct scsi_device *sdev = to_scsi_device(dev);
> -
> - if (!sdev->handler)
> - return snprintf(buf, 20, "detached\n");
> -
> - return snprintf(buf, 20, "%s\n", sdev->handler->name);
> -}
> -
> -static struct device_attribute scsi_dh_state_attr =
> - __ATTR(dh_state, S_IRUGO | S_IWUSR, show_dh_state,
> - store_dh_state);
> -
> int scsi_dh_add_device(struct scsi_device *sdev)
> {
> struct scsi_device_handler *devinfo = NULL;
> const char *drv;
> - int err;
> -
> - err = device_create_file(&sdev->sdev_gendev,
> &scsi_dh_state_attr);
> - if (err)
> - return err;
> + int err = 0;
>
> drv = scsi_dh_find_driver(sdev);
> if (drv)
> @@ -236,7 +171,6 @@ void scsi_dh_remove_device(struct scsi_device
> *sdev)
> {
> if (sdev->handler)
> scsi_dh_handler_detach(sdev);
> - device_remove_file(&sdev->sdev_gendev, &scsi_dh_state_attr);
> }
>
> /*
> diff --git a/drivers/scsi/scsi_sysfs.c b/drivers/scsi/scsi_sysfs.c
> index f021423..13a5ede 100644
> --- a/drivers/scsi/scsi_sysfs.c
> +++ b/drivers/scsi/scsi_sysfs.c
> @@ -17,6 +17,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
>
> @@ -902,6 +903,60 @@ sdev_show_function(queue_depth, "%d\n");
> static DEVICE_ATTR(queue_depth, S_IRUGO | S_IWUSR,
> sdev_show_queue_depth,
> sdev_store_queue_depth);
>
> +#ifdef CONFIG_SCSI_DH
> +static ssize_t
> +sdev_show_dh_state(struct device *dev, struct device_attribute
> *attr,
> + char *buf)
> +{
> + struct scsi_device *sdev = to_scsi_device(dev);
> +
> + if (!sdev->handler)
> + return snprintf(buf, 20, "detached\n");
> +
> + return snprintf(buf, 20, "%s\n", sdev->handler->name);
> +}
> +
> +static ssize_t
> +sdev_store_dh_state(struct device *dev, struct device_attribute
> *attr,
> + const char *buf, size_t count)
> +{
> + struct scsi_device *sdev = to_scsi_device(dev);
> + int err = -EINVAL;
> +
> + if (sdev->sdev_state == SDEV_CANCEL ||
> + sdev->sdev_state == SDEV_DEL)
> + return -ENODEV;
> +
> + if (!sdev->handler) {
> + /*
> + * Attach to a device handler
> + */
> + err = scsi_dh_attach(sdev->request_queue, buf);
> + } else if (!strncmp(buf, "activate", 8)) {
> + /*
> + * Activate a device handler
> + */
> + if (sdev->handler->activate)
> +
Re: [PATCH 02/18] scsi: ignore errors from scsi_dh_add_device()
On Mon, 2015-11-09 at 16:08 +0100, Hannes Reinecke wrote:
> device handler initialisation might fail due to a number of
> reasons. But as device_handlers are optional this shouldn't
> cause us to disable the device entirely.
> So just ignore errors from scsi_dh_add_device().
>
> Signed-off-by: Hannes Reinecke
> ---
> drivers/scsi/scsi_sysfs.c | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/scsi/scsi_sysfs.c b/drivers/scsi/scsi_sysfs.c
> index 13a5ede..7b41b2c 100644
> --- a/drivers/scsi/scsi_sysfs.c
> +++ b/drivers/scsi/scsi_sysfs.c
> @@ -1118,11 +1118,12 @@ int scsi_sysfs_add_sdev(struct scsi_device
> *sdev)
> }
>
> error = scsi_dh_add_device(sdev);
> - if (error) {
> + if (error)
> + /*
> + * device_handler is optional, so any error can be
> ignored
> + */
> sdev_printk(KERN_INFO, sdev,
> "failed to add device handler:
> %d\n", error);
> - return error;
> - }
>
> device_enable_async_suspend(&sdev->sdev_dev);
> error = device_add(&sdev->sdev_dev);
Reviewed-by: Johannes Thumshirn
--
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/71] More fixes, cleanup and modernization for NCR5380 drivers
On Tuesday 24 November 2015, Finn Thain wrote:
>
> On Tue, 24 Nov 2015, Ondrej Zary wrote:
>
> > On Tuesday 24 November 2015, Finn Thain wrote:
> > >
> > > On Mon, 23 Nov 2015, Ondrej Zary wrote:
> > >
> > > >
> > > > PDMA seems to be broken in multiple ways. NCR5380_pread cannot
> > > > process less than 128 bytes. In fact, 53C400 datasheet says that
> > > > it's HW limitation: non-modulo-128-byte transfers should use PIO.
> > > >
> > > > Adding
> > > > transfersize = round_down(transfersize, 128);
> > > > to generic_NCR5380_dma_xfer_len() improves the situation a bit.
> > > >
> > > > After modprobe, some small reads (8, 4, 24 and 64 bytes) are done
> > > > using PIO, then eight 512-byte reads using PDMA and then it fails on
> > > > a 254-byte read. First 128 bytes are read using PDMA and the next
> > > > PDMA operation hangs waiting forever for the host buffer to be
> > > > ready.
> > > >
> > >
> > > A 128-byte PDMA receive followed by 126-byte PDMA receive? I don't see
> > > how that is possible given round_down(126, 128) == 0. Was this the
> > > actual 'len' argument to NCR5380_pread() in g_NCR5380.c?
> >
> > No 126-byte PDMA. The 126 bytes were probably lost (or mixed with the
> > next read?).
>
> When you said, the "PDMA operation hangs waiting forever", I figured that
> you had hit an infinite loop in NCR5380_pread()... but now I'm lost.
The first 128-byte PDMA ended successfully (ignoring what happened to the
remaining 126 bytes), then a next request for 254 bytes came. This resulted
in a new 128-byte PDMA and that hanged (in one of its possibly infinite loops
without a timeout).
> My main concern here is to confirm that I didn't break anything e.g. with
> patch 24 or 41. It would be nice to know that this hang is not the result
> of a new bug.
PDMA was already broken before so it's hard to tell. I can try to modify
the unpatched driver to see if PDMA is broken the same way.
> > The next read was also 254 bytes so another 128-byte PDMA transfer.
> >
> > Then modified NCR5380_information_transfer() to transfer the remaining
> > data (126 bytes in this case) using PIO. It did not help, the next PDMA
> > transfer failed too.
> >
>
> AFAICT, no change to NCR5380_information_transfer() should be needed. It
> was always meant to cope with the need to split a transfer between (P)DMA
> and PIO.
>
> If the target is expecting the remaining 126 bytes, it will keep the bus
> in DATA OUT phase, and the next iteration of the loop
> while ((cmd = hostdata->connected)) { }
> will call NCR5380_transfer_pio() for the remaining bytes. If the target
> never asserts REQ, that transfer will never happen, but then the command
> should timeout and get aborted, to handle the possibility that a "PDMA
> operation hangs waiting forever".
Thanks for explanation.
> A protocol analyzer would be useful to debug this. I get a lot of value
> from a bus terminator block that has LEDs for the various control signals.
> Failing that, you might need to place,
> #define NDEBUG (NDEBUG_INFORMATION | NDEBUG_HANDSHAKE | NDEBUG_PIO |
> NDEBUG_DMA | NDEBUG_MAIN)
> at the top of g_NCR5380.c.
--
Ondrej Zary
--
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/2] arcmsr: adds code for support areca new adapter ARC1203
On Tue, 2015-11-24 at 02:24 -0800, Joe Perches wrote:
> On Tue, 2015-11-24 at 17:53 +0800, Ching Huang wrote:
> > On Tue, 2015-11-24 at 01:33 -0800, Joe Perches wrote:
> > > On Tue, 2015-11-24 at 16:17 +0800, Ching Huang wrote:
> > > > From: Ching Huang
> > > >
> > > > Support areca new PCIe to SATA RAID adapter ARC1203
> > >
> > > Why add the dma_free_coherent to an old data path?
> > > Is that a general bug fix that should be backported?
> >
> > That's right. It's need to release the allocated resource for failed
> > condition.
>
> Then the dma_free_coherent addition should be a separate patch.
>
> Style trivia:
>
> The goto to another error path like that is odd and
> the label is unintelligible.
>
> Ideally error condition handling would use a goto and
> a separate and obviously named label. Use multiple
> labels for cases with more complicated unwinding.
>
> Dan Carpenter has written about this several times.
>
> For this use, something like:
>
> writel(ARCMSR_MESSAGE_START_DRIVER_MODE, reg->drv2iop_doorbell);
> if (!arcmsr_hbaB_wait_msgint_ready(acb)) {
> logging_message(...);
> goto
> err_free_resource;
> }
> writel(ARCMSR_MESSAGE_GET_CONFIG, reg->drv2iop_doorbell);
> if (!arcmsr_hbaB_wait_msgint_ready(acb)) {
> logging_message(...);
> goto err_free_resource;
> }
>
> [success path...]
>
> return true;
>
> err_free_resource:
> dma_free_coherent(...);
>
> return false;
> }
>
Thanks for Joe's advice.
Revised as below.
Signed-of-by: Ching Huang
---
diff -uprN a/drivers/scsi/arcmsr/arcmsr.h b/drivers/scsi/arcmsr/arcmsr.h
--- a/drivers/scsi/arcmsr/arcmsr.h 2015-11-24 11:36:20.0 +0800
+++ b/drivers/scsi/arcmsr/arcmsr.h 2015-10-19 15:57:08.0 +0800
@@ -74,6 +74,9 @@ struct device_attribute;
#ifndef PCI_DEVICE_ID_ARECA_1214
#define PCI_DEVICE_ID_ARECA_12140x1214
#endif
+#ifndef PCI_DEVICE_ID_ARECA_1203
+ #define PCI_DEVICE_ID_ARECA_12030x1203
+#endif
/*
**
**
@@ -245,6 +248,12 @@ struct FIRMWARE_INFO
/* window of "instruction flags" from iop to driver */
#define ARCMSR_IOP2DRV_DOORBELL 0x00020408
#define ARCMSR_IOP2DRV_DOORBELL_MASK 0x0002040C
+/* window of "instruction flags" from iop to driver */
+#define ARCMSR_IOP2DRV_DOORBELL_1203 0x00021870
+#define ARCMSR_IOP2DRV_DOORBELL_MASK_1203 0x00021874
+/* window of "instruction flags" from driver to iop */
+#define ARCMSR_DRV2IOP_DOORBELL_1203 0x00021878
+#define ARCMSR_DRV2IOP_DOORBELL_MASK_1203 0x0002187C
/* ARECA FLAG LANGUAGE */
/* ioctl transfer */
#define ARCMSR_IOP2DRV_DATA_WRITE_OK 0x0001
diff -uprN a/drivers/scsi/arcmsr/arcmsr_hba.c
b/drivers/scsi/arcmsr/arcmsr_hba.c
--- a/drivers/scsi/arcmsr/arcmsr_hba.c 2015-11-24 11:35:26.0
+0800
+++ b/drivers/scsi/arcmsr/arcmsr_hba.c 2015-11-24 18:58:40.640226000
+0800
@@ -114,6 +114,7 @@ static void arcmsr_hardware_reset(struct
static const char *arcmsr_info(struct Scsi_Host *);
static irqreturn_t arcmsr_interrupt(struct AdapterControlBlock *acb);
static void arcmsr_free_irq(struct pci_dev *, struct
AdapterControlBlock *);
+static void arcmsr_wait_firmware_ready(struct AdapterControlBlock
*acb);
static int arcmsr_adjust_disk_queue_depth(struct scsi_device *sdev, int
queue_depth)
{
if (queue_depth > ARCMSR_MAX_CMD_PERLUN)
@@ -157,6 +158,8 @@ static struct pci_device_id arcmsr_devic
.driver_data = ACB_ADAPTER_TYPE_B},
{PCI_DEVICE(PCI_VENDOR_ID_ARECA, PCI_DEVICE_ID_ARECA_1202),
.driver_data = ACB_ADAPTER_TYPE_B},
+ {PCI_DEVICE(PCI_VENDOR_ID_ARECA, PCI_DEVICE_ID_ARECA_1203),
+ .driver_data = ACB_ADAPTER_TYPE_B},
{PCI_DEVICE(PCI_VENDOR_ID_ARECA, PCI_DEVICE_ID_ARECA_1210),
.driver_data = ACB_ADAPTER_TYPE_A},
{PCI_DEVICE(PCI_VENDOR_ID_ARECA, PCI_DEVICE_ID_ARECA_1214),
@@ -2621,7 +2624,7 @@ static bool arcmsr_hbaA_get_config(struc
}
static bool arcmsr_hbaB_get_config(struct AdapterControlBlock *acb)
{
- struct MessageUnit_B *reg = acb->pmuB;
+ struct MessageUnit_B *reg;
struct pci_dev *pdev = acb->pdev;
void *dma_coherent;
dma_addr_t dma_coherent_handle;
@@ -2649,10 +2652,17 @@ static bool arcmsr_hbaB_get_config(struc
acb->dma_coherent2 = dma_coherent;
reg = (struct MessageUnit_B *)dma_coherent;
acb->pmuB = reg;
- reg->drv2iop_doorbell= (uint32_t __iomem *)((unsigned
long)acb->mem_base0 + ARCMSR_DRV2IOP_DOORBELL);
- reg->drv2iop_doorbell_mask = (uint32_t __iomem *)((unsigned
long)acb->mem_base0 + ARCMSR_DRV2IOP_DOORBELL_MASK);
- reg->iop2drv_doorbell = (uint32_t __iomem *)((unsigned
long)acb->mem_base0 + ARCMSR_IOP2DRV_DOORBELL);
-
Re: [PATCH 2/2] arcmsr: adds code for support areca new adapter ARC1203
On Tue, 2015-11-24 at 17:53 +0800, Ching Huang wrote:
> On Tue, 2015-11-24 at 01:33 -0800, Joe Perches wrote:
> > On Tue, 2015-11-24 at 16:17 +0800, Ching Huang wrote:
> > > From: Ching Huang
> > >
> > > Support areca new PCIe to SATA RAID adapter ARC1203
> >
> > Why add the dma_free_coherent to an old data path?
> > Is that a general bug fix that should be backported?
>
> That's right. It's need to release the allocated resource for failed
> condition.
Then the dma_free_coherent addition should be a separate patch.
Style trivia:
The goto to another error path like that is odd and
the label is unintelligible.
Ideally error condition handling would use a goto and
a separate and obviously named label. Use multiple
labels for cases with more complicated unwinding.
Dan Carpenter has written about this several times.
For this use, something like:
writel(ARCMSR_MESSAGE_START_DRIVER_MODE, reg->drv2iop_doorbell);
if (!arcmsr_hbaB_wait_msgint_ready(acb)) {
logging_message(...);
goto
err_free_resource;
}
writel(ARCMSR_MESSAGE_GET_CONFIG, reg->drv2iop_doorbell);
if (!arcmsr_hbaB_wait_msgint_ready(acb)) {
logging_message(...);
goto err_free_resource;
}
[success path...]
return true;
err_free_resource:
dma_free_coherent(...);
return false;
}
--
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/2] arcmsr: adds code for support areca new adapter ARC1203
On Tue, 2015-11-24 at 01:33 -0800, Joe Perches wrote:
> On Tue, 2015-11-24 at 16:17 +0800, Ching Huang wrote:
> > From: Ching Huang
> >
> > Support areca new PCIe to SATA RAID adapter ARC1203
>
> Why add the dma_free_coherent to an old data path?
> Is that a general bug fix that should be backported?
That's right. It's need to release the allocated resource for failed condition.
>
> btw: the printk above the dma_free_coherent use
> shouldn't use a \ line continuation.
> it adds undesired whitespace to the format.
>
> > diff -uprN a/drivers/scsi/arcmsr/arcmsr_hba.c
> > b/drivers/scsi/arcmsr/arcmsr_hba.c
> []
> > @@ -2660,10 +2670,19 @@ static bool arcmsr_hbaB_get_config(struc
> > iop_firm_version = (char __iomem *)(®->message_rwbuffer[17]);> >
> > /*firm_version,17,68-83*/
> > iop_device_map = (char __iomem *)(®->message_rwbuffer[21]);>>
> > /*firm_version,21,84-99*/
> >
> > + arcmsr_wait_firmware_ready(acb);
> > + writel(ARCMSR_MESSAGE_START_DRIVER_MODE, reg->drv2iop_doorbell);
> > + if (!arcmsr_hbaB_wait_msgint_ready(acb)) {
> > + printk(KERN_ERR "arcmsr%d: can't set driver mode.\n",
> > acb->host->host_no);
> > + goto gcfg1;
> > + }
> > writel(ARCMSR_MESSAGE_GET_CONFIG, reg->drv2iop_doorbell);
> > if (!arcmsr_hbaB_wait_msgint_ready(acb)) {
> > printk(KERN_NOTICE "arcmsr%d: wait 'get adapter firmware \
> > miscellaneous data' timeout \n", acb->host->host_no);
> > +gcfg1:
> > + dma_free_coherent(&acb->pdev->dev, acb->roundup_ccbsize,
> > + acb->dma_coherent2, acb->dma_coherent_handle2);
> > return false;
> > }
> > count = 8;
>
--
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 1/3] scsi: make some Additional Sense strings more grep'able
There's little point in breaking these strings over multiple lines.
Signed-off-by: Rasmus Villemoes
---
drivers/scsi/constants.c | 27 +--
1 file changed, 9 insertions(+), 18 deletions(-)
diff --git a/drivers/scsi/constants.c b/drivers/scsi/constants.c
index fa09d4be2b53..58d94e3c3713 100644
--- a/drivers/scsi/constants.c
+++ b/drivers/scsi/constants.c
@@ -346,11 +346,9 @@ static const struct error_info additional[] =
{0x0407, "Logical unit not ready, operation in progress"},
{0x0408, "Logical unit not ready, long write in progress"},
{0x0409, "Logical unit not ready, self-test in progress"},
- {0x040A, "Logical unit not accessible, asymmetric access state "
-"transition"},
+ {0x040A, "Logical unit not accessible, asymmetric access state
transition"},
{0x040B, "Logical unit not accessible, target port in standby state"},
- {0x040C, "Logical unit not accessible, target port in unavailable "
-"state"},
+ {0x040C, "Logical unit not accessible, target port in unavailable
state"},
{0x040D, "Logical unit not ready, structure check required"},
{0x040E, "Logical unit not ready, security session in progress"},
{0x0410, "Logical unit not ready, auxiliary memory not accessible"},
@@ -363,11 +361,9 @@ static const struct error_info additional[] =
{0x0417, "Logical unit not ready, calibration required"},
{0x0418, "Logical unit not ready, a door is open"},
{0x0419, "Logical unit not ready, operating in sequential mode"},
- {0x041A, "Logical unit not ready, start stop unit command in "
-"progress"},
+ {0x041A, "Logical unit not ready, start stop unit command in progress"},
{0x041B, "Logical unit not ready, sanitize in progress"},
- {0x041C, "Logical unit not ready, additional power use not yet "
-"granted"},
+ {0x041C, "Logical unit not ready, additional power use not yet
granted"},
{0x041D, "Logical unit not ready, configuration in progress"},
{0x041E, "Logical unit not ready, microcode activation required"},
{0x041F, "Logical unit not ready, microcode download required"},
@@ -559,8 +555,7 @@ static const struct error_info additional[] =
{0x2300, "Invalid token operation, cause not reportable"},
{0x2301, "Invalid token operation, unsupported token type"},
{0x2302, "Invalid token operation, remote token usage not supported"},
- {0x2303, "Invalid token operation, remote rod token creation not "
-"supported"},
+ {0x2303, "Invalid token operation, remote rod token creation not
supported"},
{0x2304, "Invalid token operation, token unknown"},
{0x2305, "Invalid token operation, token corrupt"},
{0x2306, "Invalid token operation, token revoked"},
@@ -641,8 +636,7 @@ static const struct error_info additional[] =
{0x2A0D, "Data encryption capabilities changed"},
{0x2A10, "Timestamp changed"},
{0x2A11, "Data encryption parameters changed by another i_t nexus"},
- {0x2A12, "Data encryption parameters changed by vendor specific "
-"event"},
+ {0x2A12, "Data encryption parameters changed by vendor specific event"},
{0x2A13, "Data encryption key instance counter has changed"},
{0x2A14, "SA creation capabilities data has changed"},
{0x2A15, "Medium removal prevention preempted"},
@@ -759,8 +753,7 @@ static const struct error_info additional[] =
{0x3B19, "Element enabled"},
{0x3B1A, "Data transfer device removed"},
{0x3B1B, "Data transfer device inserted"},
- {0x3B1C, "Too many logical objects on partition to support "
-"operation"},
+ {0x3B1C, "Too many logical objects on partition to support operation"},
{0x3D00, "Invalid bits in identify message"},
@@ -957,8 +950,7 @@ static const struct error_info additional[] =
{0x5D39, "Data channel impending failure throughput performance"},
{0x5D3A, "Data channel impending failure seek time performance"},
{0x5D3B, "Data channel impending failure spin-up retry count"},
- {0x5D3C, "Data channel impending failure drive calibration retry "
-"count"},
+ {0x5D3C, "Data channel impending failure drive calibration retry
count"},
{0x5D40, "Servo impending failure general hard drive failure"},
{0x5D41, "Servo impending failure drive error rate too high"},
{0x5D42, "Servo impending failure data error rate too high"},
@@ -1070,8 +1062,7 @@ static const struct error_info additional[] =
{0x6E00, "Command to logical unit failed"},
- {0x6F00, "Copy protection key exchange failure - authentication "
-"failure"},
+ {0x6F00, "Copy protection key exchange failure - authentication
failure"},
{0x6F01, "Copy protection key exchange failure - key not present"},
{0x6F02, "Copy protection
[PATCH v2 3/3] scsi: reduce CONFIG_SCSI_CONSTANTS=y impact by 8k
On 64 bit, struct error_info has 6 bytes of padding, which amounts to
over 4k of wasted space in the additional[] array. We could easily get
rid of that by instead using separate arrays for the codes and the
pointers. However, we can do even better than that and save an
additional 6 bytes per entry: In the table, just store the sizeof()
the corresponding string literal. The cumulative sum of these is then
the appropriate offset into additional_text, which is built from the
concatenation (with '\0's inbetween) of the strings.
$ scripts/bloat-o-meter /tmp/vmlinux vmlinux
add/remove: 0/0 grow/shrink: 1/1 up/down: 24/-8488 (-8464)
function old new delta
scsi_extd_sense_format 136 160 +24
additional 113122824 -8488
Signed-off-by: Rasmus Villemoes
---
drivers/scsi/constants.c | 26 +-
1 file changed, 21 insertions(+), 5 deletions(-)
diff --git a/drivers/scsi/constants.c b/drivers/scsi/constants.c
index 6e813eec4f8d..83458f7a2824 100644
--- a/drivers/scsi/constants.c
+++ b/drivers/scsi/constants.c
@@ -292,17 +292,30 @@ bool scsi_opcode_sa_name(int opcode, int service_action,
struct error_info {
unsigned short code12; /* 0x0302 looks better than 0x03,0x02 */
- const char * text;
+ unsigned short size;
};
+/*
+ * There are 700+ entries in this table. To save space, we don't store
+ * (code, pointer) pairs, which would make sizeof(struct
+ * error_info)==16 on 64 bits. Rather, the second element just stores
+ * the size (including \0) of the corresponding string, and we use the
+ * sum of these to get the appropriate offset into additional_text
+ * defined below. This approach saves 12 bytes per entry.
+ */
static const struct error_info additional[] =
{
-#define SENSE_CODE(c, s) {c, s},
+#define SENSE_CODE(c, s) {c, sizeof(s)},
#include "sense_codes.h"
#undef SENSE_CODE
- {0, NULL}
};
+static const char *additional_text =
+#define SENSE_CODE(c, s) s "\0"
+#include "sense_codes.h"
+#undef SENSE_CODE
+ ;
+
struct error_info2 {
unsigned char code1, code2_min, code2_max;
const char * str;
@@ -364,11 +377,14 @@ scsi_extd_sense_format(unsigned char asc, unsigned char
ascq, const char **fmt)
{
int i;
unsigned short code = ((asc << 8) | ascq);
+ unsigned offset = 0;
*fmt = NULL;
- for (i = 0; additional[i].text; i++)
+ for (i = 0; i < ARRAY_SIZE(additional); i++) {
if (additional[i].code12 == code)
- return additional[i].text;
+ return additional_text + offset;
+ offset += additional[i].size;
+ }
for (i = 0; additional2[i].fmt; i++) {
if (additional2[i].code1 == asc &&
ascq >= additional2[i].code2_min &&
--
2.6.1
--
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 0/3] scsi: reduce CONFIG_SCSI_CONSTANTS=y impact by 8k
This reduces the impact of choosing CONFIG_SCSI_CONSTANTS by about 8KB.
2dd951ecd511 ("scsi: Conditionally compile in constants.c") updated
the Kconfig help text from 12KB to 75KB. The 12K predated git so was
certainly outdated. But I'm not sure where the 75K comes from; using
size(1) on a defconfig (with/without this config option) vmlinux shows
a difference of about 47K, and 39K after these patches are applied. In
any case, I've left the Kconfig text alone, since I'm not sure I'm
counting the same way the 75K was computed (I'm fairly certain of the
8K delta, however).
Tested with a trivial module calling scsi_extd_sense_format with a few
random known codes and comparing the result to the expected value.
v2: prepend patch to unsplit a few string literals for greppability,
leave the NULL sentinel in the .c file in 2/3 (it's removed in 3/3
either way).
Rasmus Villemoes (3):
scsi: make some Additional Sense strings more grep'able
scsi: move Additional Sense Codes to separate file
scsi: reduce CONFIG_SCSI_CONSTANTS=y impact by 8k
drivers/scsi/constants.c | 859 ++---
drivers/scsi/sense_codes.h | 826 +++
2 files changed, 847 insertions(+), 838 deletions(-)
create mode 100644 drivers/scsi/sense_codes.h
--
2.6.1
--
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 2/3] scsi: move Additional Sense Codes to separate file
This is a purely mechanical move of the list of additional sense codes
to a separate file, in preparation for reducing the impact of choosing
CONFIG_SCSI_CONSTANTS=y by about 8k.
Signed-off-by: Rasmus Villemoes
---
drivers/scsi/constants.c | 830 +
drivers/scsi/sense_codes.h | 826
2 files changed, 829 insertions(+), 827 deletions(-)
create mode 100644 drivers/scsi/sense_codes.h
diff --git a/drivers/scsi/constants.c b/drivers/scsi/constants.c
index 58d94e3c3713..6e813eec4f8d 100644
--- a/drivers/scsi/constants.c
+++ b/drivers/scsi/constants.c
@@ -295,835 +295,11 @@ struct error_info {
const char * text;
};
-/*
- * The canonical list of T10 Additional Sense Codes is available at:
- * http://www.t10.org/lists/asc-num.txt [most recent: 20141221]
- */
-
static const struct error_info additional[] =
{
- {0x, "No additional sense information"},
- {0x0001, "Filemark detected"},
- {0x0002, "End-of-partition/medium detected"},
- {0x0003, "Setmark detected"},
- {0x0004, "Beginning-of-partition/medium detected"},
- {0x0005, "End-of-data detected"},
- {0x0006, "I/O process terminated"},
- {0x0007, "Programmable early warning detected"},
- {0x0011, "Audio play operation in progress"},
- {0x0012, "Audio play operation paused"},
- {0x0013, "Audio play operation successfully completed"},
- {0x0014, "Audio play operation stopped due to error"},
- {0x0015, "No current audio status to return"},
- {0x0016, "Operation in progress"},
- {0x0017, "Cleaning requested"},
- {0x0018, "Erase operation in progress"},
- {0x0019, "Locate operation in progress"},
- {0x001A, "Rewind operation in progress"},
- {0x001B, "Set capacity operation in progress"},
- {0x001C, "Verify operation in progress"},
- {0x001D, "ATA pass through information available"},
- {0x001E, "Conflicting SA creation request"},
- {0x001F, "Logical unit transitioning to another power condition"},
- {0x0020, "Extended copy information available"},
- {0x0021, "Atomic command aborted due to ACA"},
-
- {0x0100, "No index/sector signal"},
-
- {0x0200, "No seek complete"},
-
- {0x0300, "Peripheral device write fault"},
- {0x0301, "No write current"},
- {0x0302, "Excessive write errors"},
-
- {0x0400, "Logical unit not ready, cause not reportable"},
- {0x0401, "Logical unit is in process of becoming ready"},
- {0x0402, "Logical unit not ready, initializing command required"},
- {0x0403, "Logical unit not ready, manual intervention required"},
- {0x0404, "Logical unit not ready, format in progress"},
- {0x0405, "Logical unit not ready, rebuild in progress"},
- {0x0406, "Logical unit not ready, recalculation in progress"},
- {0x0407, "Logical unit not ready, operation in progress"},
- {0x0408, "Logical unit not ready, long write in progress"},
- {0x0409, "Logical unit not ready, self-test in progress"},
- {0x040A, "Logical unit not accessible, asymmetric access state
transition"},
- {0x040B, "Logical unit not accessible, target port in standby state"},
- {0x040C, "Logical unit not accessible, target port in unavailable
state"},
- {0x040D, "Logical unit not ready, structure check required"},
- {0x040E, "Logical unit not ready, security session in progress"},
- {0x0410, "Logical unit not ready, auxiliary memory not accessible"},
- {0x0411, "Logical unit not ready, notify (enable spinup) required"},
- {0x0412, "Logical unit not ready, offline"},
- {0x0413, "Logical unit not ready, SA creation in progress"},
- {0x0414, "Logical unit not ready, space allocation in progress"},
- {0x0415, "Logical unit not ready, robotics disabled"},
- {0x0416, "Logical unit not ready, configuration required"},
- {0x0417, "Logical unit not ready, calibration required"},
- {0x0418, "Logical unit not ready, a door is open"},
- {0x0419, "Logical unit not ready, operating in sequential mode"},
- {0x041A, "Logical unit not ready, start stop unit command in progress"},
- {0x041B, "Logical unit not ready, sanitize in progress"},
- {0x041C, "Logical unit not ready, additional power use not yet
granted"},
- {0x041D, "Logical unit not ready, configuration in progress"},
- {0x041E, "Logical unit not ready, microcode activation required"},
- {0x041F, "Logical unit not ready, microcode download required"},
- {0x0420, "Logical unit not ready, logical unit reset required"},
- {0x0421, "Logical unit not ready, hard reset required"},
- {0x0422, "Logical unit not ready, power cycle required"},
-
- {0x0500, "Logical unit does not respond to selection"},
-
- {0x0600, "No reference position found"},
-
- {0x0700, "M
Re: [PATCH 2/2] arcmsr: adds code for support areca new adapter ARC1203
On Tue, 2015-11-24 at 16:17 +0800, Ching Huang wrote:
> From: Ching Huang
>
> Support areca new PCIe to SATA RAID adapter ARC1203
Why add the dma_free_coherent to an old data path?
Is that a general bug fix that should be backported?
btw: the printk above the dma_free_coherent use
shouldn't use a \ line continuation.
it adds undesired whitespace to the format.
> diff -uprN a/drivers/scsi/arcmsr/arcmsr_hba.c
> b/drivers/scsi/arcmsr/arcmsr_hba.c
[]
> @@ -2660,10 +2670,19 @@ static bool arcmsr_hbaB_get_config(struc
> iop_firm_version = (char __iomem *)(®->message_rwbuffer[17]);> >
> /*firm_version,17,68-83*/
> iop_device_map = (char __iomem *)(®->message_rwbuffer[21]);>>
> /*firm_version,21,84-99*/
>
> + arcmsr_wait_firmware_ready(acb);
> + writel(ARCMSR_MESSAGE_START_DRIVER_MODE, reg->drv2iop_doorbell);
> + if (!arcmsr_hbaB_wait_msgint_ready(acb)) {
> + printk(KERN_ERR "arcmsr%d: can't set driver mode.\n",
> acb->host->host_no);
> + goto gcfg1;
> + }
> writel(ARCMSR_MESSAGE_GET_CONFIG, reg->drv2iop_doorbell);
> if (!arcmsr_hbaB_wait_msgint_ready(acb)) {
> printk(KERN_NOTICE "arcmsr%d: wait 'get adapter firmware \
> miscellaneous data' timeout \n", acb->host->host_no);
> +gcfg1:
> + dma_free_coherent(&acb->pdev->dev, acb->roundup_ccbsize,
> + acb->dma_coherent2, acb->dma_coherent_handle2);
> return false;
> }
> count = 8;
--
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/71] More fixes, cleanup and modernization for NCR5380 drivers
On Tue, 24 Nov 2015, Ondrej Zary wrote:
> On Tuesday 24 November 2015, Finn Thain wrote:
> >
> > On Mon, 23 Nov 2015, Ondrej Zary wrote:
> >
> > >
> > > PDMA seems to be broken in multiple ways. NCR5380_pread cannot
> > > process less than 128 bytes. In fact, 53C400 datasheet says that
> > > it's HW limitation: non-modulo-128-byte transfers should use PIO.
> > >
> > > Adding
> > > transfersize = round_down(transfersize, 128);
> > > to generic_NCR5380_dma_xfer_len() improves the situation a bit.
> > >
> > > After modprobe, some small reads (8, 4, 24 and 64 bytes) are done
> > > using PIO, then eight 512-byte reads using PDMA and then it fails on
> > > a 254-byte read. First 128 bytes are read using PDMA and the next
> > > PDMA operation hangs waiting forever for the host buffer to be
> > > ready.
> > >
> >
> > A 128-byte PDMA receive followed by 126-byte PDMA receive? I don't see
> > how that is possible given round_down(126, 128) == 0. Was this the
> > actual 'len' argument to NCR5380_pread() in g_NCR5380.c?
>
> No 126-byte PDMA. The 126 bytes were probably lost (or mixed with the
> next read?).
When you said, the "PDMA operation hangs waiting forever", I figured that
you had hit an infinite loop in NCR5380_pread()... but now I'm lost.
My main concern here is to confirm that I didn't break anything e.g. with
patch 24 or 41. It would be nice to know that this hang is not the result
of a new bug.
> The next read was also 254 bytes so another 128-byte PDMA transfer.
>
> Then modified NCR5380_information_transfer() to transfer the remaining
> data (126 bytes in this case) using PIO. It did not help, the next PDMA
> transfer failed too.
>
AFAICT, no change to NCR5380_information_transfer() should be needed. It
was always meant to cope with the need to split a transfer between (P)DMA
and PIO.
If the target is expecting the remaining 126 bytes, it will keep the bus
in DATA OUT phase, and the next iteration of the loop
while ((cmd = hostdata->connected)) { }
will call NCR5380_transfer_pio() for the remaining bytes. If the target
never asserts REQ, that transfer will never happen, but then the command
should timeout and get aborted, to handle the possibility that a "PDMA
operation hangs waiting forever".
A protocol analyzer would be useful to debug this. I get a lot of value
from a bus terminator block that has LEDs for the various control signals.
Failing that, you might need to place,
#define NDEBUG (NDEBUG_INFORMATION | NDEBUG_HANDSHAKE | NDEBUG_PIO | NDEBUG_DMA
| NDEBUG_MAIN)
at the top of g_NCR5380.c.
--
--
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 2/2] arcmsr: adds code for support areca new adapter ARC1203
From: Ching Huang
Support areca new PCIe to SATA RAID adapter ARC1203
Signed-of-by: Ching Huang
---
diff -uprN a/drivers/scsi/arcmsr/arcmsr.h b/drivers/scsi/arcmsr/arcmsr.h
--- a/drivers/scsi/arcmsr/arcmsr.h 2015-11-24 11:36:20.0 +0800
+++ b/drivers/scsi/arcmsr/arcmsr.h 2015-10-19 15:57:08.0 +0800
@@ -74,6 +74,9 @@ struct device_attribute;
#ifndef PCI_DEVICE_ID_ARECA_1214
#define PCI_DEVICE_ID_ARECA_12140x1214
#endif
+#ifndef PCI_DEVICE_ID_ARECA_1203
+ #define PCI_DEVICE_ID_ARECA_12030x1203
+#endif
/*
**
**
@@ -245,6 +248,12 @@ struct FIRMWARE_INFO
/* window of "instruction flags" from iop to driver */
#define ARCMSR_IOP2DRV_DOORBELL 0x00020408
#define ARCMSR_IOP2DRV_DOORBELL_MASK 0x0002040C
+/* window of "instruction flags" from iop to driver */
+#define ARCMSR_IOP2DRV_DOORBELL_1203 0x00021870
+#define ARCMSR_IOP2DRV_DOORBELL_MASK_1203 0x00021874
+/* window of "instruction flags" from driver to iop */
+#define ARCMSR_DRV2IOP_DOORBELL_1203 0x00021878
+#define ARCMSR_DRV2IOP_DOORBELL_MASK_1203 0x0002187C
/* ARECA FLAG LANGUAGE */
/* ioctl transfer */
#define ARCMSR_IOP2DRV_DATA_WRITE_OK 0x0001
diff -uprN a/drivers/scsi/arcmsr/arcmsr_hba.c b/drivers/scsi/arcmsr/arcmsr_hba.c
--- a/drivers/scsi/arcmsr/arcmsr_hba.c 2015-11-24 11:35:26.0 +0800
+++ b/drivers/scsi/arcmsr/arcmsr_hba.c 2015-11-23 18:03:30.0 +0800
@@ -114,6 +114,7 @@ static void arcmsr_hardware_reset(struct
static const char *arcmsr_info(struct Scsi_Host *);
static irqreturn_t arcmsr_interrupt(struct AdapterControlBlock *acb);
static void arcmsr_free_irq(struct pci_dev *, struct AdapterControlBlock *);
+static void arcmsr_wait_firmware_ready(struct AdapterControlBlock *acb);
static int arcmsr_adjust_disk_queue_depth(struct scsi_device *sdev, int
queue_depth)
{
if (queue_depth > ARCMSR_MAX_CMD_PERLUN)
@@ -157,6 +158,8 @@ static struct pci_device_id arcmsr_devic
.driver_data = ACB_ADAPTER_TYPE_B},
{PCI_DEVICE(PCI_VENDOR_ID_ARECA, PCI_DEVICE_ID_ARECA_1202),
.driver_data = ACB_ADAPTER_TYPE_B},
+ {PCI_DEVICE(PCI_VENDOR_ID_ARECA, PCI_DEVICE_ID_ARECA_1203),
+ .driver_data = ACB_ADAPTER_TYPE_B},
{PCI_DEVICE(PCI_VENDOR_ID_ARECA, PCI_DEVICE_ID_ARECA_1210),
.driver_data = ACB_ADAPTER_TYPE_A},
{PCI_DEVICE(PCI_VENDOR_ID_ARECA, PCI_DEVICE_ID_ARECA_1214),
@@ -2621,7 +2624,7 @@ static bool arcmsr_hbaA_get_config(struc
}
static bool arcmsr_hbaB_get_config(struct AdapterControlBlock *acb)
{
- struct MessageUnit_B *reg = acb->pmuB;
+ struct MessageUnit_B *reg;
struct pci_dev *pdev = acb->pdev;
void *dma_coherent;
dma_addr_t dma_coherent_handle;
@@ -2649,10 +2652,17 @@ static bool arcmsr_hbaB_get_config(struc
acb->dma_coherent2 = dma_coherent;
reg = (struct MessageUnit_B *)dma_coherent;
acb->pmuB = reg;
- reg->drv2iop_doorbell= (uint32_t __iomem *)((unsigned
long)acb->mem_base0 + ARCMSR_DRV2IOP_DOORBELL);
- reg->drv2iop_doorbell_mask = (uint32_t __iomem *)((unsigned
long)acb->mem_base0 + ARCMSR_DRV2IOP_DOORBELL_MASK);
- reg->iop2drv_doorbell = (uint32_t __iomem *)((unsigned
long)acb->mem_base0 + ARCMSR_IOP2DRV_DOORBELL);
- reg->iop2drv_doorbell_mask = (uint32_t __iomem *)((unsigned
long)acb->mem_base0 + ARCMSR_IOP2DRV_DOORBELL_MASK);
+ if (acb->pdev->device == PCI_DEVICE_ID_ARECA_1203) {
+ reg->drv2iop_doorbell = (uint32_t __iomem *)((unsigned
long)acb->mem_base0 + ARCMSR_DRV2IOP_DOORBELL_1203);
+ reg->drv2iop_doorbell_mask = (uint32_t __iomem *)((unsigned
long)acb->mem_base0 + ARCMSR_DRV2IOP_DOORBELL_MASK_1203);
+ reg->iop2drv_doorbell = (uint32_t __iomem *)((unsigned
long)acb->mem_base0 + ARCMSR_IOP2DRV_DOORBELL_1203);
+ reg->iop2drv_doorbell_mask = (uint32_t __iomem *)((unsigned
long)acb->mem_base0 + ARCMSR_IOP2DRV_DOORBELL_MASK_1203);
+ } else {
+ reg->drv2iop_doorbell= (uint32_t __iomem *)((unsigned
long)acb->mem_base0 + ARCMSR_DRV2IOP_DOORBELL);
+ reg->drv2iop_doorbell_mask = (uint32_t __iomem *)((unsigned
long)acb->mem_base0 + ARCMSR_DRV2IOP_DOORBELL_MASK);
+ reg->iop2drv_doorbell = (uint32_t __iomem *)((unsigned
long)acb->mem_base0 + ARCMSR_IOP2DRV_DOORBELL);
+ reg->iop2drv_doorbell_mask = (uint32_t __iomem *)((unsigned
long)acb->mem_base0 + ARCMSR_IOP2DRV_DOORBELL_MASK);
+ }
reg->message_wbuffer = (uint32_t __iomem *)((unsigned
long)acb->mem_base1 + ARCMSR_MESSAGE_WBUFFER);
reg->message_rbuffer = (uint32_t __iomem *)((unsigned
long)acb->mem_base1 + ARCMSR_MESSAGE_RBUFFER);
reg->message_rwbuffer = (uint32_t __iomem *)((unsi
[PATCH 1/2] arcmsr: fixed getting wrong configuration data
From: Ching Huang
Fixed getting wrong configuration data of adapter type B and type D.
Signed-of-by: Ching Huang
---
diff -uprN a/drivers/scsi/arcmsr/arcmsr.h b/drivers/scsi/arcmsr/arcmsr.h
--- a/drivers/scsi/arcmsr/arcmsr.h 2015-11-23 16:25:48.0 +0800
+++ b/drivers/scsi/arcmsr/arcmsr.h 2015-11-24 11:36:20.0 +0800
@@ -52,7 +52,7 @@ struct device_attribute;
#define ARCMSR_MAX_FREECCB_NUM 320
#define ARCMSR_MAX_OUTSTANDING_CMD 255
#endif
-#define ARCMSR_DRIVER_VERSION "v1.30.00.04-20140919"
+#define ARCMSR_DRIVER_VERSION "v1.30.00.21-20151019"
#define ARCMSR_SCSI_INITIATOR_ID
255
#define ARCMSR_MAX_XFER_SECTORS
512
#define ARCMSR_MAX_XFER_SECTORS_B
4096
diff -uprN a/drivers/scsi/arcmsr/arcmsr_hba.c b/drivers/scsi/arcmsr/arcmsr_hba.c
--- a/drivers/scsi/arcmsr/arcmsr_hba.c 2015-11-23 16:25:22.0 +0800
+++ b/drivers/scsi/arcmsr/arcmsr_hba.c 2015-11-24 11:35:26.0 +0800
@@ -2694,15 +2694,15 @@ static bool arcmsr_hbaB_get_config(struc
acb->firm_model,
acb->firm_version);
- acb->signature = readl(®->message_rwbuffer[1]);
+ acb->signature = readl(®->message_rwbuffer[0]);
/*firm_signature,1,00-03*/
- acb->firm_request_len = readl(®->message_rwbuffer[2]);
+ acb->firm_request_len = readl(®->message_rwbuffer[1]);
/*firm_request_len,1,04-07*/
- acb->firm_numbers_queue = readl(®->message_rwbuffer[3]);
+ acb->firm_numbers_queue = readl(®->message_rwbuffer[2]);
/*firm_numbers_queue,2,08-11*/
- acb->firm_sdram_size = readl(®->message_rwbuffer[4]);
+ acb->firm_sdram_size = readl(®->message_rwbuffer[3]);
/*firm_sdram_size,3,12-15*/
- acb->firm_hd_channels = readl(®->message_rwbuffer[5]);
+ acb->firm_hd_channels = readl(®->message_rwbuffer[4]);
/*firm_ide_channels,4,16-19*/
acb->firm_cfg_version = readl(®->message_rwbuffer[25]);
/*firm_cfg_version,25,100-103*/
/*firm_ide_channels,4,16-19*/
@@ -2880,15 +2880,15 @@ static bool arcmsr_hbaD_get_config(struc
iop_device_map++;
count--;
}
- acb->signature = readl(®->msgcode_rwbuffer[1]);
+ acb->signature = readl(®->msgcode_rwbuffer[0]);
/*firm_signature,1,00-03*/
- acb->firm_request_len = readl(®->msgcode_rwbuffer[2]);
+ acb->firm_request_len = readl(®->msgcode_rwbuffer[1]);
/*firm_request_len,1,04-07*/
- acb->firm_numbers_queue = readl(®->msgcode_rwbuffer[3]);
+ acb->firm_numbers_queue = readl(®->msgcode_rwbuffer[2]);
/*firm_numbers_queue,2,08-11*/
- acb->firm_sdram_size = readl(®->msgcode_rwbuffer[4]);
+ acb->firm_sdram_size = readl(®->msgcode_rwbuffer[3]);
/*firm_sdram_size,3,12-15*/
- acb->firm_hd_channels = readl(®->msgcode_rwbuffer[5]);
+ acb->firm_hd_channels = readl(®->msgcode_rwbuffer[4]);
/*firm_hd_channels,4,16-19*/
acb->firm_cfg_version = readl(®->msgcode_rwbuffer[25]);
pr_notice("Areca RAID Controller%d: Model %s, F/W %s\n",
--
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/71] More fixes, cleanup and modernization for NCR5380 drivers
On Tuesday 24 November 2015, Finn Thain wrote: > > On Mon, 23 Nov 2015, Ondrej Zary wrote: > > > > > PDMA seems to be broken in multiple ways. NCR5380_pread cannot process > > less than 128 bytes. In fact, 53C400 datasheet says that it's HW > > limitation: non-modulo-128-byte transfers should use PIO. > > > > Adding > > transfersize = round_down(transfersize, 128); > > to generic_NCR5380_dma_xfer_len() improves the situation a bit. > > > > After modprobe, some small reads (8, 4, 24 and 64 bytes) are done using > > PIO, then eight 512-byte reads using PDMA and then it fails on a > > 254-byte read. First 128 bytes are read using PDMA and the next PDMA > > operation hangs waiting forever for the host buffer to be ready. > > > > A 128-byte PDMA receive followed by 126-byte PDMA receive? I don't see how > that is possible given round_down(126, 128) == 0. Was this the actual > 'len' argument to NCR5380_pread() in g_NCR5380.c? No 126-byte PDMA. The 126 bytes were probably lost (or mixed with the next read?). The next read was also 254 bytes so another 128-byte PDMA transfer. Then modified NCR5380_information_transfer() to transfer the remaining data (126 bytes in this case) using PIO. It did not help, the next PDMA transfer failed too. > BTW, I presume that FLAG_NO_DMA_FIXUPS was set (which is the case if you > pass ncr_53c400=1 option with modprobe). Otherwise you could see PDMA IO > sizes like 127 etc. Yes, the flag was set. -- Ondrej Zary -- 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/2] arcmsr: support areca new adapter ARC1203
From: Ching Huang Patch 1 fixes getting wrong configuration data. Pacth 2 adds codes to support new adapter ARC1203. -- -- 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
