[PATCH] [SCSI] use module_platform_driver()
Eliminate a bunch of boilerplate code by using module_platform_driver().
Signed-off-by: Christoph Jaeger christophjae...@linux.com
---
drivers/scsi/jazz_esp.c | 13 +
drivers/scsi/mac_esp.c| 13 +
drivers/scsi/qlogicpti.c | 13 +
drivers/scsi/sgiwd93.c| 13 +
drivers/scsi/sni_53c710.c | 13 +
drivers/scsi/sun3x_esp.c | 13 +
drivers/scsi/sun_esp.c| 13 +
7 files changed, 7 insertions(+), 84 deletions(-)
diff --git a/drivers/scsi/jazz_esp.c b/drivers/scsi/jazz_esp.c
index 69efbf1..80f66c9 100644
--- a/drivers/scsi/jazz_esp.c
+++ b/drivers/scsi/jazz_esp.c
@@ -230,20 +230,9 @@ static struct platform_driver esp_jazz_driver = {
},
};
-static int __init jazz_esp_init(void)
-{
- return platform_driver_register(esp_jazz_driver);
-}
-
-static void __exit jazz_esp_exit(void)
-{
- platform_driver_unregister(esp_jazz_driver);
-}
+module_platform_driver(esp_jazz_driver);
MODULE_DESCRIPTION(JAZZ ESP SCSI driver);
MODULE_AUTHOR(Thomas Bogendoerfer (tsbog...@alpha.franken.de));
MODULE_LICENSE(GPL);
MODULE_VERSION(DRV_VERSION);
-
-module_init(jazz_esp_init);
-module_exit(jazz_esp_exit);
diff --git a/drivers/scsi/mac_esp.c b/drivers/scsi/mac_esp.c
index 994fc5c..d7d2d6b 100644
--- a/drivers/scsi/mac_esp.c
+++ b/drivers/scsi/mac_esp.c
@@ -621,21 +621,10 @@ static struct platform_driver esp_mac_driver = {
},
};
-static int __init mac_esp_init(void)
-{
- return platform_driver_register(esp_mac_driver);
-}
-
-static void __exit mac_esp_exit(void)
-{
- platform_driver_unregister(esp_mac_driver);
-}
+module_platform_driver(esp_mac_driver);
MODULE_DESCRIPTION(Mac ESP SCSI driver);
MODULE_AUTHOR(Finn Thain fth...@telegraphics.com.au);
MODULE_LICENSE(GPL v2);
MODULE_VERSION(DRV_VERSION);
MODULE_ALIAS(platform: DRV_MODULE_NAME);
-
-module_init(mac_esp_init);
-module_exit(mac_esp_exit);
diff --git a/drivers/scsi/qlogicpti.c b/drivers/scsi/qlogicpti.c
index 6d48d30..b7643e6 100644
--- a/drivers/scsi/qlogicpti.c
+++ b/drivers/scsi/qlogicpti.c
@@ -1462,21 +1462,10 @@ static struct platform_driver qpti_sbus_driver = {
.remove = qpti_sbus_remove,
};
-static int __init qpti_init(void)
-{
- return platform_driver_register(qpti_sbus_driver);
-}
-
-static void __exit qpti_exit(void)
-{
- platform_driver_unregister(qpti_sbus_driver);
-}
+module_platform_driver(qpti_sbus_driver);
MODULE_DESCRIPTION(QlogicISP SBUS driver);
MODULE_AUTHOR(David S. Miller (da...@davemloft.net));
MODULE_LICENSE(GPL);
MODULE_VERSION(2.1);
MODULE_FIRMWARE(qlogic/isp1000.bin);
-
-module_init(qpti_init);
-module_exit(qpti_exit);
diff --git a/drivers/scsi/sgiwd93.c b/drivers/scsi/sgiwd93.c
index a464d95..11307be 100644
--- a/drivers/scsi/sgiwd93.c
+++ b/drivers/scsi/sgiwd93.c
@@ -319,18 +319,7 @@ static struct platform_driver sgiwd93_driver = {
}
};
-static int __init sgiwd93_module_init(void)
-{
- return platform_driver_register(sgiwd93_driver);
-}
-
-static void __exit sgiwd93_module_exit(void)
-{
- return platform_driver_unregister(sgiwd93_driver);
-}
-
-module_init(sgiwd93_module_init);
-module_exit(sgiwd93_module_exit);
+module_platform_driver(sgiwd93_driver);
MODULE_DESCRIPTION(SGI WD33C93 driver);
MODULE_AUTHOR(Ralf Baechle r...@linux-mips.org);
diff --git a/drivers/scsi/sni_53c710.c b/drivers/scsi/sni_53c710.c
index 52d54e7..5528bae 100644
--- a/drivers/scsi/sni_53c710.c
+++ b/drivers/scsi/sni_53c710.c
@@ -141,15 +141,4 @@ static struct platform_driver snirm710_driver = {
},
};
-static int __init snirm710_init(void)
-{
- return platform_driver_register(snirm710_driver);
-}
-
-static void __exit snirm710_exit(void)
-{
- platform_driver_unregister(snirm710_driver);
-}
-
-module_init(snirm710_init);
-module_exit(snirm710_exit);
+module_platform_driver(snirm710_driver);
diff --git a/drivers/scsi/sun3x_esp.c b/drivers/scsi/sun3x_esp.c
index 534eb96..438da93 100644
--- a/drivers/scsi/sun3x_esp.c
+++ b/drivers/scsi/sun3x_esp.c
@@ -299,21 +299,10 @@ static struct platform_driver esp_sun3x_driver = {
},
};
-static int __init sun3x_esp_init(void)
-{
- return platform_driver_register(esp_sun3x_driver);
-}
-
-static void __exit sun3x_esp_exit(void)
-{
- platform_driver_unregister(esp_sun3x_driver);
-}
+module_platform_driver(esp_sun3x_driver);
MODULE_DESCRIPTION(Sun3x ESP SCSI driver);
MODULE_AUTHOR(Thomas Bogendoerfer (tsbog...@alpha.franken.de));
MODULE_LICENSE(GPL);
MODULE_VERSION(DRV_VERSION);
-
-module_init(sun3x_esp_init);
-module_exit(sun3x_esp_exit);
MODULE_ALIAS(platform:sun3x_esp);
diff --git a/drivers/scsi/sun_esp.c b/drivers/scsi/sun_esp.c
index f2e6845..d8ece284 100644
--- a/drivers/scsi/sun_esp.c
+++ b/drivers/scsi/sun_esp.c
@@ -640,20 +640,9 @@ static struct platform_driver esp_sbus_driver = {
.remove = esp_sbus_remove,
};
-static int __init sunesp_init(void)
-{
-
[Bug 71231] System unresponsable after a lot of LUNs have been added to the system
https://bugzilla.kernel.org/show_bug.cgi?id=71231 --- Comment #11 from Alex alexandernaum...@gmx.de --- Does anyboy has any hitn how I can solve this problem? It occures with any server and any storage with kernel 3.10 and kernel 3.12. Using bisect has not given my any logical hint which patch might be the reason why it crashes or why it does not crash anymore. -- You are receiving this mail because: You are the assignee for the bug. -- 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
[Bug 71231] System unresponsable after a lot of LUNs have been added to the system
https://bugzilla.kernel.org/show_bug.cgi?id=71231 Alex alexandernaum...@gmx.de changed: What|Removed |Added Kernel Version|3.10.32 |3.10 Regression|No |Yes -- You are receiving this mail because: You are the assignee for the bug. -- 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: blk-mq queue selection and queue_rq preemption
On 4/8/2014 6:40 PM, Jens Axboe wrote: On 2014-04-08 05:10, Sagi Grimberg wrote: On 4/7/2014 10:45 PM, Jens Axboe wrote: On 04/07/2014 06:44 AM, Sagi Grimberg wrote: Hey Jens, Christoph Co, I raised this question at LSF but didn't get a clear answer on this matter. So it seems to me that the hctx selection and the actual request dispatch (queue_rq) are preemptive: (1) blk_mq_get_ctx(q); (2) map_queue(q, ctx-cpu); ... (3) blk_mq_put_ctx(ctx); (4) blk_mq_run_hw_queue(hctx, async); It is possible that an MQ device driver may want to implement a lockless scheme counting on (running) CPU - hctx attachment. Generally speaking, I think that LLDs will be more comfortable knowing that they are not preemptive in the dispatch flow. My question is, is this a must? if so can you please explain why? Is it possible to put the hctx (restoring preemption) after run_hw_queue allowing to LLDs to be sure that the selected queue match the running CPU? It's a good question, and one I have thought about before. As you note, in the existing code, the mappings are what I would refer to as soft. Generally speaking, CPU X will always map to hardware queue Y, but there are no specific guarantees made to effect. It would be trivial to make this mapping hard, and I'd be very open to doing that. But so far I haven't seen cases where it would improve things. If you end up being preempted and moved to a different CPU, it doesn't really matter if this happens before or after you queued the IO - the completion will end up in the wrong location regardless. But if drivers can be simplified and improved through relying on hard mappings (and preempt hence disabled), then I would definitely provide that possibility as well. If it doesn't hurt by default, we can just switch to that model. Hey Jens, thanks for the quick response! So in my driver I would definitely want to rely on hard mappings. The reason is that I maintain a context for IO completions (lets call it completer) and a submission queue percpu. The completer handles IO completions and also peeks at the submission queue to handle pending IOs. I wish to keep mutual exclusion between the completer and the submission context. The driver is capable of setting the IO submission so that the completion will end up on the same core. Hard mappings providing non-preemptive submission flows will guarantee that the above scheme will work. At the moment I do: (1) queue = hctx-driver_data process request... (2) cpu = get_cpu() (3) if (cpu != queue.id) queue = queues[cpu] (4) submit_io(queue) (5) put_cpu() So, adding hard_map indicator to blk_mq_reg will be great. As I mentioned in the general case, I think that LLDs will be more comfortable with hard mappings in order to avoid/reduce lock contention in the submission path and also possibly exploiting cache/NUMA locality. Moreover I think that setting the device to generate IO completion on the submission CPU is common practice for blk-mq implementation. isn't it? I would definitely like to get more input from the driver folks on this. I've rolled up a set of changes to test this out, I have attached the small series. As I originally stated, it was due to performance concerns that I didn't do this originally. If this works better (or the same) on cases where we don't necessarily care about the hard mappings, then we should just do it. It's a cleaner model, and the hardware that has as many queues as CPUs, it's definitely the right (and obvious) thing to do. Note that the attached are TOTALLY untested. Thanks Jens! I'll give it a go... Sagi. -- 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/6] virtio-scsi.h: Add virtio_scsi_cmd_req_pi + VIRTIO_SCSI_F_T10_PI bits
On Tue, Apr 08, 2014 at 04:31:26PM -0400, Paolo Bonzini wrote: Il 07/04/2014 05:55, Michael S. Tsirkin ha scritto: + u16 do_pi_niov; /* DataOUT PI Number of iovecs */ + u16 di_pi_niov; /* DataIN PI Number of iovecs */ So this looks like a somewhat problematic interface to me in that it talks in terms of iovecs not bytes. So this perpetuates the assumption that header is in a separate iov from data (and protection is separate from data). Arguably virtio doesn't work in terms of iovecs on the guest side so this naming looks strange. Further host side, get_vq_descs can in theory split a buffer to multiple iovecs if it crosses the boundary of a memory region. One solution is to use byte lengths here, but this does require that vhost scsi gets rid of layout assumptions generally. Not sure that's practical for -rc1. Why does that require that vhost scsi gets rid of layout assumptions? The interface uses bytes instead of iovecs as the unit, and vhost-scsi can add the (temporary...) requirement that do_pi_nbytes and di_pi_nbytes comprise an integer number of iovecs. Paolo That would be a reasonable intermediate step, but I'm worried there are more assumptions lurking in tere. In particular is it legal for PI to be in the same iov entry as data? If not they really need to use a separate buf entry. -- MST -- 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: blk-mq queue selection and queue_rq preemption
On 04/09/2014 06:10 AM, Sagi Grimberg wrote: On 4/8/2014 6:40 PM, Jens Axboe wrote: On 2014-04-08 05:10, Sagi Grimberg wrote: On 4/7/2014 10:45 PM, Jens Axboe wrote: On 04/07/2014 06:44 AM, Sagi Grimberg wrote: Hey Jens, Christoph Co, I raised this question at LSF but didn't get a clear answer on this matter. So it seems to me that the hctx selection and the actual request dispatch (queue_rq) are preemptive: (1) blk_mq_get_ctx(q); (2) map_queue(q, ctx-cpu); ... (3) blk_mq_put_ctx(ctx); (4) blk_mq_run_hw_queue(hctx, async); It is possible that an MQ device driver may want to implement a lockless scheme counting on (running) CPU - hctx attachment. Generally speaking, I think that LLDs will be more comfortable knowing that they are not preemptive in the dispatch flow. My question is, is this a must? if so can you please explain why? Is it possible to put the hctx (restoring preemption) after run_hw_queue allowing to LLDs to be sure that the selected queue match the running CPU? It's a good question, and one I have thought about before. As you note, in the existing code, the mappings are what I would refer to as soft. Generally speaking, CPU X will always map to hardware queue Y, but there are no specific guarantees made to effect. It would be trivial to make this mapping hard, and I'd be very open to doing that. But so far I haven't seen cases where it would improve things. If you end up being preempted and moved to a different CPU, it doesn't really matter if this happens before or after you queued the IO - the completion will end up in the wrong location regardless. But if drivers can be simplified and improved through relying on hard mappings (and preempt hence disabled), then I would definitely provide that possibility as well. If it doesn't hurt by default, we can just switch to that model. Hey Jens, thanks for the quick response! So in my driver I would definitely want to rely on hard mappings. The reason is that I maintain a context for IO completions (lets call it completer) and a submission queue percpu. The completer handles IO completions and also peeks at the submission queue to handle pending IOs. I wish to keep mutual exclusion between the completer and the submission context. The driver is capable of setting the IO submission so that the completion will end up on the same core. Hard mappings providing non-preemptive submission flows will guarantee that the above scheme will work. At the moment I do: (1) queue = hctx-driver_data process request... (2) cpu = get_cpu() (3) if (cpu != queue.id) queue = queues[cpu] (4) submit_io(queue) (5) put_cpu() So, adding hard_map indicator to blk_mq_reg will be great. As I mentioned in the general case, I think that LLDs will be more comfortable with hard mappings in order to avoid/reduce lock contention in the submission path and also possibly exploiting cache/NUMA locality. Moreover I think that setting the device to generate IO completion on the submission CPU is common practice for blk-mq implementation. isn't it? I would definitely like to get more input from the driver folks on this. I've rolled up a set of changes to test this out, I have attached the small series. As I originally stated, it was due to performance concerns that I didn't do this originally. If this works better (or the same) on cases where we don't necessarily care about the hard mappings, then we should just do it. It's a cleaner model, and the hardware that has as many queues as CPUs, it's definitely the right (and obvious) thing to do. Note that the attached are TOTALLY untested. Thanks Jens! I'll give it a go... The patches were since tested, and miraculously, they actually do seem to work as-is. At least from the perspective of doesn't crash - I'll need to double check things and add some debug logic to check that we don't run on the wrong CPUs from some paths. -- Jens Axboe -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] blk-mq: move request structures into struct blk_mq_tags
On 03/31/2014 08:46 AM, Christoph Hellwig wrote:
diff --git a/block/blk-mq.h b/block/blk-mq.h
index 238379a..eca3a47 100644
--- a/block/blk-mq.h
+++ b/block/blk-mq.h
@@ -1,6 +1,24 @@
#ifndef INT_BLK_MQ_H
#define INT_BLK_MQ_H
+#include linux/percpu_ida.h
+
+/*
+ * Tag address space map.
+ */
+struct blk_mq_tags {
+ unsigned int nr_tags;
+ unsigned int nr_reserved_tags;
+ unsigned int nr_batch_move;
+ unsigned int nr_max_cache;
+
+ struct percpu_ida free_tags;
+ struct percpu_ida reserved_tags;
+
+ struct request **rqs;
+ struct list_head page_list;
+};
+
This should go into block/blk-mq-tag.h.
-static inline struct request *blk_mq_tag_to_rq(struct blk_mq_hw_ctx *hctx,
- unsigned int tag)
-{
- return hctx-rqs[tag];
-}
We might as well leave this, the mtip32xx conversion ends up using it.
So if we pull it now, it'll just be reintroduced shortly.
--
Jens Axboe
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] Fix USB deadlock caused by SCSI error handling
On 04/07/2014 05:26 PM, Alan Stern wrote: On Wed, 2 Apr 2014, Hannes Reinecke wrote: On 04/01/2014 11:28 PM, Alan Stern wrote: On Tue, 1 Apr 2014, Hannes Reinecke wrote: So if the above reasoning is okay then this patch should be doing the trick: diff --git a/drivers/scsi/scsi_error.c b/drivers/scsi/scsi_error.c index 771c16b..0e72374 100644 --- a/drivers/scsi/scsi_error.c +++ b/drivers/scsi/scsi_error.c @@ -189,6 +189,7 @@ scsi_abort_command(struct scsi_cmnd *scmd) /* * Retry after abort failed, escalate to next level. */ + scmd-eh_eflags = ~SCSI_EH_ABORT_SCHEDULED; SCSI_LOG_ERROR_RECOVERY(3, scmd_printk(KERN_INFO, scmd, scmd %p previous abort failed\n, scmd)); (Beware of line breaks) Can you test with it? I don't understand. This doesn't solve the fundamental problem (namely that you escalate before aborting a running command). All it does is clear the SCSI_EH_ABORT_SCHEDULED flag before escalating. Which was precisely the point :-) Hmm. The comment might've been clearer. What this patch is _supposed_ to be doing is that it'll clear the SCSI_EH_ABORT_SCHEDULED flag it it has been set. Which means this will be the second time scsi_abort_command() has been called for the same command. IE the first abort went out, did its thing, but now the same command has timed out again. So this flag gets cleared, and scsi_abort_command() returns FAILED, and _no_ asynchronous abort is being scheduled. scsi_times_out() will then proceed to call scsi_eh_scmd_add(). But as we've cleared the SCSI_EH_ABORT_SCHEDULED flag the SCSI_EH_CANCEL_CMD flag will continue to be set, and the command will be aborted with the main SCSI EH routine. It looks to me as if it should do what you desire, namely abort the command asynchronously the first time, and invoking the SCSI EH the second time. Am I wrong? I don't know -- I'll have to try it out. Currently I'm busy with a bunch of other stuff, so it will take some time. I finally got a chance to try it out. It does seem to do what we want. I didn't track the flow of control in complete detail, but the command definitely got aborted both times it was issued. Good, so it is as I thought. James, can we include this patch instead of your prior solution? Cheers, Hannes -- Dr. Hannes Reinecke zSeries Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[Bug 71231] System unresponsable after a lot of LUNs have been added to the system
https://bugzilla.kernel.org/show_bug.cgi?id=71231 Hannes Reinecke h...@suse.de changed: What|Removed |Added CC||h...@suse.de --- Comment #12 from Hannes Reinecke h...@suse.de --- Comment #3 is the well-known printk lockup. Try to increase the speed on the serial console. Or alternatively try the patch by Jan Kara, should've been posted to lkml. Nothing to do with SCSI, except for the number of messages printed. -- You are receiving this mail because: You are the assignee for the bug. -- 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] Fix USB deadlock caused by SCSI error handling
On Wed, 9 Apr 2014, Hannes Reinecke wrote: I finally got a chance to try it out. It does seem to do what we want. I didn't track the flow of control in complete detail, but the command definitely got aborted both times it was issued. Good, so it is as I thought. James, can we include this patch instead of your prior solution? First, we should have the original bug reporter try it out. Andreas, the patch in question can be found here: http://marc.info/?l=linux-usbm=13962706597w=2 Can you try this in place of the 1/3 patch posted by James? It should have the same effect, of preventing your system from crashing when the READ command fails. Alan Stern -- 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: hpsa driver bug crack kernel down!
[+linux-scsi] On Wed, 2014-04-09 at 15:49 -0700, Davidlohr Bueso wrote: On Wed, 2014-04-09 at 10:39 +0800, Baoquan He wrote: Hi, The kernel is 3.14.0+ which is pulled just now. Cc'ing more people. While the hpsa driver appears to be involved in some way, I'm sure if this is a related issue, but as of today's pull I'm getting another problem that causes my DL980 not to come up. *Massive* amounts of: DMAR:[fault reason 02] Present bit in context entry is clear dmar: DRHD: handling fault status reg 602 dmar: DMAR:[DMA Read] Request device [02:00.0] fault addr 7f61e000 Then: hpsa :03:00.0: Controller lockup detected: 0x ... Workqueue: events hpsa_monitor_ctlr_worker [hpsa] ... Screenshot of the actual LOCKUP: http://stgolabs.net/hpsa-hard-lockup-3.14+.png While I haven't bisected, things worked fine until at least until commit 39de65aa2c3e (April 2nd). Any ideas? Well, it's either a DMA remapping issue or a hpsa one. Your assertion that everything worked fine until 39de65aa2c3e would tend to vindicate hpsa, because all the hpsa changes went in before that under Merge: 3e75c6d b2bff6c Author: Linus Torvalds torva...@linux-foundation.org Date: Tue Apr 1 18:49:04 2014 -0700 Merge tag 'scsi-misc' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi can you revalidate that this commit works OK just to make sure? 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: hpsa driver bug crack kernel down!
On Wed, 2014-04-09 at 16:08 -0700, James Bottomley wrote: [+linux-scsi] On Wed, 2014-04-09 at 15:49 -0700, Davidlohr Bueso wrote: On Wed, 2014-04-09 at 10:39 +0800, Baoquan He wrote: Hi, The kernel is 3.14.0+ which is pulled just now. Cc'ing more people. While the hpsa driver appears to be involved in some way, I'm sure if this is a related issue, but as of today's pull I'm getting another problem that causes my DL980 not to come up. *Massive* amounts of: DMAR:[fault reason 02] Present bit in context entry is clear dmar: DRHD: handling fault status reg 602 dmar: DMAR:[DMA Read] Request device [02:00.0] fault addr 7f61e000 Then: hpsa :03:00.0: Controller lockup detected: 0x ... Workqueue: events hpsa_monitor_ctlr_worker [hpsa] ... Screenshot of the actual LOCKUP: http://stgolabs.net/hpsa-hard-lockup-3.14+.png While I haven't bisected, things worked fine until at least until commit 39de65aa2c3e (April 2nd). Any ideas? Well, it's either a DMA remapping issue or a hpsa one. Your assertion that everything worked fine until 39de65aa2c3e would tend to vindicate hpsa, because all the hpsa changes went in before that under Missing crucial info: commit 1a0b6abaea78f73d9bc0a2f6df2d9e4c917cade1 Merge: 3e75c6d b2bff6c Author: Linus Torvalds torva...@linux-foundation.org Date: Tue Apr 1 18:49:04 2014 -0700 Merge tag 'scsi-misc' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi can you revalidate that this commit works OK just to make sure? 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 -- 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: hpsa driver bug crack kernel down!
On Wed, 2014-04-09 at 16:10 -0700, James Bottomley wrote: On Wed, 2014-04-09 at 16:08 -0700, James Bottomley wrote: [+linux-scsi] On Wed, 2014-04-09 at 15:49 -0700, Davidlohr Bueso wrote: On Wed, 2014-04-09 at 10:39 +0800, Baoquan He wrote: Hi, The kernel is 3.14.0+ which is pulled just now. Cc'ing more people. While the hpsa driver appears to be involved in some way, I'm sure if this is a related issue, but as of today's pull I'm getting another problem that causes my DL980 not to come up. *Massive* amounts of: DMAR:[fault reason 02] Present bit in context entry is clear dmar: DRHD: handling fault status reg 602 dmar: DMAR:[DMA Read] Request device [02:00.0] fault addr 7f61e000 Then: hpsa :03:00.0: Controller lockup detected: 0x ... Workqueue: events hpsa_monitor_ctlr_worker [hpsa] ... Screenshot of the actual LOCKUP: http://stgolabs.net/hpsa-hard-lockup-3.14+.png While I haven't bisected, things worked fine until at least until commit 39de65aa2c3e (April 2nd). Any ideas? Well, it's either a DMA remapping issue or a hpsa one. Your assertion that everything worked fine until 39de65aa2c3e would tend to vindicate hpsa, Hmm here you mean DMA, right? because all the hpsa changes went in before that under Missing crucial info: commit 1a0b6abaea78f73d9bc0a2f6df2d9e4c917cade1 Merge: 3e75c6d b2bff6c Author: Linus Torvalds torva...@linux-foundation.org Date: Tue Apr 1 18:49:04 2014 -0700 Merge tag 'scsi-misc' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi can you revalidate that this commit works OK just to make sure? Ok so I don't see those DMA messages and system starts just fine. I'm thinking perhaps something broke after the IO mmu stuff in commit 3f583bc21977a608908b83d03ee2250426a5695c... could this be indirectly causing the CPU stalls and just blame hpsa in the path as a side effect? /me goes out to try the commit. -- 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: hpsa driver bug crack kernel down!
On Wed, 2014-04-09 at 16:40 -0700, Davidlohr Bueso wrote: On Wed, 2014-04-09 at 16:10 -0700, James Bottomley wrote: On Wed, 2014-04-09 at 16:08 -0700, James Bottomley wrote: [+linux-scsi] On Wed, 2014-04-09 at 15:49 -0700, Davidlohr Bueso wrote: On Wed, 2014-04-09 at 10:39 +0800, Baoquan He wrote: Hi, The kernel is 3.14.0+ which is pulled just now. Cc'ing more people. While the hpsa driver appears to be involved in some way, I'm sure if this is a related issue, but as of today's pull I'm getting another problem that causes my DL980 not to come up. *Massive* amounts of: DMAR:[fault reason 02] Present bit in context entry is clear dmar: DRHD: handling fault status reg 602 dmar: DMAR:[DMA Read] Request device [02:00.0] fault addr 7f61e000 Then: hpsa :03:00.0: Controller lockup detected: 0x ... Workqueue: events hpsa_monitor_ctlr_worker [hpsa] ... Screenshot of the actual LOCKUP: http://stgolabs.net/hpsa-hard-lockup-3.14+.png While I haven't bisected, things worked fine until at least until commit 39de65aa2c3e (April 2nd). Any ideas? Well, it's either a DMA remapping issue or a hpsa one. Your assertion that everything worked fine until 39de65aa2c3e would tend to vindicate hpsa, Hmm here you mean DMA, right? No, it vindicates the hpsa changes ... they don't seem to be causing problems until something goes wrong with dma remapping. because all the hpsa changes went in before that under Missing crucial info: commit 1a0b6abaea78f73d9bc0a2f6df2d9e4c917cade1 Merge: 3e75c6d b2bff6c Author: Linus Torvalds torva...@linux-foundation.org Date: Tue Apr 1 18:49:04 2014 -0700 Merge tag 'scsi-misc' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi can you revalidate that this commit works OK just to make sure? Ok so I don't see those DMA messages and system starts just fine. I'm thinking perhaps something broke after the IO mmu stuff in commit 3f583bc21977a608908b83d03ee2250426a5695c... could this be indirectly causing the CPU stalls and just blame hpsa in the path as a side effect? /me goes out to try the commit. That's my guess. The DMAR messages are DMA remapping issues caused in the IOMMU. If I had to guess, I'd say the DMAR fault message is indicating the IOMMU is calling for a mapping address before it can satisfy the driver read request, which is causing the hang apparently in the hpsa driver. I've added linux-pci to the cc; I think they deal with iommu issues on x86. 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: hpsa driver bug crack kernel down!
On Wed, 2014-04-09 at 16:50 -0700, James Bottomley wrote: On Wed, 2014-04-09 at 16:40 -0700, Davidlohr Bueso wrote: On Wed, 2014-04-09 at 16:10 -0700, James Bottomley wrote: On Wed, 2014-04-09 at 16:08 -0700, James Bottomley wrote: [+linux-scsi] On Wed, 2014-04-09 at 15:49 -0700, Davidlohr Bueso wrote: On Wed, 2014-04-09 at 10:39 +0800, Baoquan He wrote: Hi, The kernel is 3.14.0+ which is pulled just now. Cc'ing more people. While the hpsa driver appears to be involved in some way, I'm sure if this is a related issue, but as of today's pull I'm getting another problem that causes my DL980 not to come up. *Massive* amounts of: DMAR:[fault reason 02] Present bit in context entry is clear dmar: DRHD: handling fault status reg 602 dmar: DMAR:[DMA Read] Request device [02:00.0] fault addr 7f61e000 Then: hpsa :03:00.0: Controller lockup detected: 0x ... Workqueue: events hpsa_monitor_ctlr_worker [hpsa] ... Screenshot of the actual LOCKUP: http://stgolabs.net/hpsa-hard-lockup-3.14+.png While I haven't bisected, things worked fine until at least until commit 39de65aa2c3e (April 2nd). Any ideas? Well, it's either a DMA remapping issue or a hpsa one. Your assertion that everything worked fine until 39de65aa2c3e would tend to vindicate hpsa, Hmm here you mean DMA, right? No, it vindicates the hpsa changes ... they don't seem to be causing problems until something goes wrong with dma remapping. because all the hpsa changes went in before that under Missing crucial info: commit 1a0b6abaea78f73d9bc0a2f6df2d9e4c917cade1 Merge: 3e75c6d b2bff6c Author: Linus Torvalds torva...@linux-foundation.org Date: Tue Apr 1 18:49:04 2014 -0700 Merge tag 'scsi-misc' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi can you revalidate that this commit works OK just to make sure? Ok so I don't see those DMA messages and system starts just fine. I'm thinking perhaps something broke after the IO mmu stuff in commit 3f583bc21977a608908b83d03ee2250426a5695c... could this be indirectly causing the CPU stalls and just blame hpsa in the path as a side effect? /me goes out to try the commit. That's my guess. The DMAR messages are DMA remapping issues caused in the IOMMU. If I had to guess, I'd say the DMAR fault message is indicating the IOMMU is calling for a mapping address before it can satisfy the driver read request, which is causing the hang apparently in the hpsa driver. I've added linux-pci to the cc; I think they deal with iommu issues on x86. So that merge commit appears to be the culprit, I see both the DMA messages and the lockup blaming hpsa... -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/6] qla4xxx: Fix memory leak for ha-saved_acb
From: Nilesh Javali nilesh.jav...@qlogic.com
Signed-off-by: Vikas Chaudhary vikas.chaudh...@qlogic.com
---
drivers/scsi/qla4xxx/ql4_mbx.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/qla4xxx/ql4_mbx.c b/drivers/scsi/qla4xxx/ql4_mbx.c
index 1345c0e..0a3312c 100644
--- a/drivers/scsi/qla4xxx/ql4_mbx.c
+++ b/drivers/scsi/qla4xxx/ql4_mbx.c
@@ -2395,8 +2395,6 @@ int qla4_84xx_config_acb(struct scsi_qla_host *ha, int
acb_config)
}
memcpy(acb, ha-saved_acb, acb_len);
- kfree(ha-saved_acb);
- ha-saved_acb = NULL;
rval = qla4xxx_set_acb(ha, mbox_cmd[0], mbox_sts[0], acb_dma);
if (rval != QLA_SUCCESS)
@@ -2412,6 +2410,10 @@ exit_free_acb:
dma_free_coherent(ha-pdev-dev, sizeof(struct addr_ctrl_blk), acb,
acb_dma);
exit_config_acb:
+ if ((acb_config == ACB_CONFIG_SET) ha-saved_acb) {
+ kfree(ha-saved_acb);
+ ha-saved_acb = NULL;
+ }
DEBUG2(ql4_printk(KERN_INFO, ha,
%s %s\n, __func__,
rval == QLA_SUCCESS ? SUCCEEDED : FAILED));
--
1.8.2.GIT
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/6] qla4xxx: Fix smatch warning in func qla4xxx_get_ep_param
From: Adheer Chandravanshi adheer.chandravan...@qlogic.com
Fix following smatch warning:-
drivers/scsi/qla4xxx/ql4_os.c:1752 qla4xxx_get_ep_param() warn: variable
dereferenced before check 'qla_ep' (see line 1745)
Signed-off-by: Vikas Chaudhary vikas.chaudh...@qlogic.com
---
drivers/scsi/qla4xxx/ql4_os.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/scsi/qla4xxx/ql4_os.c b/drivers/scsi/qla4xxx/ql4_os.c
index 9be829b..592f293 100644
--- a/drivers/scsi/qla4xxx/ql4_os.c
+++ b/drivers/scsi/qla4xxx/ql4_os.c
@@ -1742,6 +1742,9 @@ static int qla4xxx_get_ep_param(struct iscsi_endpoint *ep,
struct sockaddr *dst_addr;
struct scsi_qla_host *ha;
+ if (!qla_ep)
+ return -ENOTCONN;
+
ha = to_qla_host(qla_ep-host);
DEBUG2(ql4_printk(KERN_INFO, ha, %s: host: %ld\n, __func__,
ha-host_no));
@@ -1749,9 +1752,6 @@ static int qla4xxx_get_ep_param(struct iscsi_endpoint *ep,
switch (param) {
case ISCSI_PARAM_CONN_PORT:
case ISCSI_PARAM_CONN_ADDRESS:
- if (!qla_ep)
- return -ENOTCONN;
-
dst_addr = (struct sockaddr *)qla_ep-dst_addr;
if (!dst_addr)
return -ENOTCONN;
--
1.8.2.GIT
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/6] qla4xxx: Export sysfs DDBs from DPC handler
From: Nilesh Javali nilesh.jav...@qlogic.com
Issue:
modprobe qla4xxx is killed by systemd due to timeout.
Solution:
The exporting of sysfs DDBs from qla4xxx_probe_adapter added delay of
approximately 15s due to which system-udevd killed the modprobe of the
driver. Added fix to export the sysfs DDBs from the DPC handler.
Signed-off-by: Nilesh Javali nilesh.jav...@qlogic.com
Signed-off-by: Vikas Chaudhary vikas.chaudh...@qlogic.com
---
drivers/scsi/qla4xxx/ql4_def.h | 1 +
drivers/scsi/qla4xxx/ql4_glbl.h | 1 +
drivers/scsi/qla4xxx/ql4_os.c | 15 +--
3 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/drivers/scsi/qla4xxx/ql4_def.h b/drivers/scsi/qla4xxx/ql4_def.h
index 73a5022..8f6d0fb 100644
--- a/drivers/scsi/qla4xxx/ql4_def.h
+++ b/drivers/scsi/qla4xxx/ql4_def.h
@@ -601,6 +601,7 @@ struct scsi_qla_host {
#define DPC_HA_NEED_QUIESCENT 22 /* 0x0040 ISP-82xx only*/
#define DPC_POST_IDC_ACK 23 /* 0x0080 */
#define DPC_RESTORE_ACB24 /* 0x0100 */
+#define DPC_SYSFS_DDB_EXPORT 25 /* 0x0200 */
struct Scsi_Host *host; /* pointer to host data */
uint32_t tot_ddbs;
diff --git a/drivers/scsi/qla4xxx/ql4_glbl.h b/drivers/scsi/qla4xxx/ql4_glbl.h
index 2035475..5f58b45 100644
--- a/drivers/scsi/qla4xxx/ql4_glbl.h
+++ b/drivers/scsi/qla4xxx/ql4_glbl.h
@@ -281,6 +281,7 @@ int qla4_83xx_get_port_config(struct scsi_qla_host *ha,
uint32_t *config);
int qla4_83xx_set_port_config(struct scsi_qla_host *ha, uint32_t *config);
int qla4_8xxx_check_init_adapter_retry(struct scsi_qla_host *ha);
int qla4_83xx_is_detached(struct scsi_qla_host *ha);
+int qla4xxx_sysfs_ddb_export(struct scsi_qla_host *ha);
extern int ql4xextended_error_logging;
extern int ql4xdontresethba;
diff --git a/drivers/scsi/qla4xxx/ql4_os.c b/drivers/scsi/qla4xxx/ql4_os.c
index bb16040..9be829b 100644
--- a/drivers/scsi/qla4xxx/ql4_os.c
+++ b/drivers/scsi/qla4xxx/ql4_os.c
@@ -4565,6 +4565,7 @@ static void qla4xxx_timer(struct scsi_qla_host *ha)
test_bit(DPC_LINK_CHANGED, ha-dpc_flags) ||
test_bit(DPC_HA_UNRECOVERABLE, ha-dpc_flags) ||
test_bit(DPC_HA_NEED_QUIESCENT, ha-dpc_flags) ||
+test_bit(DPC_SYSFS_DDB_EXPORT, ha-dpc_flags) ||
test_bit(DPC_AEN, ha-dpc_flags)) {
DEBUG2(printk(scsi%ld: %s: scheduling dpc routine
- dpc flags = 0x%lx\n,
@@ -5429,6 +5430,11 @@ dpc_post_reset_ha:
qla4xxx_relogin_all_devices(ha);
}
}
+ if (test_and_clear_bit(DPC_SYSFS_DDB_EXPORT, ha-dpc_flags)) {
+ if (qla4xxx_sysfs_ddb_export(ha))
+ ql4_printk(KERN_ERR, ha, %s: Error exporting ddb to
sysfs\n,
+ __func__);
+ }
}
/**
@@ -8406,7 +8412,7 @@ exit_ddb_del:
*
* Export the firmware DDB for all send targets and normal targets to sysfs.
**/
-static int qla4xxx_sysfs_ddb_export(struct scsi_qla_host *ha)
+int qla4xxx_sysfs_ddb_export(struct scsi_qla_host *ha)
{
struct dev_db_entry *fw_ddb_entry = NULL;
dma_addr_t fw_ddb_entry_dma;
@@ -8844,11 +8850,8 @@ skip_retry_init:
ql4_printk(KERN_ERR, ha,
%s: No iSCSI boot target configured\n, __func__);
- if (qla4xxx_sysfs_ddb_export(ha))
- ql4_printk(KERN_ERR, ha,
- %s: Error exporting ddb to sysfs\n, __func__);
-
- /* Perform the build ddb list and login to each */
+ set_bit(DPC_SYSFS_DDB_EXPORT, ha-dpc_flags);
+ /* Perform the build ddb list and login to each */
qla4xxx_build_ddb_list(ha, INIT_ADAPTER);
iscsi_host_for_each_session(ha-host, qla4xxx_login_flash_ddb);
qla4xxx_wait_login_resp_boot_tgt(ha);
--
1.8.2.GIT
--
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 5/6] qla4xxx: Fix smatch warning in func qla4xxx_conn_get_param
From: Adheer Chandravanshi adheer.chandravan...@qlogic.com Signed-off-by: Vikas Chaudhary vikas.chaudh...@qlogic.com --- drivers/scsi/qla4xxx/ql4_os.c | 4 1 file changed, 4 deletions(-) diff --git a/drivers/scsi/qla4xxx/ql4_os.c b/drivers/scsi/qla4xxx/ql4_os.c index 592f293..9eef7d4 100644 --- a/drivers/scsi/qla4xxx/ql4_os.c +++ b/drivers/scsi/qla4xxx/ql4_os.c @@ -2879,7 +2879,6 @@ static int qla4xxx_conn_get_param(struct iscsi_cls_conn *cls_conn, struct iscsi_conn *conn; struct qla_conn *qla_conn; struct sockaddr *dst_addr; - int len = 0; conn = cls_conn-dd_data; qla_conn = conn-dd_data; @@ -2893,9 +2892,6 @@ static int qla4xxx_conn_get_param(struct iscsi_cls_conn *cls_conn, default: return iscsi_conn_get_param(cls_conn, param, buf); } - - return len; - } int qla4xxx_get_ddb_index(struct scsi_qla_host *ha, uint16_t *ddb_index) -- 1.8.2.GIT -- 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 6/6] qla4xxx: Update driver version to 5.04.00-k6
From: Vikas Chaudhary vikas.chaudh...@qlogic.com Signed-off-by: Vikas Chaudhary vikas.chaudh...@qlogic.com --- drivers/scsi/qla4xxx/ql4_version.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/scsi/qla4xxx/ql4_version.h b/drivers/scsi/qla4xxx/ql4_version.h index bd78cb3..f11eaa7 100644 --- a/drivers/scsi/qla4xxx/ql4_version.h +++ b/drivers/scsi/qla4xxx/ql4_version.h @@ -5,4 +5,4 @@ * See LICENSE.qla4xxx for copyright and licensing details. */ -#define QLA4XXX_DRIVER_VERSION 5.04.00-k5 +#define QLA4XXX_DRIVER_VERSION 5.04.00-k6 -- 1.8.2.GIT -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/6] qla4xxx: 5.04.00-k6: Updates for scsi misc branch
From: Vikas Chaudhary vikas.chaudh...@qlogic.com James, Please apply the following patches to the scsi tree at your earliest convenience. Adheer Chandravanshi (2): qla4xxx: Fix smatch warning in func qla4xxx_get_ep_param qla4xxx: Fix smatch warning in func qla4xxx_conn_get_param Nilesh Javali (2): qla4xxx: Export sysfs DDBs from DPC handler qla4xxx: Fix memory leak for ha-saved_acb Tej Parkash (1): qla4xxx: Disable INTx interrupt for ISP82XX Vikas Chaudhary (1): qla4xxx: Update driver version to 5.04.00-k6 Thanks, Vikas. -- 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 1/6] qla4xxx: Disable INTx interrupt for ISP82XX
From: Tej Parkash tej.park...@qlogic.com
Signed-off-by: Tej Parkash tej.park...@qlogic.com
Signed-off-by: Vikas Chaudhary vikas.chaudh...@qlogic.com
---
drivers/scsi/qla4xxx/ql4_isr.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/scsi/qla4xxx/ql4_isr.c b/drivers/scsi/qla4xxx/ql4_isr.c
index b1925d1..081b6b7 100644
--- a/drivers/scsi/qla4xxx/ql4_isr.c
+++ b/drivers/scsi/qla4xxx/ql4_isr.c
@@ -1526,7 +1526,7 @@ void qla4xxx_process_aen(struct scsi_qla_host * ha,
uint8_t process_aen)
int qla4xxx_request_irqs(struct scsi_qla_host *ha)
{
- int ret;
+ int ret = 0;
int rval = QLA_ERROR;
if (is_qla40XX(ha))
@@ -1580,15 +1580,13 @@ try_msi:
}
}
- /*
-* Prevent interrupts from falling back to INTx mode in cases where
-* interrupts cannot get acquired through MSI-X or MSI mode.
-*/
+try_intx:
if (is_qla8022(ha)) {
- ql4_printk(KERN_WARNING, ha, IRQ not attached -- %d.\n, ret);
+ ql4_printk(KERN_WARNING, ha, %s: ISP82xx Legacy interrupt not
supported\n,
+ __func__);
goto irq_not_attached;
}
-try_intx:
+
/* Trying INTx */
ret = request_irq(ha-pdev-irq, ha-isp_ops-intr_handler,
IRQF_SHARED, DRIVER_NAME, ha);
--
1.8.2.GIT
--
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: Make sure cmd_flags are 64-bit
From: Martin K. Petersen martin.peter...@oracle.com
cmd_flags in struct request is now 64 bits wide but the scsi_execute
functions truncated arguments passed to int leading to errors. Make sure
the flags parameters are u64.
Signed-off-by: Martin K. Petersen martin.peter...@oracle.com
Cc: Jens Axboe ax...@fb.com
CC: Jan Kara j...@suse.cz
Cc: Frederic Weisbecker fweis...@gmail.com
---
drivers/scsi/scsi_lib.c| 4 ++--
include/scsi/scsi_device.h | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 5681c05ac506..65a123d9c676 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -184,7 +184,7 @@ void scsi_queue_insert(struct scsi_cmnd *cmd, int reason)
*/
int scsi_execute(struct scsi_device *sdev, const unsigned char *cmd,
int data_direction, void *buffer, unsigned bufflen,
-unsigned char *sense, int timeout, int retries, int flags,
+unsigned char *sense, int timeout, int retries, u64 flags,
int *resid)
{
struct request *req;
@@ -235,7 +235,7 @@ EXPORT_SYMBOL(scsi_execute);
int scsi_execute_req_flags(struct scsi_device *sdev, const unsigned char *cmd,
int data_direction, void *buffer, unsigned bufflen,
struct scsi_sense_hdr *sshdr, int timeout, int retries,
-int *resid, int flags)
+int *resid, u64 flags)
{
char *sense = NULL;
int result;
diff --git a/include/scsi/scsi_device.h b/include/scsi/scsi_device.h
index 4e845b80efd3..5853c913d2b0 100644
--- a/include/scsi/scsi_device.h
+++ b/include/scsi/scsi_device.h
@@ -423,11 +423,11 @@ extern int scsi_is_target_device(const struct device *);
extern int scsi_execute(struct scsi_device *sdev, const unsigned char *cmd,
int data_direction, void *buffer, unsigned bufflen,
unsigned char *sense, int timeout, int retries,
- int flag, int *resid);
+ u64 flags, int *resid);
extern int scsi_execute_req_flags(struct scsi_device *sdev,
const unsigned char *cmd, int data_direction, void *buffer,
unsigned bufflen, struct scsi_sense_hdr *sshdr, int timeout,
- int retries, int *resid, int flags);
+ int retries, int *resid, u64 flags);
static inline int scsi_execute_req(struct scsi_device *sdev,
const unsigned char *cmd, int data_direction, void *buffer,
unsigned bufflen, struct scsi_sense_hdr *sshdr, int timeout,
--
1.8.3.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
