Re: Sym2 scsi hang on boot on sparc64
Hi, On Tue, Aug 19, 2014 at 03:37:18PM -0500, James Bottomley wrote: > On Tue, 2014-08-19 at 23:17 +0300, Aaro Koskinen wrote: > > Bisection (on PA-RISC) points to: > > > > 71e75c97f97a9645d25fbf3d8e4165a558f18747 is the first bad commit > > commit 71e75c97f97a9645d25fbf3d8e4165a558f18747 > > Author: Christoph Hellwig > > Date: Fri Apr 11 19:07:01 2014 +0200 > > > > scsi: convert device_busy to atomic_t > > That's fixed upstream: > > commit 480cadc2b7e0fa2bbab20141efb547dfe0c3707c > Author: Guenter Roeck > Date: Sun Aug 10 05:54:25 2014 -0700 > > scsi: Fix qemu boot hang problem > > Could you try with a kernel that has that fix? Yes, the box boots now fine with the fix. Thanks, A. -- 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: Sym2 scsi hang on boot on sparc64
On Tue, 2014-08-19 at 23:17 +0300, Aaro Koskinen wrote: > Hi, > > On Tue, Aug 19, 2014 at 09:47:35AM -0500, James Bottomley wrote: > > On Tue, 2014-08-19 at 17:37 +0300, Meelis Roos wrote: > > > > On Tue, 2014-08-19 at 14:25 +0300, Meelis Roos wrote: > > > > > 3.16 scsi worked fine, 3.17-rc1 misbehaves on 3 of my sparc64 test > > > > > machines. E220R and E420R are with onboard 5c3875, V210 is with > > > > > onboarc > > > > > 53c1010 and all behave the same. Any ideas whre to dig deeper? > > > > > bisection > > > > > might be nontrivial, because of sparc64 changes that are OK on > > > > > 3.17-rc1 > > > > > again - but is possible if nothing else helps. > > > > > > > > We've got a parisc with an 875 as a root SCSI bus ... I haven't got > > > > around to building for it yet, but I might find time to try today. > > > > > > Same on parisc: > > > > > > sym0: <1010-66> rev 0x1 at pci :20:01.0 irq 22 > > > sym0: PA-RISC Firmware, ID 7, Fast-80, LVD, parity checking > > > sym0: SCSI BUS has been reset. > > > scsi host0: sym-2.2.3 > > > random: nonblocking pool is initialized > > > > > > and hangs here. So hopefully it is reproducible for you. > > > > And also independent of the sparc changes. The only other change in the > > window you quote is 64 bit luns. > > Bisection (on PA-RISC) points to: > > 71e75c97f97a9645d25fbf3d8e4165a558f18747 is the first bad commit > commit 71e75c97f97a9645d25fbf3d8e4165a558f18747 > Author: Christoph Hellwig > Date: Fri Apr 11 19:07:01 2014 +0200 > > scsi: convert device_busy to atomic_t That's fixed upstream: commit 480cadc2b7e0fa2bbab20141efb547dfe0c3707c Author: Guenter Roeck Date: Sun Aug 10 05:54:25 2014 -0700 scsi: Fix qemu boot hang problem Could you try with a kernel that has that fix? Thanks, James -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Sym2 scsi hang on boot on sparc64
On Tue, Aug 19, 2014 at 11:17:48PM +0300, Aaro Koskinen wrote: > Hi, > > On Tue, Aug 19, 2014 at 09:47:35AM -0500, James Bottomley wrote: > > On Tue, 2014-08-19 at 17:37 +0300, Meelis Roos wrote: > > > > On Tue, 2014-08-19 at 14:25 +0300, Meelis Roos wrote: > > > > > 3.16 scsi worked fine, 3.17-rc1 misbehaves on 3 of my sparc64 test > > > > > machines. E220R and E420R are with onboard 5c3875, V210 is with > > > > > onboarc > > > > > 53c1010 and all behave the same. Any ideas whre to dig deeper? > > > > > bisection > > > > > might be nontrivial, because of sparc64 changes that are OK on > > > > > 3.17-rc1 > > > > > again - but is possible if nothing else helps. > > > > > > > > We've got a parisc with an 875 as a root SCSI bus ... I haven't got > > > > around to building for it yet, but I might find time to try today. > > > > > > Same on parisc: > > > > > > sym0: <1010-66> rev 0x1 at pci :20:01.0 irq 22 > > > sym0: PA-RISC Firmware, ID 7, Fast-80, LVD, parity checking > > > sym0: SCSI BUS has been reset. > > > scsi host0: sym-2.2.3 > > > random: nonblocking pool is initialized > > > > > > and hangs here. So hopefully it is reproducible for you. > > > > And also independent of the sparc changes. The only other change in the > > window you quote is 64 bit luns. > > Bisection (on PA-RISC) points to: > > 71e75c97f97a9645d25fbf3d8e4165a558f18747 is the first bad commit > commit 71e75c97f97a9645d25fbf3d8e4165a558f18747 > Author: Christoph Hellwig > Date: Fri Apr 11 19:07:01 2014 +0200 > > scsi: convert device_busy to atomic_t I guess you need this fix: diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c index 9c44392..ce62e87 100644 --- a/drivers/scsi/scsi_lib.c +++ b/drivers/scsi/scsi_lib.c @@ -1774,7 +1774,7 @@ static void scsi_request_fn(struct request_queue *q) blk_requeue_request(q, req); atomic_dec(&sdev->device_busy); out_delay: - if (atomic_read(&sdev->device_busy) && !scsi_device_blocked(sdev)) + if (!atomic_read(&sdev->device_busy) && !scsi_device_blocked(sdev)) blk_delay_queue(q, SCSI_QUEUE_DELAY); } James already sent it to Linus. Sam -- 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: Sym2 scsi hang on boot on sparc64
Hi, On Tue, Aug 19, 2014 at 09:47:35AM -0500, James Bottomley wrote: > On Tue, 2014-08-19 at 17:37 +0300, Meelis Roos wrote: > > > On Tue, 2014-08-19 at 14:25 +0300, Meelis Roos wrote: > > > > 3.16 scsi worked fine, 3.17-rc1 misbehaves on 3 of my sparc64 test > > > > machines. E220R and E420R are with onboard 5c3875, V210 is with onboarc > > > > 53c1010 and all behave the same. Any ideas whre to dig deeper? > > > > bisection > > > > might be nontrivial, because of sparc64 changes that are OK on 3.17-rc1 > > > > again - but is possible if nothing else helps. > > > > > > We've got a parisc with an 875 as a root SCSI bus ... I haven't got > > > around to building for it yet, but I might find time to try today. > > > > Same on parisc: > > > > sym0: <1010-66> rev 0x1 at pci :20:01.0 irq 22 > > sym0: PA-RISC Firmware, ID 7, Fast-80, LVD, parity checking > > sym0: SCSI BUS has been reset. > > scsi host0: sym-2.2.3 > > random: nonblocking pool is initialized > > > > and hangs here. So hopefully it is reproducible for you. > > And also independent of the sparc changes. The only other change in the > window you quote is 64 bit luns. Bisection (on PA-RISC) points to: 71e75c97f97a9645d25fbf3d8e4165a558f18747 is the first bad commit commit 71e75c97f97a9645d25fbf3d8e4165a558f18747 Author: Christoph Hellwig Date: Fri Apr 11 19:07:01 2014 +0200 scsi: convert device_busy to atomic_t A. -- 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
[GIT PULL] SCSI fixes for 3.17-rc1
These are the two bug fixes I mentioned in the final merge window pull.
One is a reversed logic check in the device busy tests which can cause a
nasty hang and another crash seen in the new SCSI pool support if the
use count ever goes to zero.
The patch is available here:
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git scsi-fixes
The short changelog is:
Guenter Roeck (1):
fix qemu boot hang problem
Juergen Gross (1):
save command pool address of Scsi_Host
And the diffstat:
drivers/scsi/scsi.c | 12 ++--
drivers/scsi/scsi_lib.c | 2 +-
2 files changed, 11 insertions(+), 3 deletions(-)
With full diff below.
James
---
diff --git a/drivers/scsi/scsi.c b/drivers/scsi/scsi.c
index df33060..d81f3cc 100644
--- a/drivers/scsi/scsi.c
+++ b/drivers/scsi/scsi.c
@@ -377,6 +377,10 @@ scsi_alloc_host_cmd_pool(struct Scsi_Host *shost)
pool->slab_flags |= SLAB_CACHE_DMA;
pool->gfp_mask = __GFP_DMA;
}
+
+ if (hostt->cmd_size)
+ hostt->cmd_pool = pool;
+
return pool;
}
@@ -421,8 +425,10 @@ out:
out_free_slab:
kmem_cache_destroy(pool->cmd_slab);
out_free_pool:
- if (hostt->cmd_size)
+ if (hostt->cmd_size) {
scsi_free_host_cmd_pool(pool);
+ hostt->cmd_pool = NULL;
+ }
goto out;
}
@@ -444,8 +450,10 @@ static void scsi_put_host_cmd_pool(struct Scsi_Host *shost)
if (!--pool->users) {
kmem_cache_destroy(pool->cmd_slab);
kmem_cache_destroy(pool->sense_slab);
- if (hostt->cmd_size)
+ if (hostt->cmd_size) {
scsi_free_host_cmd_pool(pool);
+ hostt->cmd_pool = NULL;
+ }
}
mutex_unlock(&host_cmd_pool_mutex);
}
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 9c44392..ce62e87 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -1774,7 +1774,7 @@ static void scsi_request_fn(struct request_queue *q)
blk_requeue_request(q, req);
atomic_dec(&sdev->device_busy);
out_delay:
- if (atomic_read(&sdev->device_busy) && !scsi_device_blocked(sdev))
+ if (!atomic_read(&sdev->device_busy) && !scsi_device_blocked(sdev))
blk_delay_queue(q, SCSI_QUEUE_DELAY);
}
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] scsi.mq:Added enable_cmd_list flags in hostt to reduce lock contention
Add enable_cmd_list flag in shost template to indicate scs.mq stack
to keep track of cmd_list per sdev.
Default behaviour is not to keep track of cmd_list per sdev, as this may
introduce
lock contention. (overhead is more on multi-node NUMA.)
Patch is tested using megaraid_sas driver with "enable_cmd_list" value set to 1
and 0.
Added MAINTAINER of Adaptec to verify changes.
Signed-off-by: Kashyap Desai
--
diff --git a/drivers/scsi/aacraid/linit.c b/drivers/scsi/aacraid/linit.c
index 63f576c..6cb5132 100644
--- a/drivers/scsi/aacraid/linit.c
+++ b/drivers/scsi/aacraid/linit.c
@@ -1082,6 +1082,7 @@ static struct scsi_host_template aac_driver_template = {
.use_clustering = ENABLE_CLUSTERING,
.emulated = 1,
.no_write_same = 1,
+ .enable_cmd_list= 1,
};
static void __aac_shutdown(struct aac_dev * aac)
diff --git a/drivers/scsi/dpt_i2o.c b/drivers/scsi/dpt_i2o.c
index 67283ef..3c91ba6 100644
--- a/drivers/scsi/dpt_i2o.c
+++ b/drivers/scsi/dpt_i2o.c
@@ -3565,6 +3565,7 @@ static struct scsi_host_template driver_template = {
.this_id= 7,
.cmd_per_lun= 1,
.use_clustering = ENABLE_CLUSTERING,
+ .enable_cmd_list= 1,
};
static int __init adpt_init(void)
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 9c44392..a3ddaa5 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -645,16 +645,18 @@ static void scsi_mq_free_sgtables(struct scsi_cmnd *cmd)
static void scsi_mq_uninit_cmd(struct scsi_cmnd *cmd)
{
struct scsi_device *sdev = cmd->device;
+ struct Scsi_Host *shost = sdev->host;
unsigned long flags;
- BUG_ON(list_empty(&cmd->list));
-
scsi_mq_free_sgtables(cmd);
scsi_uninit_cmd(cmd);
- spin_lock_irqsave(&sdev->list_lock, flags);
- list_del_init(&cmd->list);
- spin_unlock_irqrestore(&sdev->list_lock, flags);
+ if (shost->hostt->enable_cmd_list) {
+ BUG_ON(list_empty(&cmd->list));
+ spin_lock_irqsave(&sdev->list_lock, flags);
+ list_del_init(&cmd->list);
+ spin_unlock_irqrestore(&sdev->list_lock, flags);
+ }
}
/*
@@ -1817,12 +1819,14 @@ static int scsi_mq_prep_fn(struct request *req)
cmd->jiffies_at_alloc = jiffies;
/*
-* XXX: cmd_list lookups are only used by two drivers, try to get
-* rid of this list in common code.
+* XXX: cmd_list lookups are only used by two drivers. Try to
+* reduce lock contention, managing sdev cmd_list for requested driver.
*/
- spin_lock_irq(&sdev->list_lock);
- list_add_tail(&cmd->list, &sdev->cmd_list);
- spin_unlock_irq(&sdev->list_lock);
+ if (shost->hostt->enable_cmd_list) {
+ spin_lock_irq(&sdev->list_lock);
+ list_add_tail(&cmd->list, &sdev->cmd_list);
+ spin_unlock_irq(&sdev->list_lock);
+ }
sg = (void *)cmd + sizeof(struct scsi_cmnd) + shost->hostt->cmd_size;
cmd->sdb.table.sgl = sg;
diff --git a/include/scsi/scsi_host.h b/include/scsi/scsi_host.h
index ba20347..ebef2eb 100644
--- a/include/scsi/scsi_host.h
+++ b/include/scsi/scsi_host.h
@@ -514,6 +514,9 @@ struct scsi_host_template {
/* temporary flag to disable blk-mq I/O path */
bool disable_blk_mq;
+
+ /* temporary flag to enable cmd_list per sdev */
+ bool enable_cmd_list;
};
/*
--
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: Bad tag value in scsi-mq.4
I may take a look again, but was able to get this working on my Rhel7 box (with the kernel boot parameter present). So I either consistently used an earlier version of GRUB incorrectly (possible, maybe when I double checked my boot parameters in the earlier version I somehow reset to defaults?) or found some strange bug. I'm not too concerned, since other members of the team haven't had problems and have been using the SCSI mq code more than I have. Sorry for the false alarm! Joe -Original Message- From: h...@infradead.org [mailto:h...@infradead.org] Sent: Tuesday, August 19, 2014 1:05 PM To: Handzik, Joe Cc: h...@infradead.org; linux-scsi@vger.kernel.org; scame...@beardog.cce.hp.com; Scales, Webb; Teel, Scott Stacy Subject: Re: Bad tag value in scsi-mq.4 On Tue, Aug 05, 2014 at 07:47:12PM +, Handzik, Joe wrote: > Yeah, we thought about that one. We call scsi_activate_tcq if our scsi_device > has tagged_supported set within hpsa_change_queue_type (our > .change_queue_type entry into the scsi_host_template). Also made sure I was > booting with the "scsi_mod.use_blk_mq=Y" option, which makes no difference > either way. Can you add some tracing to catch this? On the non-mq path requests start out with ->tag set to -1 and blk_queue_start_tag, which is called from scsi_request_fn sets it up. Adding printks in that area should help you to find the culprit. -- 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/arcmsr: Add timeout module parameter
On Tue, Aug 05, 2014 at 04:10:08PM +0300, Ari Sundholm wrote: > > On Mon, 4 Aug 2014, Christoph Hellwig wrote: > > > To modify the timeout on a queue please use blk_queue_rq_timeout in > > the slave_configure method instead of poking directly into the block > > timer, which won't work e.g. for the blk-mq path. > > I see. It seems the way the driver Areca offers on its download page does > this is wrong, then, as all I did was I ported the feature from there. > > > But this really needs an explanation on why you'd need a configurable > > timeout to start with. > > A colleague of mine has experienced problems with disks not supporting > TLER performing lengthy error recovery, hitting a timeout. He has > mitigated this problem by configuring the timeout to be long enough to > allow for the error recovery to finish. And again, the driver offered by > Areca supports this feature, so it seems they have their reasons as well. Can you test this patch: http://git.infradead.org/users/hch/scsi-queue.git/commitdiff/3a7fcf9e5f57469fab78d6b6db81fbef6fa48a0d which is part of the latest Areca code drop? I don't really like the timeout parameter, but if there's no better work around for you we'll probablyneed to merge something. In that case I'd love a patch ontop of the branch that the above patches is in, which used the timeout manipulation method I mentioned in my previous mail. -- 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: Bad tag value in scsi-mq.4
On Tue, Aug 05, 2014 at 07:47:12PM +, Handzik, Joe wrote: > Yeah, we thought about that one. We call scsi_activate_tcq if our scsi_device > has tagged_supported set within hpsa_change_queue_type (our > .change_queue_type entry into the scsi_host_template). Also made sure I was > booting with the "scsi_mod.use_blk_mq=Y" option, which makes no difference > either way. Can you add some tracing to catch this? On the non-mq path requests start out with ->tag set to -1 and blk_queue_start_tag, which is called from scsi_request_fn sets it up. Adding printks in that area should help you to find the culprit. -- 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: Question about scsi error handling and LLD
On Tue, Aug 19, 2014 at 12:16:12PM -0500, James Bottomley wrote: > On Tue, 2014-08-19 at 10:30 -0500, scame...@beardog.cce.hp.com wrote: > > > > Is it permitted for a LLD to call scsi_done() for a command which > > has been or is attempting to be aborted via the LLD abort error handler > > function? > > > > I am looking at the scsi mid layer code, and I'm a bit confused. > > Hannes asked a similar question; does this help: > > http://marc.info/?l=linux-scsi&m=140267838320488 [...] Yes, that helps. Thanks. -- steve -- 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/3] scsi_debug: review fixes for scsi-mq changes
Thanks, I've applied all three patches to the driver-for-3.18 branch. -- 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: [Bug 80711] [PATCH]SG_FLAG_LUN_INHIBIT is no longer implemented and there's not way to prevent the kernel from using the 2nd cdb byte for the LUN
On Thu, Aug 07, 2014 at 11:58:37AM -0400, Alan Stern wrote: > > On Wed, Aug 06, 2014 at 04:02:22PM -0400, Alan Stern wrote: > > > > I doubt either of them forces users to hack up flags for these cases. > > > > > > Why was this change needed in the first place? There's no explanation > > > in the patch itself. > > > > Which chance? The one to not support SG_FLAG_LUN_INHIBIT? > > No, the patch that started this Bugzilla entry. Tiziano says it is > needed in order to send vendor-specific commands that use the LUN bits > in CDB[1]. Yes, I'd really like to know the exact scenario. What kind of command is this and who sends it? -- 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 09/10] scsi: sd: Avoid sending medium write commands if device is write protected
On Mon, Aug 11, 2014 at 5:40 AM, Dolev Raviv wrote: > From: Sujit Reddy Thumma > > The SYNCHRONIZE_CACHE command is a medium write command and hence can > fail when the device is write protected. Avoid sending such commands by > making sure that write-cache-enable is disabled even though the device > claim to support it. > > Signed-off-by: Sujit Reddy Thumma > Signed-off-by: Dolev Raviv Looks good. Setting SWP is defined to flush caches; there is no other reason I could imagine WP media would need a SYNCHRONIZE CACHE. Reviewed-by: Venkatesh Srinivas -- vs; -- 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] Drivers: scsi: storvsc: Force discovery of LUNs that may have been removed.
On Sat, Aug 16, 2014 at 08:09:48PM -0700, K. Y. Srinivasan wrote: > The host asks the guest to scan when a LUN is removed or added. > The only way a guest can identify the removed LUN is when an I/O is > attempted on a removed LUN - the SRB status code indicates that the LUN > is invalid. We currently handle this SRB status and remove the device. > > Rather than waiting for an I/O to remove the device, force the discovery of > LUNs that may have been removed prior to discovering LUNs that may have > been added. This looks pretty reasonable to me, but I wonder if we should move this up to common code so that it happens for any host rescan triggered by sysfs or other drivers as well. -- 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: Fix qemu boot hang problem
James, can you please send this on ASAP? Sitting for oever a week
on a boot regression that comes with a patch isn't reasonable.
On Sun, Aug 10, 2014 at 05:54:25AM -0700, Guenter Roeck wrote:
> The latest kernel fails to boot qemu arm images when using scsi
> for disk access. Boot gets stuck after the following messages.
>
> brd: module loaded
> sym53c8xx :00:0c.0: enabling device (0100 -> 0103)
> sym0: <895a> rev 0x0 at pci :00:0c.0 irq 93
> sym0: No NVRAM, ID 7, Fast-40, LVD, parity checking
> sym0: SCSI BUS has been reset.
> scsi host0: sym-2.2.3
>
> Bisect points to commit 71e75c97f97a ("scsi: convert device_busy to
> atomic_t"). Code inspection shows the following suspicious change
> in scsi_request_fn.
>
> out_delay:
> - if (sdev->device_busy == 0 && !scsi_device_blocked(sdev))
> + if (atomic_read(&sdev->device_busy) && !scsi_device_blocked(sdev))
> blk_delay_queue(q, SCSI_QUEUE_DELAY);
> }
>
> 'sdev->device_busy == 0' was replaced with 'atomic_read(&sdev->device_busy)',
> meaning the logic was reversed. Changing this expression to
> '!atomic_read(&sdev->device_busy)' fixes the problem.
>
> Cc: Christoph Hellwig
> Cc: Hannes Reinecke
> Cc: Webb Scales
> Cc: Jens Axboe
> Signed-off-by: Guenter Roeck
> ---
> drivers/scsi/scsi_lib.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
> index 9c44392..ce62e87 100644
> --- a/drivers/scsi/scsi_lib.c
> +++ b/drivers/scsi/scsi_lib.c
> @@ -1774,7 +1774,7 @@ static void scsi_request_fn(struct request_queue *q)
> blk_requeue_request(q, req);
> atomic_dec(&sdev->device_busy);
> out_delay:
> - if (atomic_read(&sdev->device_busy) && !scsi_device_blocked(sdev))
> + if (!atomic_read(&sdev->device_busy) && !scsi_device_blocked(sdev))
> blk_delay_queue(q, SCSI_QUEUE_DELAY);
> }
>
> --
> 1.9.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
---end quoted text---
--
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 09/10] scsi: sd: Avoid sending medium write commands if device is write protected
This looks reasonable to me. Martin, and objections?
On Mon, Aug 11, 2014 at 03:40:37PM +0300, Dolev Raviv wrote:
> From: Sujit Reddy Thumma
>
> The SYNCHRONIZE_CACHE command is a medium write command and hence can
> fail when the device is write protected. Avoid sending such commands by
> making sure that write-cache-enable is disabled even though the device
> claim to support it.
>
> Signed-off-by: Sujit Reddy Thumma
> Signed-off-by: Dolev Raviv
>
> diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
> index 3663e38..67282bf 100644
> --- a/drivers/scsi/sd.c
> +++ b/drivers/scsi/sd.c
> @@ -185,7 +185,7 @@ cache_type_store(struct device *dev, struct
> device_attribute *attr,
> if (ct < 0)
> return -EINVAL;
> rcd = ct & 0x01 ? 1 : 0;
> - wce = ct & 0x02 ? 1 : 0;
> + wce = (ct & 0x02) && !sdkp->write_prot ? 1 : 0;
>
> if (sdkp->cache_override) {
> sdkp->WCE = wce;
> @@ -2493,6 +2493,10 @@ sd_read_cache_type(struct scsi_disk *sdkp, unsigned
> char *buffer)
> sdkp->DPOFUA = 0;
> }
>
> + /* No cache flush allowed for write protected devices */
> + if (sdkp->WCE && sdkp->write_prot)
> + sdkp->WCE = 0;
> +
> if (sdkp->first_scan || old_wce != sdkp->WCE ||
> old_rcd != sdkp->RCD || old_dpofua != sdkp->DPOFUA)
> sd_printk(KERN_NOTICE, sdkp,
> --
> 1.8.5.2
> --
> QUALCOMM ISRAEL, on behalf of Qualcomm Innovation Center, Inc. is a member
> of Code Aurora Forum, hosted by The Linux Foundation
> --
> 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
---end quoted text---
--
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: fix various kernel-doc problems in scsi_error.c
Thanks, I've applied both docbook fixups to the drivers-for-3.18 and also addressed the addition nitpicks from Ewan. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 10/15] scsi: fix decimal printf format specifiers prefixed with 0x
Thanks, applied to the drivers-for-3.18 tree. -- 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] hpsa: refine the pci enable/disable handling
Thanks, applied to the drivers-for-3.18 branch. -- 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] pm8001: Update nvmd response data to request buffer
Thanks, applied to the drivers-for-3.18 branch. -- 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/5] be2iscsi: Fix the sparse warning introduced in previous submission
Thanks, applied the whole series to the drivers-for-3.18 tree. -- 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/RFC V2 07/16] scsi: support well known logical units
On Thu, Aug 14, 2014 at 04:30:58PM +0300, Dolev Raviv wrote:
> From: Subhash Jadavani
>
> REPORT LUNS command has "SELECT REPORT" field which controls what type of
> logical units to be reported by device server. According to UFS device
> standard, if this field is set to 0, REPORT LUNS would report only report
> standard logical units. If it's set to 1 then it would report only well
> known logical unit and if it's set to 2 then device would report both
> standard and well known logical units.
> Some well-known logical units might not have scsi upper-layer drivers. In
> such cases, the runtime PM reference count increased during device
> enumeration will not be decreased, causing the parent device (host) to
> always be on even during idle.
>
> This change allows the SCSI LLD (Low Level Driver) to choose which type
> of logical units should be detected.
>
> Signed-off-by: Subhash Jadavani
> Signed-off-by: Sujit Reddy Thumma
> Signed-off-by: Dolev Raviv
>
> diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c
> index 4a6e4ba..5a0e164 100644
> --- a/drivers/scsi/scsi_scan.c
> +++ b/drivers/scsi/scsi_scan.c
> @@ -802,6 +802,14 @@ static int scsi_add_lun(struct scsi_device *sdev,
> unsigned char *inq_result,
> } else {
> sdev->type = (inq_result[0] & 0x1f);
> sdev->removable = (inq_result[1] & 0x80) >> 7;
> +
> + /*
> + * some devices may respond with wrong type for
> + * well-known logical units. Force well-known type
> + * to enumerate them correctly.
> + */
> + if (scsi_is_wlun(sdev->lun) && (sdev->type != TYPE_WLUN))
> + sdev->type = TYPE_WLUN;
no need to test for TYPE_WLUN here.
> switch (sdev->type) {
> @@ -817,6 +825,7 @@ static int scsi_add_lun(struct scsi_device *sdev,
> unsigned char *inq_result,
> case TYPE_COMM:
> case TYPE_RAID:
> case TYPE_OSD:
> + case TYPE_WLUN:
> sdev->writeable = 1;
> break;
> case TYPE_ROM:
This switch statements has been removed in 3.17-rc1, please rebase your
series on top of it. While you're at it please make this patch, which
introduceѕ core scsi changes first in the series.
> @@ -1412,6 +1421,13 @@ static int scsi_report_lun_scan(struct scsi_target
> *starget, int bflags,
>*/
> memset(&scsi_cmd[1], 0, 5);
>
> + if (shost->report_wlus)
> + /*
> + * Set "SELECT REPORT" field to 0x2 which will make device to
> + * report well known logical units along with standard LUs.
> + */
> + scsi_cmd[2] = 0x2;
So we're finally getting well known LUN support. I think we should key this
off the SBC compliance level and not have the drivers opt in.
> diff --git a/drivers/scsi/scsi_sysfs.c b/drivers/scsi/scsi_sysfs.c
> index 5f36788..ba9d0f0 100644
> --- a/drivers/scsi/scsi_sysfs.c
> +++ b/drivers/scsi/scsi_sysfs.c
> @@ -1060,6 +1060,13 @@ int scsi_sysfs_add_sdev(struct scsi_device *sdev)
> }
> }
>
> + /*
> + * put runtime pm reference for well-known logical units,
> + * drivers are expected to _get_* again during probe.
> + */
> + if (scsi_is_wlun(sdev->lun))
> + scsi_autopm_put_device(sdev);
Special casing the well known LUNs here seems wrong. Shouldn't we do this
for any devices that don't get a driver attached to them?
--
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: Question about scsi error handling and LLD
On Tue, 2014-08-19 at 10:30 -0500, scame...@beardog.cce.hp.com wrote: > > Is it permitted for a LLD to call scsi_done() for a command which > has been or is attempting to be aborted via the LLD abort error handler > function? > > I am looking at the scsi mid layer code, and I'm a bit confused. Hannes asked a similar question; does this help: http://marc.info/?l=linux-scsi&m=140267838320488 James > There seem to be a few ways the LLD abort handler function can > get called. > > One path: > > scsi_times_out() calls scsi_abort_command() which queues > cmd->abort_work in 10ms. This will cause scmd_eh_abort_handler() > to be called, which can call scsi_try_to_abort_cmd() which > calls the LLD abort error handler function. If the LLD abort > error handler function returns SUCCESS, then scmd_eh_abort_handler() > may requeue the command via scsi_queue_insert() re-using the same > scsi_cmnd pointer. Or, it may call scsi_finish_cmnd() on that > scsi_cmnd. > > Both of those actions, requeueing the same scsi command, or calling > scsi_finish_cmnd(), seem incompatible with the LLD also having > called scsi_done() on the command. > > I think, scsi_done eventually frees the scsi_cmnd... > > scsi_done() -> blk_complete_request -> __blk_complete_request -> > -> raise_softirq_irqoff -> ??? -> scsi_softirq_done() -> > -> scsi_finish_cmnd() -> scsi_io_completion -> scsi_end_request() > -> scsi_mq_uninit_cmd() ... etc. > > It seems like either calling scsi_finish_cmnd() too many times (once via > LLD calling scsi_done, and once via scmd_eh_abort_handler calling > scsi_finish_cmnd()), or calling scsi_done() via LLD concurrently with > re-using that same scsi command (via scmd_eh_abort_handler calling > scsi_queue_insert()) would both be bad things. Correct? > > So, without completely understanding it, it seems like if the LLD > abort handler is going to return SUCCESS, it must be sure that it > hasn't already called scsi_done() on the command. Or to put it > another way, the LLD must make sure there is not a race between > the abort handler and the interrupt handler, and the instant > the LLD abort handler is called for a command, calling scsi_done() > for that command is no longer an option for the LLD. But, I do > not see how to synchronize that. > > I hope I'm missing something here, because I am having a hard time > seeing how to eliminate the race between the LLD abort handler and > command completion in the LLD, esp. since now (due to my hardware's > specific weirdness) I may in the interrupt handler requeue the command > internally in a workqueue within the LLD for submission to HW a 2nd > time before completion back to the mid layer under some circumstances > (e.g. fast path failed, try slower but more robust RAID stack path.) > > But, then there is this comment attached to scsi_times_out() which > makes me feel better: > > * Notes: > * We do not need to lock this. There is the potential for a race > * only in that the normal completion handling might run, but if the > * normal completion function determines that the timer has already > * fired, then it mustn't do anything. > */ > > So, perhaps that is the answer I'm looking for. If the comment is > correct and my understanding of it is correct, then the LLD *is* free > to call scsi_done() even though it races with the LLD abort handler? > > I'm not finding the code that implements what that comment claims though. > Is it in the block layer code? > > -- steve > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-scsi" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 00/13] scsi: Use pci_enable_msix_range() instead of pci_enable_msix()
Thanks, I've applied patches 1 to 7 to the drivers-for-3.18 branch. -- 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] bnx2fc: fix incorrect DMA memory mapping in bnx2fc_map_sg()
Can I get a review for this one, please? -- 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] drivers: message: fusion: Simplify rounding
On Tue, Jul 01, 2014 at 02:56:20PM +0200, Rasmus Villemoes wrote: > Rounding up to a multiple of 4 should be done using the ALIGN > macro. As a bonus, this also makes the generated code smaller. > > In GetIocFacts(), sz is assigned to a few lines below without being > read in the meantime, so it is ok that it doesn't end up with the same > value as facts->FWImageSize. > > Signed-off-by: Rasmus Villemoes > Reviewed-by: Joe Lawrence Thanks, applied to the drivers-for-3.18 branch. -- 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/14] scsi: add support for a blk-mq based I/O path.
On Tue, Aug 19, 2014 at 9:36 PM, Christoph Hellwig wrote: > On Tue, Aug 19, 2014 at 03:51:42AM +0530, Kashyap Desai wrote: >> I read this comment and find that very few drivers are using this >> cmd_list. I think if we remove this cmd_list, performance will scale as I >> am seeing major contention in this lock. >> Just thought to ping you to see if this is known limitation for now or any >> plan to change this lock in near future ? > > Removing the lock entirely and pushing the list into the two drivers > using it is on my TODO list. Bart actually suggested keeping the code in the > SCSI core and having a flag to enabled. Given that I'm too busy to get my > full > version done in time, it might be a good idea if someone picks up Barts > idea. Can you send me a patch to add a enable_cmd_list flag to the host > template and only enable it for aacraid and dpt_i2o? > Sure. I will work on relevant code change and will post patch for review. -- Device Driver Developer @ Avagotech Kashyap D. Desai Note - my new email address kashyap.de...@avagotech.com -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 13/14] scsi: add support for a blk-mq based I/O path.
On Tue, Aug 19, 2014 at 03:51:42AM +0530, Kashyap Desai wrote: > I read this comment and find that very few drivers are using this > cmd_list. I think if we remove this cmd_list, performance will scale as I > am seeing major contention in this lock. > Just thought to ping you to see if this is known limitation for now or any > plan to change this lock in near future ? Removing the lock entirely and pushing the list into the two drivers using it is on my TODO list. Bart actually suggested keeping the code in the SCSI core and having a flag to enabled. Given that I'm too busy to get my full version done in time, it might be a good idea if someone picks up Barts idea. Can you send me a patch to add a enable_cmd_list flag to the host template and only enable it for aacraid and dpt_i2o? -- 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/14] scsi: add support for a blk-mq based I/O path.
On Tue, Aug 19, 2014 at 3:51 AM, Kashyap Desai
wrote:
>
> > -Original Message-
> > From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi-
> > ow...@vger.kernel.org] On Behalf Of Christoph Hellwig
> > Sent: Friday, July 18, 2014 3:43 PM
> > To: James Bottomley; linux-scsi@vger.kernel.org
> > Cc: Jens Axboe; Bart Van Assche; Mike Christie; Martin K. Petersen;
> Robert
> > Elliott; Webb Scales; linux-ker...@vger.kernel.org
> > Subject: [PATCH 13/14] scsi: add support for a blk-mq based I/O path.
> >
> > This patch adds support for an alternate I/O path in the scsi midlayer
> which
> > uses the blk-mq infrastructure instead of the legacy request code.
> >
> > Use of blk-mq is fully transparent to drivers, although for now a host
> > template field is provided to opt out of blk-mq usage in case any
> unforseen
> > incompatibilities arise.
> >
> > In general replacing the legacy request code with blk-mq is a simple and
> > mostly mechanical transformation. The biggest exception is the new code
> > that deals with the fact the I/O submissions in blk-mq must happen from
> > process context, which slightly complicates the I/O completion handler.
> > The second biggest differences is that blk-mq is build around the
> concept of
> > preallocated requests that also include driver specific data, which in
> SCSI
> > context means the scsi_cmnd structure. This completely avoids dynamic
> > memory allocations for the fast path through I/O submission.
> >
> > Due the preallocated requests the MQ code path exclusively uses the
> host-
> > wide shared tag allocator instead of a per-LUN one. This only affects
> drivers
> > actually using the block layer provided tag allocator instead of their
> own.
> > Unlike the old path blk-mq always provides a tag, although drivers don't
> have
> > to use it.
> >
> > For now the blk-mq path is disable by defauly and must be enabled using
> the
> > "use_blk_mq" module parameter. Once the remaining work in the block
> > layer to make blk-mq more suitable for slow devices is complete I hope
> to
> > make it the default and eventually even remove the old code path.
> >
> > Based on the earlier scsi-mq prototype by Nicholas Bellinger.
> >
> > Thanks to Bart Van Assche and Robert Elliot for testing, benchmarking
> and
> > various sugestions and code contributions.
> >
> > Signed-off-by: Christoph Hellwig
> > Reviewed-by: Hannes Reinecke
> > Reviewed-by: Webb Scales
> > Acked-by: Jens Axboe
> > Tested-by: Bart Van Assche
> > Tested-by: Robert Elliott
> > ---
> > drivers/scsi/hosts.c | 35 +++-
> > drivers/scsi/scsi.c | 5 +-
> > drivers/scsi/scsi_lib.c | 464
> > --
> > drivers/scsi/scsi_priv.h | 3 +
> > drivers/scsi/scsi_scan.c | 5 +-
> > drivers/scsi/scsi_sysfs.c | 2 +
> > include/scsi/scsi_host.h | 18 +-
> > include/scsi/scsi_tcq.h | 28 ++-
> > 8 files changed, 488 insertions(+), 72 deletions(-)
> >
> > diff --git a/drivers/scsi/hosts.c b/drivers/scsi/hosts.c index
> 0632eee..6de80e3
> > 100644
> > --- a/drivers/scsi/hosts.c
> > +++ b/drivers/scsi/hosts.c
> > @@ -213,9 +213,24 @@ int scsi_add_host_with_dma(struct Scsi_Host
> > *shost, struct device *dev,
> > goto fail;
> > }
> >
> > + if (shost_use_blk_mq(shost)) {
> > + error = scsi_mq_setup_tags(shost);
> > + if (error)
> > + goto fail;
> > + }
> > +
> > + /*
> > + * Note that we allocate the freelist even for the MQ case for
> now,
> > + * as we need a command set aside for scsi_reset_provider. Having
> > + * the full host freelist and one command available for that is a
> > + * little heavy-handed, but avoids introducing a special allocator
> > + * just for this. Eventually the structure of scsi_reset_provider
> > + * will need a major overhaul.
> > + */
> > error = scsi_setup_command_freelist(shost);
> > if (error)
> > - goto fail;
> > + goto out_destroy_tags;
> > +
> >
> > if (!shost->shost_gendev.parent)
> > shost->shost_gendev.parent = dev ? dev : &platform_bus;
> > @@ -226,7 +241,7 @@ int scsi_add_host_with_dma(struct Scsi_Host *shost,
> > struct device *dev,
> >
> > error = device_add(&shost->shost_gendev);
> > if (error)
> > - goto out;
> > + goto out_destroy_freelist;
> >
> > pm_runtime_set_active(&shost->shost_gendev);
> > pm_runtime_enable(&shost->shost_gendev);
> > @@ -279,8 +294,11 @@ int scsi_add_host_with_dma(struct Scsi_Host
> > *shost, struct device *dev,
> > device_del(&shost->shost_dev);
> > out_del_gendev:
> > device_del(&shost->shost_gendev);
> > - out:
> > + out_destroy_freelist:
> > scsi_destroy_command_freelist(shost);
> > + out_destroy_tags:
> > + if (shost_use_blk_mq(shost))
> > + scsi_mq_destroy_tags(shost);
> > fail:
> > return error;
> > }
> > @@ -309,8
Re: [PATCH v7 3/3] ahci_xgene: Fix the link down in first attempt for the APM X-Gene SoC AHCI SATA host controller driver.
On Tue, Aug 19, 2014 at 12:01:51PM +0530, Suman Tripathi wrote: > The link down issue in first attempt happens due to 2 H/W errata below: > > 1. Due to HW errata, during speed negotiation, sometimes controller > is not able to detect ALIGN at GEN3(6Gbps) within 54.6us results in > a timeout. This issue can be recovered by issuing a COMRESET again. > > 2. Due to HW errata, although ALIGH detection is successfull, due to > 8b/10b and disparity BERR, sometimes the signature from the drive is > not received successfully by the Host controller. Due to this the > communication with the host and drive is not established due to > locking of CDR(clock and data recovery) circuit. This issue can be > recovered by issuing a COMRESET again. > > This patch fixes the above issues by retrying the COMRESET with a > maximum attempts of 3. It's kinda nasty but if it's necessary. That said, can you please update the comment so that it actually matches the code? Also, Wouldn't it be better to check how the reset failed before retrying? Thanks. -- tejun -- 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
Question about scsi error handling and LLD
Is it permitted for a LLD to call scsi_done() for a command which has been or is attempting to be aborted via the LLD abort error handler function? I am looking at the scsi mid layer code, and I'm a bit confused. There seem to be a few ways the LLD abort handler function can get called. One path: scsi_times_out() calls scsi_abort_command() which queues cmd->abort_work in 10ms. This will cause scmd_eh_abort_handler() to be called, which can call scsi_try_to_abort_cmd() which calls the LLD abort error handler function. If the LLD abort error handler function returns SUCCESS, then scmd_eh_abort_handler() may requeue the command via scsi_queue_insert() re-using the same scsi_cmnd pointer. Or, it may call scsi_finish_cmnd() on that scsi_cmnd. Both of those actions, requeueing the same scsi command, or calling scsi_finish_cmnd(), seem incompatible with the LLD also having called scsi_done() on the command. I think, scsi_done eventually frees the scsi_cmnd... scsi_done() -> blk_complete_request -> __blk_complete_request -> -> raise_softirq_irqoff -> ??? -> scsi_softirq_done() -> -> scsi_finish_cmnd() -> scsi_io_completion -> scsi_end_request() -> scsi_mq_uninit_cmd() ... etc. It seems like either calling scsi_finish_cmnd() too many times (once via LLD calling scsi_done, and once via scmd_eh_abort_handler calling scsi_finish_cmnd()), or calling scsi_done() via LLD concurrently with re-using that same scsi command (via scmd_eh_abort_handler calling scsi_queue_insert()) would both be bad things. Correct? So, without completely understanding it, it seems like if the LLD abort handler is going to return SUCCESS, it must be sure that it hasn't already called scsi_done() on the command. Or to put it another way, the LLD must make sure there is not a race between the abort handler and the interrupt handler, and the instant the LLD abort handler is called for a command, calling scsi_done() for that command is no longer an option for the LLD. But, I do not see how to synchronize that. I hope I'm missing something here, because I am having a hard time seeing how to eliminate the race between the LLD abort handler and command completion in the LLD, esp. since now (due to my hardware's specific weirdness) I may in the interrupt handler requeue the command internally in a workqueue within the LLD for submission to HW a 2nd time before completion back to the mid layer under some circumstances (e.g. fast path failed, try slower but more robust RAID stack path.) But, then there is this comment attached to scsi_times_out() which makes me feel better: * Notes: * We do not need to lock this. There is the potential for a race * only in that the normal completion handling might run, but if the * normal completion function determines that the timer has already * fired, then it mustn't do anything. */ So, perhaps that is the answer I'm looking for. If the comment is correct and my understanding of it is correct, then the LLD *is* free to call scsi_done() even though it races with the LLD abort handler? I'm not finding the code that implements what that comment claims though. Is it in the block layer code? -- steve -- 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 v7 2/3] ahci_xgene: Skip the PHY and clock initialization if already configured by the firmware.
On Tue, Aug 19, 2014 at 12:01:50PM +0530, Suman Tripathi wrote:
> This patch implements the feature to skip the PHY and clock
> initialization if it is already configured by the firmware.
>
> Signed-off-by: Loc Ho
> Signed-off-by: Suman Tripathi
...
> +static int xgene_ahci_is_memram_inited(struct xgene_ahci_context *ctx)
> +{
> + void __iomem *diagcsr = ctx->csr_diag;
> +
> + if (readl(diagcsr + CFG_MEM_RAM_SHUTDOWN) == 0 &&
> + readl(diagcsr + BLOCK_MEM_RDY) == 0x)
> + return 1;
> + return 0;
> +}
Please make it return bool.
Thanks.
--
tejun
--
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 v3 0/17] arcmsr: change note since v13 or v2
Hi Ching, I've fixed up various checkpatch errors and fixed up some descriptions and applied the patches to a branch. This includes patch 4, so please send a fix for this and any other patches relative to the branch. Please find the branch at git://git.infradead.org/users/hch/scsi-queue.git arcmsr-for-3.18 Can the others help reviewing these patches and make sure we can get them into 3.18? Thanks, Christoph -- 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: Sym2 scsi hang on boot on sparc64
On Tue, 2014-08-19 at 17:37 +0300, Meelis Roos wrote: > > On Tue, 2014-08-19 at 14:25 +0300, Meelis Roos wrote: > > > 3.16 scsi worked fine, 3.17-rc1 misbehaves on 3 of my sparc64 test > > > machines. E220R and E420R are with onboard 5c3875, V210 is with onboarc > > > 53c1010 and all behave the same. Any ideas whre to dig deeper? bisection > > > might be nontrivial, because of sparc64 changes that are OK on 3.17-rc1 > > > again - but is possible if nothing else helps. > > > > We've got a parisc with an 875 as a root SCSI bus ... I haven't got > > around to building for it yet, but I might find time to try today. > > Same on parisc: > > sym0: <1010-66> rev 0x1 at pci :20:01.0 irq 22 > sym0: PA-RISC Firmware, ID 7, Fast-80, LVD, parity checking > sym0: SCSI BUS has been reset. > scsi host0: sym-2.2.3 > random: nonblocking pool is initialized > > and hangs here. So hopefully it is reproducible for you. And also independent of the sparc changes. The only other change in the window you quote is 64 bit luns. James -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Sym2 scsi hang on boot on sparc64
> On Tue, 2014-08-19 at 14:25 +0300, Meelis Roos wrote: > > 3.16 scsi worked fine, 3.17-rc1 misbehaves on 3 of my sparc64 test > > machines. E220R and E420R are with onboard 5c3875, V210 is with onboarc > > 53c1010 and all behave the same. Any ideas whre to dig deeper? bisection > > might be nontrivial, because of sparc64 changes that are OK on 3.17-rc1 > > again - but is possible if nothing else helps. > > We've got a parisc with an 875 as a root SCSI bus ... I haven't got > around to building for it yet, but I might find time to try today. Same on parisc: sym0: <1010-66> rev 0x1 at pci :20:01.0 irq 22 sym0: PA-RISC Firmware, ID 7, Fast-80, LVD, parity checking sym0: SCSI BUS has been reset. scsi host0: sym-2.2.3 random: nonblocking pool is initialized and hangs here. So hopefully it is reproducible for you. -- Meelis Roos (mr...@linux.ee) -- 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: Sym2 scsi hang on boot on sparc64
> > 3.16 scsi worked fine, 3.17-rc1 misbehaves on 3 of my sparc64 test > > machines. E220R and E420R are with onboard 5c3875, V210 is with onboarc > > 53c1010 and all behave the same. Any ideas whre to dig deeper? bisection > > might be nontrivial, because of sparc64 changes that are OK on 3.17-rc1 > > again - but is possible if nothing else helps. > > We've got a parisc with an 875 as a root SCSI bus ... I haven't got > around to building for it yet, but I might find time to try today. Come to think of it, I have couple parsisc with 875 too, will try. > > [ 164.639697] PCI: Enabling device: (:00:03.0), cmd 147 > > > > [ 164.705076] sym0: <875> rev 0x14 at pci :00:03.0 irq 13 > > > > [ 164.858446] sym0: No NVRAM, ID 7, Fast-20, SE, parity checking > > > > [ 164.935031] sym0: SCSI BUS has been reset. > > > > [ 164.983113] scsi host0: sym-2.2.3 > > > > [ 165.026358] PCI: Enabling device: (:00:03.1), cmd 3 > > > > [ 165.089634] sym1: <875> rev 0x14 at pci :00:03.1 irq 14 > > > > [ 165.242820] sym1: No NVRAM, ID 7, Fast-20, SE, parity checking > > > > [ 165.319227] sym1: SCSI BUS has been reset. > > > > [ 165.367281] scsi host1: sym-2.2.3 > > > > Does it detect drives in the bit you cut? I ask because one of the > symptoms of a misrouted irq is random problems with bring up. However, > if anything is detected, then the irq must be OK. No, nothing scsi related - rtc detection etc. > > James > > > [ 388.835999] INFO: task swapper/0:1 blocked for more than 120 seconds. > > > > [ 388.912181] Not tainted 3.17.0-rc1 #46 > > > > [ 388.963187] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables > > this message. > > [ 389.056953] swapper/0 D 00483958 7584 1 0 > > 0x2000100 > > [ 389.148575] Call Trace: > > > > [ 389.177747] [0082e5fc] schedule+0x1c/0x80 > > > > [ 389.235024] [00483958] > > async_synchronize_cookie_domain+0x58/0x100 > > [ 389.317301] [00483a28] async_synchronize_full+0x8/0x20 > > > > [ 389.388133] [006ebe04] wait_for_device_probe+0x64/0x80 > > > > [ 389.458938] [009dcffc] prepare_namespace+0x4/0x1b8 > > > > [ 389.525590] [009dcbac] kernel_init_freeable+0x1c0/0x1d8 > > > > [ 389.597450] [008298e4] kernel_init+0x4/0x100 > > > > [ 389.657868] [004060c4] ret_from_fork+0x1c/0x2c > > > > [ 389.720324] [] (null) > > > > [ 389.775518] no locks held by swapper/0/1. > > > > > > > > > > -- > > Meelis Roos (mr...@linux.ee) > > -- > > 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 > > > > -- Meelis Roos (mr...@linux.ee) -- 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: Sym2 scsi hang on boot on sparc64
On Tue, 2014-08-19 at 14:25 +0300, Meelis Roos wrote: > 3.16 scsi worked fine, 3.17-rc1 misbehaves on 3 of my sparc64 test > machines. E220R and E420R are with onboard 5c3875, V210 is with onboarc > 53c1010 and all behave the same. Any ideas whre to dig deeper? bisection > might be nontrivial, because of sparc64 changes that are OK on 3.17-rc1 > again - but is possible if nothing else helps. We've got a parisc with an 875 as a root SCSI bus ... I haven't got around to building for it yet, but I might find time to try today. > [ 164.639697] PCI: Enabling device: (:00:03.0), cmd 147 > > [ 164.705076] sym0: <875> rev 0x14 at pci :00:03.0 irq 13 > > [ 164.858446] sym0: No NVRAM, ID 7, Fast-20, SE, parity checking > > [ 164.935031] sym0: SCSI BUS has been reset. > > [ 164.983113] scsi host0: sym-2.2.3 > > [ 165.026358] PCI: Enabling device: (:00:03.1), cmd 3 > > [ 165.089634] sym1: <875> rev 0x14 at pci :00:03.1 irq 14 > > [ 165.242820] sym1: No NVRAM, ID 7, Fast-20, SE, parity checking > > [ 165.319227] sym1: SCSI BUS has been reset. > > [ 165.367281] scsi host1: sym-2.2.3 > Does it detect drives in the bit you cut? I ask because one of the symptoms of a misrouted irq is random problems with bring up. However, if anything is detected, then the irq must be OK. James > [ 388.835999] INFO: task swapper/0:1 blocked for more than 120 seconds. > > [ 388.912181] Not tainted 3.17.0-rc1 #46 > > [ 388.963187] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables > this message. > [ 389.056953] swapper/0 D 00483958 7584 1 0 > 0x2000100 > [ 389.148575] Call Trace: > > [ 389.177747] [0082e5fc] schedule+0x1c/0x80 > > [ 389.235024] [00483958] async_synchronize_cookie_domain+0x58/0x100 > > [ 389.317301] [00483a28] async_synchronize_full+0x8/0x20 > > [ 389.388133] [006ebe04] wait_for_device_probe+0x64/0x80 > > [ 389.458938] [009dcffc] prepare_namespace+0x4/0x1b8 > > [ 389.525590] [009dcbac] kernel_init_freeable+0x1c0/0x1d8 > > [ 389.597450] [008298e4] kernel_init+0x4/0x100 > > [ 389.657868] [004060c4] ret_from_fork+0x1c/0x2c > > [ 389.720324] [] (null) > > [ 389.775518] no locks held by swapper/0/1. > > > > > -- > Meelis Roos (mr...@linux.ee) > -- > To unsubscribe from this list: send the line "unsubscribe linux-scsi" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Sym2 scsi hang on boot on sparc64
3.16 scsi worked fine, 3.17-rc1 misbehaves on 3 of my sparc64 test machines. E220R and E420R are with onboard 5c3875, V210 is with onboarc 53c1010 and all behave the same. Any ideas whre to dig deeper? bisection might be nontrivial, because of sparc64 changes that are OK on 3.17-rc1 again - but is possible if nothing else helps. [ 164.639697] PCI: Enabling device: (:00:03.0), cmd 147 [ 164.705076] sym0: <875> rev 0x14 at pci :00:03.0 irq 13 [ 164.858446] sym0: No NVRAM, ID 7, Fast-20, SE, parity checking [ 164.935031] sym0: SCSI BUS has been reset. [ 164.983113] scsi host0: sym-2.2.3 [ 165.026358] PCI: Enabling device: (:00:03.1), cmd 3 [ 165.089634] sym1: <875> rev 0x14 at pci :00:03.1 irq 14 [ 165.242820] sym1: No NVRAM, ID 7, Fast-20, SE, parity checking [ 165.319227] sym1: SCSI BUS has been reset. [ 165.367281] scsi host1: sym-2.2.3 [...] [ 388.835999] INFO: task swapper/0:1 blocked for more than 120 seconds. [ 388.912181] Not tainted 3.17.0-rc1 #46 [ 388.963187] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 389.056953] swapper/0 D 00483958 7584 1 0 0x2000100 [ 389.148575] Call Trace: [ 389.177747] [0082e5fc] schedule+0x1c/0x80 [ 389.235024] [00483958] async_synchronize_cookie_domain+0x58/0x100 [ 389.317301] [00483a28] async_synchronize_full+0x8/0x20 [ 389.388133] [006ebe04] wait_for_device_probe+0x64/0x80 [ 389.458938] [009dcffc] prepare_namespace+0x4/0x1b8 [ 389.525590] [009dcbac] kernel_init_freeable+0x1c0/0x1d8 [ 389.597450] [008298e4] kernel_init+0x4/0x100 [ 389.657868] [004060c4] ret_from_fork+0x1c/0x2c [ 389.720324] [] (null) [ 389.775518] no locks held by swapper/0/1. -- Meelis Roos (mr...@linux.ee) -- 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 v3] uas: replace WARN_ON_ONCE() with lockdep_assert_held()
Thanks for letting me know. Sanjeev Sharma -Original Message- From: gre...@linuxfoundation.org [mailto:gre...@linuxfoundation.org] Sent: Tuesday, August 19, 2014 3:01 PM To: Sharma, Sanjeev Cc: kra...@redhat.com; mdharm-...@one-eyed-alien.net; linux-...@vger.kernel.org; linux-ker...@vger.kernel.org; linux-scsi@vger.kernel.org; Hans de Goede Subject: Re: [PATCH v3] uas: replace WARN_ON_ONCE() with lockdep_assert_held() On Tue, Aug 19, 2014 at 06:33:04AM +, Sharma, Sanjeev wrote: > Hi Greg, > > Any feedback on this patch ? The merge window ended 2 days ago, _and_ I'm at the kernel summit this week, _and_ my queue is currently sitting at: $ mdfrm -c ~/mail/todo/ 1317 messages in /home/gregkh/mail/todo/ So please be patient. I'll get to it in a few weeks. greg k-h -- 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 v3] uas: replace WARN_ON_ONCE() with lockdep_assert_held()
On Tue, Aug 19, 2014 at 06:33:04AM +, Sharma, Sanjeev wrote: > Hi Greg, > > Any feedback on this patch ? The merge window ended 2 days ago, _and_ I'm at the kernel summit this week, _and_ my queue is currently sitting at: $ mdfrm -c ~/mail/todo/ 1317 messages in /home/gregkh/mail/todo/ So please be patient. I'll get to it in a few weeks. greg k-h -- 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 v3 17/17] arcmsr: modify calling scsi_scan_host after all initialization done
From: Ching Huang
Modify calling scsi_scan_host until all initialization done.
And fix error path of free allocation resource.
Signed-off-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 2014-08-14 18:38:46.0 +0800
+++ b/drivers/scsi/arcmsr/arcmsr_hba.c 2014-08-14 17:43:04.0 +0800
@@ -112,6 +112,7 @@ static void arcmsr_hbaD_message_isr(stru
static void arcmsr_hardware_reset(struct AdapterControlBlock *acb);
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 int arcmsr_adjust_disk_queue_depth(struct scsi_device *sdev,
int queue_depth, int reason)
{
@@ -730,12 +731,11 @@ static int arcmsr_probe(struct pci_dev *
}
error = scsi_add_host(host, &pdev->dev);
if(error){
- goto RAID_controller_stop;
+ goto free_ccb_pool;
}
if (arcmsr_request_irq(pdev, acb) == FAILED)
goto scsi_host_remove;
arcmsr_iop_init(acb);
- scsi_scan_host(host);
INIT_WORK(&acb->arcmsr_do_message_isr_bh, arcmsr_message_isr_bh_fn);
atomic_set(&acb->rq_map_token, 16);
atomic_set(&acb->ante_token_value, 16);
@@ -747,13 +747,17 @@ static int arcmsr_probe(struct pci_dev *
add_timer(&acb->eternal_timer);
if(arcmsr_alloc_sysfs_attr(acb))
goto out_free_sysfs;
+ scsi_scan_host(host);
return 0;
out_free_sysfs:
-scsi_host_remove:
- scsi_remove_host(host);
-RAID_controller_stop:
+ del_timer_sync(&acb->eternal_timer);
+ flush_work(&acb->arcmsr_do_message_isr_bh);
arcmsr_stop_adapter_bgrb(acb);
arcmsr_flush_adapter_cache(acb);
+ arcmsr_free_irq(pdev, acb);
+scsi_host_remove:
+ scsi_remove_host(host);
+free_ccb_pool:
arcmsr_free_ccb_pool(acb);
free_hbb_mu:
arcmsr_free_mu(acb);
--
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 v3 16/17] arcmsr: support new adapter ARC12x4 series
From: Ching Huang
Add code for supporting Areca new Raid adapter ARC12x4 series.
Signed-off-by: Ching Huang
---
diff -uprN a/drivers/scsi/arcmsr/arcmsr.h b/drivers/scsi/arcmsr/arcmsr.h
--- a/drivers/scsi/arcmsr/arcmsr.h 2014-05-06 15:29:54.0 +0800
+++ b/drivers/scsi/arcmsr/arcmsr.h 2014-05-06 15:06:04.0 +0800
@@ -63,12 +63,17 @@ struct device_attribute;
#define ARCMSR_MAX_QBUFFER
4096
#define ARCMSR_DEFAULT_SG_ENTRIES
38
#define ARCMSR_MAX_HBB_POSTQUEUE
264
+#define ARCMSR_MAX_ARC1214_POSTQUEUE 256
+#define ARCMSR_MAX_ARC1214_DONEQUEUE 257
#define ARCMSR_MAX_XFER_LEN
0x26000 /* 152K */
#define ARCMSR_CDB_SG_PAGE_LENGTH
256
#define ARCMST_NUM_MSIX_VECTORS4
#ifndef PCI_DEVICE_ID_ARECA_1880
#define PCI_DEVICE_ID_ARECA_1880 0x1880
#endif
+#ifndef PCI_DEVICE_ID_ARECA_1214
+ #define PCI_DEVICE_ID_ARECA_12140x1214
+#endif
/*
**
**
@@ -339,6 +344,56 @@ struct FIRMWARE_INFO
#define ARCMSR_HBCMU_MESSAGE_FIRMWARE_OK 0x8000
/*
***
+**SPEC. for Areca Type D adapter
+***
+*/
+#define ARCMSR_ARC1214_CHIP_ID 0x4
+#define ARCMSR_ARC1214_CPU_MEMORY_CONFIGURATION0x8
+#define ARCMSR_ARC1214_I2_HOST_INTERRUPT_MASK 0x00034
+#define ARCMSR_ARC1214_SAMPLE_RESET0x00100
+#define ARCMSR_ARC1214_RESET_REQUEST 0x00108
+#define ARCMSR_ARC1214_MAIN_INTERRUPT_STATUS 0x00200
+#define ARCMSR_ARC1214_PCIE_F0_INTERRUPT_ENABLE0x0020C
+#define ARCMSR_ARC1214_INBOUND_MESSAGE00x00400
+#define ARCMSR_ARC1214_INBOUND_MESSAGE10x00404
+#define ARCMSR_ARC1214_OUTBOUND_MESSAGE0 0x00420
+#define ARCMSR_ARC1214_OUTBOUND_MESSAGE1 0x00424
+#define ARCMSR_ARC1214_INBOUND_DOORBELL0x00460
+#define ARCMSR_ARC1214_OUTBOUND_DOORBELL 0x00480
+#define ARCMSR_ARC1214_OUTBOUND_DOORBELL_ENABLE0x00484
+#define ARCMSR_ARC1214_INBOUND_LIST_BASE_LOW 0x01000
+#define ARCMSR_ARC1214_INBOUND_LIST_BASE_HIGH 0x01004
+#define ARCMSR_ARC1214_INBOUND_LIST_WRITE_POINTER 0x01018
+#define ARCMSR_ARC1214_OUTBOUND_LIST_BASE_LOW 0x01060
+#define ARCMSR_ARC1214_OUTBOUND_LIST_BASE_HIGH 0x01064
+#define ARCMSR_ARC1214_OUTBOUND_LIST_COPY_POINTER 0x0106C
+#define ARCMSR_ARC1214_OUTBOUND_LIST_READ_POINTER 0x01070
+#define ARCMSR_ARC1214_OUTBOUND_INTERRUPT_CAUSE0x01088
+#define ARCMSR_ARC1214_OUTBOUND_INTERRUPT_ENABLE 0x0108C
+#define ARCMSR_ARC1214_MESSAGE_WBUFFER 0x02000
+#define ARCMSR_ARC1214_MESSAGE_RBUFFER 0x02100
+#define ARCMSR_ARC1214_MESSAGE_RWBUFFER0x02200
+/* Host Interrupt Mask */
+#define ARCMSR_ARC1214_ALL_INT_ENABLE 0x1010
+#define ARCMSR_ARC1214_ALL_INT_DISABLE 0x
+/* Host Interrupt Status */
+#define ARCMSR_ARC1214_OUTBOUND_DOORBELL_ISR 0x1000
+#define ARCMSR_ARC1214_OUTBOUND_POSTQUEUE_ISR 0x0010
+/* DoorBell*/
+#define ARCMSR_ARC1214_DRV2IOP_DATA_IN_READY 0x0001
+#define ARCMSR_ARC1214_DRV2IOP_DATA_OUT_READ 0x0002
+/*inbound message 0 ready*/
+#define ARCMSR_ARC1214_IOP2DRV_DATA_WRITE_OK 0x0001
+/*outbound DATA WRITE isr door bell clear*/
+#define ARCMSR_ARC1214_IOP2DRV_DATA_READ_OK0x0002
+/*outbound message 0 ready*/
+#define ARCMSR_ARC1214_IOP2DRV_MESSAGE_CMD_DONE0x0200
+/*outbound message cmd isr door bell clear*/
+/*ARCMSR_HBAMU_MESSAGE_FIRMWARE_OK*/
+#define ARCMSR_ARC1214_MESSAGE_FIRMWARE_OK 0x8000
+#define ARCMSR_ARC1214_OUTBOUND_LIST_INTERRUPT_CLEAR 0x0001
+/*
+***
**ARECA SCSI COMMAND DESCRIPTOR BLOCK size 0x1F8 (504)
***
*/
@@ -496,6 +551,55 @@ struct MessageUnit_C{
uint32_tmsgcode_rwbuffer[256]; /*2200 23FF*/
};
/*
+*
+** Messaging Unit (MU) of Type D processor
+*
+*/
+struct InBound_SRB {
+ uint32_t addressLow; /* pointer to SRB block */
+ uint32_t addressHigh;
+ uint32_t length; /* i
[PATCH v3 15/17] arcmsr: modify some character string
From: Ching Huang
Revise comment and some character strings.
Signed-off-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 2014-08-14 18:41:02.0 +0800
+++ b/drivers/scsi/arcmsr/arcmsr_hba.c 2014-08-14 18:41:12.0 +0800
@@ -2,11 +2,10 @@
***
**O.S : Linux
** FILE NAME : arcmsr_hba.c
-**BY: Nick Cheng
-** Description: SCSI RAID Device Driver for
-**ARECA RAID Host adapter
+**BY: Nick Cheng, C.L. Huang
+** Description: SCSI RAID Device Driver for Areca RAID Controller
***
-** Copyright (C) 2002 - 2005, Areca Technology Corporation All rights reserved
+** Copyright (C) 2002 - 2014, Areca Technology Corporation All rights reserved
**
** Web site: www.areca.com.tw
** E-mail: supp...@areca.com.tw
@@ -70,8 +69,8 @@
#include
#include
#include "arcmsr.h"
-MODULE_AUTHOR("Nick Cheng ");
-MODULE_DESCRIPTION("ARECA (ARC11xx/12xx/16xx/1880) SATA/SAS RAID Host Bus
Adapter");
+MODULE_AUTHOR("Nick Cheng, C.L. Huang ");
+MODULE_DESCRIPTION("Areca ARC11xx/12xx/16xx/188x SAS/SATA RAID Controller
Driver");
MODULE_LICENSE("Dual BSD/GPL");
MODULE_VERSION(ARCMSR_DRIVER_VERSION);
@@ -126,8 +125,7 @@ static int arcmsr_adjust_disk_queue_dept
static struct scsi_host_template arcmsr_scsi_host_template = {
.module = THIS_MODULE,
- .name = "ARCMSR ARECA SATA/SAS RAID Controller"
- ARCMSR_DRIVER_VERSION,
+ .name = "Areca SAS/SATA RAID driver",
.info = arcmsr_info,
.queuecommand = arcmsr_queue_command,
.eh_abort_handler = arcmsr_abort,
@@ -3355,14 +3353,14 @@ static const char *arcmsr_info(struct Sc
case PCI_DEVICE_ID_ARECA_1680:
case PCI_DEVICE_ID_ARECA_1681:
case PCI_DEVICE_ID_ARECA_1880:
- type = "SAS";
+ type = "SAS/SATA";
break;
default:
- type = "X-TYPE";
+ type = "unknown";
+ raid6 = 0;
break;
}
- sprintf(buf, "Areca %s Host Adapter RAID Controller%s\n %s",
- type, raid6 ? "( RAID6 capable)" : "",
- ARCMSR_DRIVER_VERSION);
+ sprintf(buf, "Areca %s RAID Controller %s\narcmsr version %s\n",
+ type, raid6 ? "(RAID6 capable)" : "", ARCMSR_DRIVER_VERSION);
return buf;
}
--
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 v3 14/17] arcmsr: fix sparse warning and error
From: Ching Huang
Fix sparse utility checking error and warning.
Signed-off-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 2014-08-14 18:40:48.0 +0800
+++ b/drivers/scsi/arcmsr/arcmsr_hba.c 2014-08-14 18:41:02.0 +0800
@@ -78,7 +78,7 @@ MODULE_VERSION(ARCMSR_DRIVER_VERSION);
#defineARCMSR_SLEEPTIME10
#defineARCMSR_RETRYCOUNT 12
-wait_queue_head_t wait_q;
+static wait_queue_head_t wait_q;
static int arcmsr_iop_message_xfer(struct AdapterControlBlock *acb,
struct scsi_cmnd *cmd);
static int arcmsr_iop_confirm(struct AdapterControlBlock *acb);
@@ -332,7 +332,7 @@ static uint8_t arcmsr_hbaB_wait_msgint_r
static uint8_t arcmsr_hbaC_wait_msgint_ready(struct AdapterControlBlock *pACB)
{
- struct MessageUnit_C *phbcmu = (struct MessageUnit_C *)pACB->pmuC;
+ struct MessageUnit_C __iomem *phbcmu = pACB->pmuC;
int i;
for (i = 0; i < 2000; i++) {
@@ -382,7 +382,7 @@ static void arcmsr_hbaB_flush_cache(stru
static void arcmsr_hbaC_flush_cache(struct AdapterControlBlock *pACB)
{
- struct MessageUnit_C *reg = (struct MessageUnit_C *)pACB->pmuC;
+ struct MessageUnit_C __iomem *reg = pACB->pmuC;
int retry_count = 30;/* enlarge wait flush adapter cache time: 10
minute */
writel(ARCMSR_INBOUND_MESG0_FLUSH_CACHE, ®->inbound_msgaddr0);
writel(ARCMSR_HBCMU_DRV2IOP_MESSAGE_CMD_DONE, ®->inbound_doorbell);
@@ -800,7 +800,7 @@ static uint8_t arcmsr_hbaB_abort_allcmd(
}
static uint8_t arcmsr_hbaC_abort_allcmd(struct AdapterControlBlock *pACB)
{
- struct MessageUnit_C *reg = (struct MessageUnit_C *)pACB->pmuC;
+ struct MessageUnit_C __iomem *reg = pACB->pmuC;
writel(ARCMSR_INBOUND_MESG0_ABORT_CMD, ®->inbound_msgaddr0);
writel(ARCMSR_HBCMU_DRV2IOP_MESSAGE_CMD_DONE, ®->inbound_doorbell);
if (!arcmsr_hbaC_wait_msgint_ready(pACB)) {
@@ -888,7 +888,7 @@ static u32 arcmsr_disable_outbound_ints(
}
break;
case ACB_ADAPTER_TYPE_C:{
- struct MessageUnit_C *reg = (struct MessageUnit_C *)acb->pmuC;
+ struct MessageUnit_C __iomem *reg = acb->pmuC;
/* disable all outbound interrupt */
orig_mask = readl(®->host_int_mask); /* disable outbound
message0 int */
writel(orig_mask|ARCMSR_HBCMU_ALL_INTMASKENABLE,
®->host_int_mask);
@@ -1012,8 +1012,9 @@ static void arcmsr_done4abort_postqueue(
/*clear all outbound posted Q*/
writel(ARCMSR_DOORBELL_INT_CLEAR_PATTERN,
reg->iop2drv_doorbell); /* clear doorbell interrupt */
for (i = 0; i < ARCMSR_MAX_HBB_POSTQUEUE; i++) {
- if ((flag_ccb = readl(®->done_qbuffer[i])) != 0) {
- writel(0, ®->done_qbuffer[i]);
+ flag_ccb = reg->done_qbuffer[i];
+ if (flag_ccb != 0) {
+ reg->done_qbuffer[i] = 0;
pARCMSR_CDB = (struct ARCMSR_CDB
*)(acb->vir2phy_offset+(flag_ccb << 5));/*frame must be 32 bytes aligned*/
pCCB = container_of(pARCMSR_CDB, struct
CommandControlBlock, arcmsr_cdb);
error = (flag_ccb &
ARCMSR_CCBREPLY_FLAG_ERROR_MODE0) ? true : false;
@@ -1026,7 +1027,7 @@ static void arcmsr_done4abort_postqueue(
}
break;
case ACB_ADAPTER_TYPE_C: {
- struct MessageUnit_C *reg = acb->pmuC;
+ struct MessageUnit_C __iomem *reg = acb->pmuC;
struct ARCMSR_CDB *pARCMSR_CDB;
uint32_t flag_ccb, ccb_cdb_phy;
bool error;
@@ -1144,7 +1145,7 @@ static void arcmsr_enable_outbound_ints(
}
break;
case ACB_ADAPTER_TYPE_C: {
- struct MessageUnit_C *reg = acb->pmuC;
+ struct MessageUnit_C __iomem *reg = acb->pmuC;
mask = ~(ARCMSR_HBCMU_UTILITY_A_ISR_MASK |
ARCMSR_HBCMU_OUTBOUND_DOORBELL_ISR_MASK|ARCMSR_HBCMU_OUTBOUND_POSTQUEUE_ISR_MASK);
writel(intmask_org & mask, ®->host_int_mask);
acb->outbound_int_enable = ~(intmask_org & mask) & 0x000f;
@@ -1231,12 +1232,12 @@ static void arcmsr_post_ccb(struct Adapt
uint32_t ending_index, index = reg->postq_index;
ending_index = ((index + 1) % ARCMSR_MAX_HBB_POSTQUEUE);
- writel(0, ®->post_qbuffer[ending_index]);
+ reg->post_qbuffer[ending_index] = 0;
if (arcmsr_cdb->Flags & ARCMSR_CDB_FLAG_SGL_BSIZE) {
- writel(cdb_phyaddr | ARCMSR_CCBPOST_FLAG_SGL_BSIZE,\
-®->post_qbuffer[index]);
+ reg->post_qbuffer[index] =
+
[PATCH v3 13/17] arcmsr: fix ioctl data read/write error for adapter type C
From: Ching Huang
Rewrite ioctl entry and its relate function.
This patch fix ioctl data read/write error and change data I/O access from byte
to Dword.
Signed-off-by: Ching Huang
---
diff -uprN a/drivers/scsi/arcmsr/arcmsr_attr.c
b/drivers/scsi/arcmsr/arcmsr_attr.c
--- a/drivers/scsi/arcmsr/arcmsr_attr.c 2014-02-06 17:47:24.0 +0800
+++ b/drivers/scsi/arcmsr/arcmsr_attr.c 2014-04-29 17:10:42.0 +0800
@@ -70,40 +70,75 @@ static ssize_t arcmsr_sysfs_iop_message_
struct AdapterControlBlock *acb = (struct AdapterControlBlock *)
host->hostdata;
uint8_t *pQbuffer,*ptmpQbuffer;
int32_t allxfer_len = 0;
+ unsigned long flags;
if (!capable(CAP_SYS_ADMIN))
return -EACCES;
/* do message unit read. */
ptmpQbuffer = (uint8_t *)buf;
- while ((acb->rqbuf_firstindex != acb->rqbuf_lastindex)
- && (allxfer_len < 1031)) {
+ spin_lock_irqsave(&acb->rqbuffer_lock, flags);
+ if (acb->rqbuf_firstindex != acb->rqbuf_lastindex) {
pQbuffer = &acb->rqbuffer[acb->rqbuf_firstindex];
- memcpy(ptmpQbuffer, pQbuffer, 1);
- acb->rqbuf_firstindex++;
- acb->rqbuf_firstindex %= ARCMSR_MAX_QBUFFER;
- ptmpQbuffer++;
- allxfer_len++;
+ if (acb->rqbuf_firstindex > acb->rqbuf_lastindex) {
+ if ((ARCMSR_MAX_QBUFFER - acb->rqbuf_firstindex) >=
1032) {
+ memcpy(ptmpQbuffer, pQbuffer, 1032);
+ acb->rqbuf_firstindex += 1032;
+ acb->rqbuf_firstindex %= ARCMSR_MAX_QBUFFER;
+ allxfer_len = 1032;
+ } else {
+ if (((ARCMSR_MAX_QBUFFER -
acb->rqbuf_firstindex)
+ + acb->rqbuf_lastindex) > 1032) {
+ memcpy(ptmpQbuffer, pQbuffer,
+ ARCMSR_MAX_QBUFFER
+ - acb->rqbuf_firstindex);
+ ptmpQbuffer += ARCMSR_MAX_QBUFFER
+ - acb->rqbuf_firstindex;
+ memcpy(ptmpQbuffer, acb->rqbuffer, 1032
+ - (ARCMSR_MAX_QBUFFER -
+ acb->rqbuf_firstindex));
+ acb->rqbuf_firstindex = 1032 -
+ (ARCMSR_MAX_QBUFFER -
+ acb->rqbuf_firstindex);
+ allxfer_len = 1032;
+ } else {
+ memcpy(ptmpQbuffer, pQbuffer,
+ ARCMSR_MAX_QBUFFER -
+ acb->rqbuf_firstindex);
+ ptmpQbuffer += ARCMSR_MAX_QBUFFER -
+ acb->rqbuf_firstindex;
+ memcpy(ptmpQbuffer, acb->rqbuffer,
+ acb->rqbuf_lastindex);
+ allxfer_len = ARCMSR_MAX_QBUFFER -
+ acb->rqbuf_firstindex +
+ acb->rqbuf_lastindex;
+ acb->rqbuf_firstindex =
+ acb->rqbuf_lastindex;
+ }
+ }
+ } else {
+ if ((acb->rqbuf_lastindex - acb->rqbuf_firstindex) >
1032) {
+ memcpy(ptmpQbuffer, pQbuffer, 1032);
+ acb->rqbuf_firstindex += 1032;
+ allxfer_len = 1032;
+ } else {
+ memcpy(ptmpQbuffer, pQbuffer,
acb->rqbuf_lastindex
+ - acb->rqbuf_firstindex);
+ allxfer_len = acb->rqbuf_lastindex -
+ acb->rqbuf_firstindex;
+ acb->rqbuf_firstindex = acb->rqbuf_lastindex;
+ }
+ }
}
if (acb->acb_flags & ACB_F_IOPDATA_OVERFLOW) {
struct QBUFFER __iomem *prbuffer;
- uint8_t __iomem *iop_data;
- int32_t iop_len;
-
acb->acb_flags &= ~ACB_F_IOPDATA_OVERFLOW;
prbuffer = arcmsr_get_iop_rqbuffer(acb);
- iop_data = prbuffer->data;
- iop_len = readl(&prbuffer->data_len);
- while (iop_len > 0) {
- acb->rqbuffer[acb->rqbuf_lastindex] = readb(iop_data);
[PATCH v3 12/17] arcmsr: revise allocation of second dma_coherent_handle for type B
From: Ching Huang
This modification is for consistency with upcoming adapter type D.
Both adapter type B and D have similar H/W and S/W structure.
Signed-off-by: Ching Huang
---
diff -uprN a/drivers/scsi/arcmsr/arcmsr.h b/drivers/scsi/arcmsr/arcmsr.h
--- a/drivers/scsi/arcmsr/arcmsr.h 2014-05-06 15:27:38.0 +0800
+++ b/drivers/scsi/arcmsr/arcmsr.h 2014-05-06 15:28:38.0 +0800
@@ -507,6 +507,7 @@ struct AdapterControlBlock
#define ACB_ADAPTER_TYPE_B0x0002/* hbb M IOP */
#define ACB_ADAPTER_TYPE_C0x0004/* hbc P IOP */
#define ACB_ADAPTER_TYPE_D0x0008/* hbd A IOP */
+ u32 roundup_ccbsize;
struct pci_dev *pdev;
struct Scsi_Host * host;
unsigned long vir2phy_offset;
@@ -563,6 +564,7 @@ struct AdapterControlBlock
dma_addr_t dma_coherent_handle;
/* dma_coherent_handle used for memory free */
dma_addr_t dma_coherent_handle2;
+ void*dma_coherent2;
unsigned intuncache_size;
uint8_t rqbuffer[ARCMSR_MAX_QBUFFER];
/* data collection buffer for read from 80331 */
diff -uprN a/drivers/scsi/arcmsr/arcmsr_hba.c b/drivers/scsi/arcmsr/arcmsr_hba.c
--- a/drivers/scsi/arcmsr/arcmsr_hba.c 2014-08-14 18:40:26.0 +0800
+++ b/drivers/scsi/arcmsr/arcmsr_hba.c 2014-08-14 18:40:38.0 +0800
@@ -183,13 +183,10 @@ static struct pci_driver arcmsr_pci_driv
static void arcmsr_free_mu(struct AdapterControlBlock *acb)
{
switch (acb->adapter_type) {
- case ACB_ADAPTER_TYPE_A:
- case ACB_ADAPTER_TYPE_C:
- break;
case ACB_ADAPTER_TYPE_B:{
- dma_free_coherent(&acb->pdev->dev,
- sizeof(struct MessageUnit_B),
- acb->pmuB, acb->dma_coherent_handle2);
+ dma_free_coherent(&acb->pdev->dev, acb->roundup_ccbsize,
+ acb->dma_coherent2, acb->dma_coherent_handle2);
+ break;
}
}
}
@@ -2210,12 +2207,15 @@ static bool arcmsr_hbaB_get_config(struc
char __iomem *iop_device_map;
/*firm_version,21,84-99*/
int count;
- dma_coherent = dma_alloc_coherent(&pdev->dev, sizeof(struct
MessageUnit_B), &dma_coherent_handle, GFP_KERNEL);
+
+ acb->roundup_ccbsize = roundup(sizeof(struct MessageUnit_B), 32);
+ dma_coherent = dma_alloc_coherent(&pdev->dev, acb->roundup_ccbsize,
&dma_coherent_handle, GFP_KERNEL);
if (!dma_coherent){
printk(KERN_NOTICE "arcmsr%d: dma_alloc_coherent got error for
hbb mu\n", acb->host->host_no);
return false;
}
acb->dma_coherent_handle2 = dma_coherent_handle;
+ 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);
@@ -2562,6 +2562,7 @@ static int arcmsr_polling_ccbdone(struct
static int arcmsr_iop_confirm(struct AdapterControlBlock *acb)
{
uint32_t cdb_phyaddr, cdb_phyaddr_hi32;
+ dma_addr_t dma_coherent_handle;
/*
@@ -2569,8 +2570,16 @@ static int arcmsr_iop_confirm(struct Ada
** if freeccb.HighPart is not zero
*/
- cdb_phyaddr = lower_32_bits(acb->dma_coherent_handle);
- cdb_phyaddr_hi32 = upper_32_bits(acb->dma_coherent_handle);
+ switch (acb->adapter_type) {
+ case ACB_ADAPTER_TYPE_B:
+ dma_coherent_handle = acb->dma_coherent_handle2;
+ break;
+ default:
+ dma_coherent_handle = acb->dma_coherent_handle;
+ break;
+ }
+ cdb_phyaddr = lower_32_bits(dma_coherent_handle);
+ cdb_phyaddr_hi32 = upper_32_bits(dma_coherent_handle);
acb->cdb_phyaddr_hi32 = cdb_phyaddr_hi32;
/*
***
@@ -2598,7 +2607,6 @@ static int arcmsr_iop_confirm(struct Ada
break;
case ACB_ADAPTER_TYPE_B: {
- unsigned long post_queue_phyaddr;
uint32_t __iomem *rwbuffer;
struct MessageUnit_B *reg = acb->pmuB;
@@ -2610,16 +2618,15 @@ static int arcmsr_iop_confirm(struct Ada
acb->host->host_no);
return 1;
}
- post_queue_phyaddr = acb->dma_coherent_handle2;
rwbuffer = reg->message_rwbuffer;
/* driver "set confi
[PATCH v3 11/17] arcmsr: rename function and variable
From: Ching Huang
Rename some variable and function name for readability and consistency.
Signed-off-by: Ching Huang
---
diff -uprN a/drivers/scsi/arcmsr/arcmsr.h b/drivers/scsi/arcmsr/arcmsr.h
--- a/drivers/scsi/arcmsr/arcmsr.h 2014-05-06 15:27:14.0 +0800
+++ b/drivers/scsi/arcmsr/arcmsr.h 2014-05-06 15:27:38.0 +0800
@@ -359,7 +359,7 @@ struct ARCMSR_CDB
#define ARCMSR_CDB_FLAG_ORDEREDQ 0x10
uint8_t msgPages;
- uint32_tContext;
+ uint32_tmsgContext;
uint32_tDataLength;
uint8_t Cdb[16];
uint8_t DeviceStatus;
@@ -562,7 +562,7 @@ struct AdapterControlBlock
/* dma_coherent used for memory free */
dma_addr_t dma_coherent_handle;
/* dma_coherent_handle used for memory free */
- dma_addr_t dma_coherent_handle_hbb_mu;
+ dma_addr_t dma_coherent_handle2;
unsigned intuncache_size;
uint8_t rqbuffer[ARCMSR_MAX_QBUFFER];
/* data collection buffer for read from 80331 */
@@ -613,7 +613,7 @@ struct CommandControlBlock{
struct list_headlist; /*x32:
8byte, x64: 16byte*/
struct scsi_cmnd*pcmd; /*8
bytes pointer of linux scsi command */
struct AdapterControlBlock *acb; /*x32:
4byte, x64: 8byte*/
- uint32_tcdb_phyaddr_pattern;/*x32:
4byte, x64: 4byte*/
+ uint32_tcdb_phyaddr;/*x32:
4byte, x64: 4byte*/
uint32_tarc_cdb_size;
/*x32:4byte,x64:4byte*/
uint16_tccb_flags; /*x32:
2byte, x64: 2byte*/
#define CCB_FLAG_READ 0x
diff -uprN a/drivers/scsi/arcmsr/arcmsr_hba.c b/drivers/scsi/arcmsr/arcmsr_hba.c
--- a/drivers/scsi/arcmsr/arcmsr_hba.c 2014-08-14 18:40:12.0 +0800
+++ b/drivers/scsi/arcmsr/arcmsr_hba.c 2014-08-14 18:40:26.0 +0800
@@ -99,16 +99,16 @@ static u32 arcmsr_disable_outbound_ints(
static void arcmsr_enable_outbound_ints(struct AdapterControlBlock *acb,
u32 intmask_org);
static void arcmsr_stop_adapter_bgrb(struct AdapterControlBlock *acb);
-static void arcmsr_flush_hba_cache(struct AdapterControlBlock *acb);
-static void arcmsr_flush_hbb_cache(struct AdapterControlBlock *acb);
+static void arcmsr_hbaA_flush_cache(struct AdapterControlBlock *acb);
+static void arcmsr_hbaB_flush_cache(struct AdapterControlBlock *acb);
static void arcmsr_request_device_map(unsigned long pacb);
-static void arcmsr_request_hba_device_map(struct AdapterControlBlock *acb);
-static void arcmsr_request_hbb_device_map(struct AdapterControlBlock *acb);
-static void arcmsr_request_hbc_device_map(struct AdapterControlBlock *acb);
+static void arcmsr_hbaA_request_device_map(struct AdapterControlBlock *acb);
+static void arcmsr_hbaB_request_device_map(struct AdapterControlBlock *acb);
+static void arcmsr_hbaC_request_device_map(struct AdapterControlBlock *acb);
static void arcmsr_message_isr_bh_fn(struct work_struct *work);
static bool arcmsr_get_firmware_spec(struct AdapterControlBlock *acb);
static void arcmsr_start_adapter_bgrb(struct AdapterControlBlock *acb);
-static void arcmsr_hbc_message_isr(struct AdapterControlBlock *pACB);
+static void arcmsr_hbaC_message_isr(struct AdapterControlBlock *pACB);
static void arcmsr_hardware_reset(struct AdapterControlBlock *acb);
static const char *arcmsr_info(struct Scsi_Host *);
static irqreturn_t arcmsr_interrupt(struct AdapterControlBlock *acb);
@@ -180,7 +180,7 @@ static struct pci_driver arcmsr_pci_driv
*/
-static void arcmsr_free_hbb_mu(struct AdapterControlBlock *acb)
+static void arcmsr_free_mu(struct AdapterControlBlock *acb)
{
switch (acb->adapter_type) {
case ACB_ADAPTER_TYPE_A:
@@ -189,7 +189,7 @@ static void arcmsr_free_hbb_mu(struct Ad
case ACB_ADAPTER_TYPE_B:{
dma_free_coherent(&acb->pdev->dev,
sizeof(struct MessageUnit_B),
- acb->pmuB, acb->dma_coherent_handle_hbb_mu);
+ acb->pmuB, acb->dma_coherent_handle2);
}
}
}
@@ -295,7 +295,7 @@ static int arcmsr_bios_param(struct scsi
return 0;
}
-static uint8_t arcmsr_hba_wait_msgint_ready(struct AdapterControlBlock *acb)
+static uint8_t arcmsr_hbaA_wait_msgint_ready(stru
[PATCH v3 10/17] arcmsr: clear outbound doorbell buffer completely
From: Ching Huang
Clear outbound doorbell buffer completely for adapter type C.
This is to prevent getting bad data input from IOP before ioctl command
beginning.
Signed-off-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 2014-08-14 18:40:00.0 +0800
+++ b/drivers/scsi/arcmsr/arcmsr_hba.c 2014-08-14 18:40:12.0 +0800
@@ -2845,11 +2845,23 @@ static void arcmsr_clear_doorbell_queue_
break;
case ACB_ADAPTER_TYPE_C: {
struct MessageUnit_C *reg = (struct MessageUnit_C *)acb->pmuC;
- uint32_t outbound_doorbell;
+ uint32_t outbound_doorbell, i;
/* empty doorbell Qbuffer if door bell ringed */
outbound_doorbell = readl(®->outbound_doorbell);
writel(outbound_doorbell, ®->outbound_doorbell_clear);
writel(ARCMSR_HBCMU_DRV2IOP_DATA_READ_OK,
®->inbound_doorbell);
+ for (i = 0; i < 200; i++) {
+ msleep(20);
+ outbound_doorbell = readl(®->outbound_doorbell);
+ if (outbound_doorbell &
+ ARCMSR_HBCMU_IOP2DRV_DATA_WRITE_OK) {
+ writel(outbound_doorbell,
+ ®->outbound_doorbell_clear);
+ writel(ARCMSR_HBCMU_DRV2IOP_DATA_READ_OK,
+ ®->inbound_doorbell);
+ } else
+ break;
+ }
}
}
}
@@ -3077,9 +3089,7 @@ sleep:
arcmsr_get_firmware_spec(acb);
arcmsr_start_adapter_bgrb(acb);
/* clear Qbuffer if door bell ringed */
- outbound_doorbell =
readl(®->outbound_doorbell);
- writel(outbound_doorbell,
®->outbound_doorbell_clear); /*clear interrupt */
- writel(ARCMSR_HBCMU_DRV2IOP_DATA_READ_OK,
®->inbound_doorbell);
+ arcmsr_clear_doorbell_queue_buffer(acb);
/* enable outbound Post Queue,outbound doorbell
Interrupt */
arcmsr_enable_outbound_ints(acb, intmask_org);
atomic_set(&acb->rq_map_token, 16);
--
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 v3 9/17] arcmsr: modify printing adapter model number and F/W messages
From: Ching Huang
Adjust printing order of adapter model name and firmware version.
Signed-off-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 2014-08-14 18:39:48.0 +0800
+++ b/drivers/scsi/arcmsr/arcmsr_hba.c 2014-08-14 18:40:00.0 +0800
@@ -2182,10 +2182,10 @@ static bool arcmsr_get_hba_config(struct
iop_device_map++;
count--;
}
- printk(KERN_NOTICE "Areca RAID Controller%d: F/W %s & Model %s\n",
+ pr_notice("Areca RAID Controller%d: Model %s, F/W %s\n",
acb->host->host_no,
- acb->firm_version,
- acb->firm_model);
+ acb->firm_model,
+ acb->firm_version);
acb->signature = readl(®->message_rwbuffer[0]);
acb->firm_request_len = readl(®->message_rwbuffer[1]);
acb->firm_numbers_queue = readl(®->message_rwbuffer[2]);
@@ -2258,10 +2258,10 @@ static bool arcmsr_get_hbb_config(struct
count--;
}
- printk(KERN_NOTICE "Areca RAID Controller%d: F/W %s & Model %s\n",
+ pr_notice("Areca RAID Controller%d: Model %s, F/W %s\n",
acb->host->host_no,
- acb->firm_version,
- acb->firm_model);
+ acb->firm_model,
+ acb->firm_version);
acb->signature = readl(®->message_rwbuffer[1]);
/*firm_signature,1,00-03*/
@@ -2324,10 +2324,10 @@ static bool arcmsr_get_hbc_config(struct
iop_firm_version++;
count--;
}
- printk(KERN_NOTICE "Areca RAID Controller%d: F/W %s & Model %s\n",
+ pr_notice("Areca RAID Controller%d: Model %s, F/W %s\n",
pACB->host->host_no,
- pACB->firm_version,
- pACB->firm_model);
+ pACB->firm_model,
+ pACB->firm_version);
pACB->firm_request_len = readl(®->msgcode_rwbuffer[1]);
/*firm_request_len,1,04-07*/
pACB->firm_numbers_queue = readl(®->msgcode_rwbuffer[2]);
/*firm_numbers_queue,2,08-11*/
pACB->firm_sdram_size = readl(®->msgcode_rwbuffer[3]);
/*firm_sdram_size,3,12-15*/
--
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 v3 8/17] arcmsr: remove calling arcmsr_hbb_enable_driver_mode
From: Ching Huang
Remove calling arcmsr_hbb_enable_driver_mode by in-line code.
Signed-off-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 2014-08-14 18:39:06.0 +0800
+++ b/drivers/scsi/arcmsr/arcmsr_hba.c 2014-08-14 18:39:48.0 +0800
@@ -833,17 +833,6 @@ static uint8_t arcmsr_abort_allcmd(struc
return rtnval;
}
-static bool arcmsr_hbb_enable_driver_mode(struct AdapterControlBlock *pacb)
-{
- struct MessageUnit_B *reg = pacb->pmuB;
- writel(ARCMSR_MESSAGE_START_DRIVER_MODE, reg->drv2iop_doorbell);
- if (!arcmsr_hbb_wait_msgint_ready(pacb)) {
- printk(KERN_ERR "arcmsr%d: can't set driver mode. \n",
pacb->host->host_no);
- return false;
- }
- return true;
-}
-
static void arcmsr_pci_unmap_dma(struct CommandControlBlock *ccb)
{
struct scsi_cmnd *pcmd = ccb->pcmd;
@@ -2640,7 +2629,12 @@ static int arcmsr_iop_confirm(struct Ada
timeout \n",acb->host->host_no);
return 1;
}
- arcmsr_hbb_enable_driver_mode(acb);
+ writel(ARCMSR_MESSAGE_START_DRIVER_MODE, reg->drv2iop_doorbell);
+ if (!arcmsr_hbb_wait_msgint_ready(acb)) {
+ pr_err("arcmsr%d: can't set driver mode.\n",
+ acb->host->host_no);
+ return 1;
+ }
}
break;
case ACB_ADAPTER_TYPE_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
