-queuecommand returns '0' for successful command submission,
so we need to set the correct SCSI midlayer return value
when calling scsi_log_completion().
Reported-by: Robert Elliott elli...@hp.com
Cc: Stephen Cameron scame...@beardog.cce.hp.com
Signed-off-by: Hannes Reinecke h...@suse.de
---
On 04/29/2014 11:47 PM, Stewart, Sean wrote:
On Fri, 2014-01-31 at 10:30 +0100, Hannes Reinecke wrote:
@@ -797,37 +838,40 @@ static int alua_rtpg(struct scsi_device *sdev, struct
alua_port_group *pg)
off = 8 + (ucp[7] * 4);
}
- sdev_printk(KERN_INFO, sdev,
-
Il 08/05/2014 07:24, Ming Lei ha scritto:
Access to tgt-req_vq is strictly serialized by spin_lock
of tgt-tgt_lock, so the ACCESS_ONCE() isn't necessary.
smp_read_barrier_depends() in virtscsi_req_done was introduced
to order reading req_vq and decreasing tgt-reqs, but it isn't
needed now
On 05/01/2014 04:51 PM, Christoph Hellwig wrote:
By folding scsi_end_request into its only caller we can significantly clean
up the completion logic. We can use simple goto labels now to only have
a single place to finish or requeue command there instead of the previous
convoluted logic.
On 05/01/2014 04:51 PM, Christoph Hellwig wrote:
Instead of letting the ULD play games with the prep_fn move back to
the model of a central prep_fn with a callback to the ULD. This
already cleans up and shortens the code by itself, and will be required
to properly support blk-mq in the SCSI
On 05/01/2014 04:51 PM, Christoph Hellwig wrote:
Signed-off-by: Christoph Hellwig h...@lst.de
Reviewed-by: Nicholas Bellinger n...@linux-iscsi.org
Reviewed-by: Mike Christie micha...@cs.wisc.edu
Reviewed-by: Hannes Reinecke h...@suse.de
Cheers,
Hannes
--
Dr. Hannes Reinecke
On Thu, May 8, 2014 at 3:05 PM, Paolo Bonzini pbonz...@redhat.com wrote:
Decrements of reqs are never concurrent with writes of req_vq: before the
decrement reqs will be != 0; after the decrement the virtqueue completion
routine will not use the req_vq so it can be changed by a new request.
On Wed, 07 May 2014 18:43:45 +0200
Paolo Bonzini pbonz...@redhat.com wrote:
Per-CPU spinlocks have bad scalability problems, especially if you're
overcommitting. Writing req_vq is not at all rare.
OK, thought about it further, and I believe seqcount may
be a match for the case, could you
Hi Tomas,
Thanks for your suggestion.
I will add a new patch 17/17 at last.
---
diff -uprN a/drivers/scsi/arcmsr/arcmsr_hba.c b/drivers/scsi/arcmsr/arcmsr_hba.c
--- a/drivers/scsi/arcmsr/arcmsr_hba.c 2014-05-08 17:45:34.0 +0800
+++ b/drivers/scsi/arcmsr/arcmsr_hba.c 2014-05-08
Il 08/05/2014 12:44, Ming Lei ha scritto:
On Wed, 07 May 2014 18:43:45 +0200
Paolo Bonzini pbonz...@redhat.com wrote:
Per-CPU spinlocks have bad scalability problems, especially if you're
overcommitting. Writing req_vq is not at all rare.
OK, thought about it further, and I believe
On Thu, May 8, 2014 at 8:17 PM, Paolo Bonzini pbonz...@redhat.com wrote:
Il 08/05/2014 12:44, Ming Lei ha scritto:
On Wed, 07 May 2014 18:43:45 +0200
Paolo Bonzini pbonz...@redhat.com wrote:
Per-CPU spinlocks have bad scalability problems, especially if you're
overcommitting. Writing
Il 08/05/2014 14:55, Ming Lei ha scritto:
On Thu, May 8, 2014 at 8:17 PM, Paolo Bonzini pbonz...@redhat.com wrote:
Il 08/05/2014 12:44, Ming Lei ha scritto:
On Wed, 07 May 2014 18:43:45 +0200
Paolo Bonzini pbonz...@redhat.com wrote:
Per-CPU spinlocks have bad scalability problems,
On Thu, May 8, 2014 at 9:21 PM, Paolo Bonzini pbonz...@redhat.com wrote:
Il 08/05/2014 14:55, Ming Lei ha scritto:
On Thu, May 8, 2014 at 8:17 PM, Paolo Bonzini pbonz...@redhat.com wrote:
Il 08/05/2014 12:44, Ming Lei ha scritto:
On Wed, 07 May 2014 18:43:45 +0200
Paolo Bonzini
From: Joe Handzik joseph.t.hand...@hp.com
Signed-off-by: Scott Teel scott.t...@hp.com
Signed-off-by: Joe Handzik joseph.t.hand...@hp.com
Signed-off-by: Stephen M. Cameron scame...@beardog.cce.hp.com
Cc: sta...@vger.kernel.org
---
drivers/scsi/hpsa.c | 12
1 files changed, 12
From: root r...@rhel6u2e-s1.ldev.net
for controllers which support either of the ioaccel transport methods.
Signed-off-by: Stephen M. Cameron scame...@beardog.cce.hp.com
---
drivers/scsi/hpsa.c |7 +++
drivers/scsi/hpsa.h | 15 ++-
2 files changed, 21 insertions(+), 1
From: Stephen M. Cameron scame...@beardog.cce.hp.com
Avoid excessive locking by using per-cpu variable for lockup_detected
Signed-off-by: Stephen M. Cameron scame...@beardog.cce.hp.com
---
drivers/scsi/hpsa.c | 80 ++-
drivers/scsi/hpsa.h |2
From: Stephen M. Cameron scame...@beardog.cce.hp.com
Signed-off-by: Stephen M. Cameron scame...@beardog.cce.hp.com
---
drivers/scsi/hpsa.c | 21 -
drivers/scsi/hpsa_cmd.h | 12 +++-
2 files changed, 19 insertions(+), 14 deletions(-)
diff --git
From: Stephen M. Cameron scame...@beardog.cce.hp.com
Now that we can allocate more than 4 reply queues (up to 64)
we shouldn't try to make them share the same allocation but
should allocate them separately.
Signed-off-by: Stephen M. Cameron scame...@beardog.cce.hp.com
---
drivers/scsi/hpsa.c |
From: Stephen M. Cameron scame...@beardog.cce.hp.com
CTLR_STATE_CHANGE_EVENT and CTLR_STATE_CHANGE_EVENT_REDUNDANT_CNTRL
do not require rescans to be initiated. Current firmware filters out
these events already, but some out of date firmware doesn't, so the
driver needs to filter them out too.
From: Stephen M. Cameron scame...@beardog.cce.hp.com
There's nothing the user can or should do about these messages,
the commands are retried down the normal RAID path, and the
messages just flood the logs and sap performance.
Signed-off-by: Stephen M. Cameron scame...@beardog.cce.hp.com
---
From: Stephen M. Cameron scame...@beardog.cce.hp.com
Signed-off-by: Stephen M. Cameron scame...@beardog.cce.hp.com
---
drivers/scsi/hpsa.c | 17 -
1 files changed, 16 insertions(+), 1 deletions(-)
diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c
index 9c44f26..e8090e2
From: Stephen M. Cameron scame...@beardog.cce.hp.com
It shouldn't happen that we get a check condition with no sense data, but if it
does, we shouldn't just drop the check condition on the floor.
Signed-off-by: Stephen M. Cameron scame...@beardog.cce.hp.com
---
drivers/scsi/hpsa.c |7
Not a lot of extensive changes in this set, some new PCI IDs,
some small bug fixes, quieting some noisy messages, allowing
more reply queues, setting irq affinity hints, and some minor
locking improvments.
drivers/scsi/hpsa.c | 266 +--
From: Stephen M. Cameron scame...@beardog.cce.hp.com
They are not completely free of cost when disabled and
when enabled emitting debug output for every command
submitted produces far too much output to be useful.
Signed-off-by: Stephen M. Cameron scame...@beardog.cce.hp.com
---
From: Stephen M. Cameron scame...@beardog.cce.hp.com
Signed-off-by: Stephen M. Cameron scame...@beardog.cce.hp.com
---
drivers/scsi/hpsa.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c
index 8359884..9d4a0bd 100644
---
From: Stephen M. Cameron scame...@beardog.cce.hp.com
No sense having 8 or 16 reply queues if you only have 4 cpus,
and likewise no sense limiting to 8 reply queues if you have
many more cpus.
Signed-off-by: Stephen M. Cameron scame...@beardog.cce.hp.com
---
drivers/scsi/hpsa.c |2 ++
From: Stephen M. Cameron scame...@beardog.cce.hp.com
Treat the the data direction bits as a bit mask allowing both
READ and WRITE at the same time instead of testing for equality
to see if it's a exclusively a READ or a WRITE.
Signed-off-by: Stephen M. Cameron scame...@beardog.cce.hp.com
---
From: Stephen M. Cameron scame...@beardog.cce.hp.com
Signed-off-by: Stephen M. Cameron scame...@beardog.cce.hp.com
---
drivers/scsi/hpsa.c |3 ---
drivers/scsi/hpsa_cmd.h | 33 ++---
2 files changed, 6 insertions(+), 30 deletions(-)
diff --git
From: Stephen M. Cameron scame...@beardog.cce.hp.com
They are annoying and do not help anyone.
Signed-off-by: Stephen M. Cameron scame...@beardog.cce.hp.com
---
drivers/scsi/hpsa.c | 12 +++-
1 files changed, 3 insertions(+), 9 deletions(-)
diff --git a/drivers/scsi/hpsa.c
On Thu, 8 May 2014, Stephen M. Cameron wrote:
From: Stephen M. Cameron scame...@beardog.cce.hp.com
Signed-off-by: Stephen M. Cameron scame...@beardog.cce.hp.com
---
drivers/scsi/hpsa.c | 17 -
1 files changed, 16 insertions(+), 1 deletions(-)
diff --git
On 02/24/2014 09:06 PM, vikas.chaudh...@qlogic.com wrote:
From: Vikas Chaudhary vikas.chaudh...@qlogic.com
James,
Please apply the following patches to the scsi tree at your earliest
convenience.
Tej Parkash (5):
qla4xxx: Do not wait for IO completion, after issuing
-Original Message-
From: Govindarajulu Varadarajan [mailto:gvara...@cisco.com]
Sent: Thursday, 08 May, 2014 4:12 PM
To: Stephen M. Cameron
Cc: james.bottom...@hansenpartnership.com; Lindley, Justin;
martin.peter...@oracle.com; linux-scsi@vger.kernel.org;
stephenmcame...@gmail.com;
The direct cause is IRQ_SPI is already defined as a macro in unicore32
architecture (also, blackfin and mips architectures define it). The
related error (unicore32 with allmodconfig)
CC [M] drivers/scsi/mvsas/mv_94xx.o
In file included from drivers/scsi/mvsas/mv_94xx.c:27:
Oh, sorry, this patch is incorrect: IRQ_SAS_A and IRQ_SAS_B are used as
'u32' (although they are members of enum pci_interrupt_cause).
I will send patch v2 for it.
On 05/09/2014 07:45 AM, Chen Gang wrote:
The direct cause is IRQ_SPI is already defined as a macro in unicore32
architecture
The direct cause is IRQ_SPI is already defined as a macro in unicore32
architecture (also, blackfin and mips architectures define it). The
related error (unicore32 with allmodconfig)
CC [M] drivers/scsi/mvsas/mv_94xx.o
In file included from drivers/scsi/mvsas/mv_94xx.c:27:
35 matches
Mail list logo