Re: [PATCH V2] scsi_lib: removes ambiguous Unhandled error code messages.
On 07/03/2014 10:41 AM, Christoph Hellwig wrote: On Wed, Jun 25, 2014 at 08:38:47PM +, Elliott, Robert (Server Storage) wrote: Since the ACTION_FAIL case always prints the sense key and additional sense code: perhaps the description string should be removed altogether? I'm tempted to agree and just remove the description. Do you want to send a patch for this? So I'll get rid of the description string completely... I'm going to send a new patch later today. Regards, Maurizio Lombardi -- 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: uas: kernel BUG at block/blk-tag.c:89 is back again :|
On Mon, Jul 07, 2014 at 02:42:40PM +0200, Hans de Goede wrote: I can't see any sensible way to fix the issue. Struct gendisk keeps a reference to the requeue_queue, and a struct gendisk reference is held as long as the block device is open. So whenever you surprise remove a device that is open (usually by having a filesystem mounted on it), the request_queue and it's reference to the tag structure will vastly outlive the Scsi_Host. Ok, so can we then please move forward with getting your patch merged ? I've posted the patch in reply to another report and added Jens to the Cc list. As the block maintainer he need to review and merge 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: uas: kernel BUG at block/blk-tag.c:89 is back again :|
On 2014-07-08 11:53, Christoph Hellwig wrote: On Mon, Jul 07, 2014 at 02:42:40PM +0200, Hans de Goede wrote: I can't see any sensible way to fix the issue. Struct gendisk keeps a reference to the requeue_queue, and a struct gendisk reference is held as long as the block device is open. So whenever you surprise remove a device that is open (usually by having a filesystem mounted on it), the request_queue and it's reference to the tag structure will vastly outlive the Scsi_Host. Ok, so can we then please move forward with getting your patch merged ? I've posted the patch in reply to another report and added Jens to the Cc list. As the block maintainer he need to review and merge it. Which patch is this? -- 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: uas: kernel BUG at block/blk-tag.c:89 is back again :|
On Tue, Jul 08, 2014 at 11:54:14AM +0200, Jens Axboe wrote:
I've posted the patch in reply to another report and added Jens to the
Cc list. As the block maintainer he need to review and merge it.
Which patch is this?
This one:
---
From: Christoph Hellwig h...@lst.de
Subject: block: don't assume last put of shared tags is for the host
There is no inherent reason why the last put of a tag structure must be
the one for the Scsi_Host, as device model objects can be held for
arbitrary periods. Merge blk_free_tags and __blk_free_tags into a single
funtion that just release a references and get rid of the BUG() when the
host reference wasn't the last.
Signed-off-by: Christoph Hellwig h...@lst.de
diff --git a/block/blk-tag.c b/block/blk-tag.c
index 3f33d86..a185b86 100644
--- a/block/blk-tag.c
+++ b/block/blk-tag.c
@@ -27,18 +27,15 @@ struct request *blk_queue_find_tag(struct request_queue *q,
int tag)
EXPORT_SYMBOL(blk_queue_find_tag);
/**
- * __blk_free_tags - release a given set of tag maintenance info
+ * blk_free_tags - release a given set of tag maintenance info
* @bqt: the tag map to free
*
- * Tries to free the specified @bqt. Returns true if it was
- * actually freed and false if there are still references using it
+ * Drop the reference count on @bqt and frees it when the last reference
+ * is dropped.
*/
-static int __blk_free_tags(struct blk_queue_tag *bqt)
+void blk_free_tags(struct blk_queue_tag *bqt)
{
- int retval;
-
- retval = atomic_dec_and_test(bqt-refcnt);
- if (retval) {
+ if (atomic_dec_and_test(bqt-refcnt)) {
BUG_ON(find_first_bit(bqt-tag_map, bqt-max_depth)
bqt-max_depth);
@@ -50,9 +47,8 @@ static int __blk_free_tags(struct blk_queue_tag *bqt)
kfree(bqt);
}
-
- return retval;
}
+EXPORT_SYMBOL(blk_free_tags);
/**
* __blk_queue_free_tags - release tag maintenance info
@@ -69,28 +65,13 @@ void __blk_queue_free_tags(struct request_queue *q)
if (!bqt)
return;
- __blk_free_tags(bqt);
+ blk_free_tags(bqt);
q-queue_tags = NULL;
queue_flag_clear_unlocked(QUEUE_FLAG_QUEUED, q);
}
/**
- * blk_free_tags - release a given set of tag maintenance info
- * @bqt: the tag map to free
- *
- * For externally managed @bqt frees the map. Callers of this
- * function must guarantee to have released all the queues that
- * might have been using this tag map.
- */
-void blk_free_tags(struct blk_queue_tag *bqt)
-{
- if (unlikely(!__blk_free_tags(bqt)))
- BUG();
-}
-EXPORT_SYMBOL(blk_free_tags);
-
-/**
* blk_queue_free_tags - release tag maintenance info
* @q: the request queue for the device
*
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 3/3] scsi: ufs: retry if the link-startup fails
Did you plan to change the arguments to ufshcd_is_device_present in a later patch? I guess I overlooked it, thanks for bringing it to my attention. I will resend the series without this patch. Thanks, Dolev -- QUALCOMM ISRAEL, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -Original Message- From: Christoph Hellwig [mailto:h...@infradead.org] Sent: Monday, July 07, 2014 1:37 PM To: Dolev Raviv Cc: james.bottom...@hansenpartnership.com; linux-scsi@vger.kernel.org; linux-scsi-ow...@vger.kernel.org; sthu...@codeaurora.org; linux-arm-...@vger.kernel.org; santos...@gmail.com Subject: Re: [PATCH 3/3] scsi: ufs: retry if the link-startup fails This produces a compiler warning for me that looks serious: ../drivers/scsi/ufs/ufshcd.c: In function ‘ufshcd_link_startup’: ../drivers/scsi/ufs/ufshcd.c:1938:3: warning: passing argument 1 of ‘ufshcd_is_device_present’ makes integer from pointer without a cast [enabled by default] ../drivers/scsi/ufs/ufshcd.c:185:19: note: expected ‘u32’ but argument is of type ‘struct ufs_hba *’ Did you plan to change the arguments to ufshcd_is_device_present in a later patch? -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] scsi: ufs: retry if the link-startup fails
On Tue, Jul 08, 2014 at 01:18:27PM +0300, Dolev Raviv wrote: Did you plan to change the arguments to ufshcd_is_device_present in a later patch? I guess I overlooked it, thanks for bringing it to my attention. I will resend the series without this patch. If the series works just fine without this patch I'm happy to drop it locally, no need to resend. -- 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: uas: kernel BUG at block/blk-tag.c:89 is back again :|
On 2014-07-08 11:56, Christoph Hellwig wrote: On Tue, Jul 08, 2014 at 11:54:14AM +0200, Jens Axboe wrote: I've posted the patch in reply to another report and added Jens to the Cc list. As the block maintainer he need to review and merge it. Which patch is this? This one: --- From: Christoph Hellwig h...@lst.de Subject: block: don't assume last put of shared tags is for the host There is no inherent reason why the last put of a tag structure must be the one for the Scsi_Host, as device model objects can be held for arbitrary periods. Merge blk_free_tags and __blk_free_tags into a single funtion that just release a references and get rid of the BUG() when the host reference wasn't the last. Thanks, applied. I don't think I was ever CC'ed on this one, though. -- 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: uas: kernel BUG at block/blk-tag.c:89 is back again :|
Hi, On 07/08/2014 12:35 PM, Jens Axboe wrote: On 2014-07-08 11:56, Christoph Hellwig wrote: On Tue, Jul 08, 2014 at 11:54:14AM +0200, Jens Axboe wrote: I've posted the patch in reply to another report and added Jens to the Cc list. As the block maintainer he need to review and merge it. Which patch is this? This one: --- From: Christoph Hellwig h...@lst.de Subject: block: don't assume last put of shared tags is for the host There is no inherent reason why the last put of a tag structure must be the one for the Scsi_Host, as device model objects can be held for arbitrary periods. Merge blk_free_tags and __blk_free_tags into a single funtion that just release a references and get rid of the BUG() when the host reference wasn't the last. Thanks, applied. I don't think I was ever CC'ed on this one, though. Thanks, good to hear. Can you please add a Cc: stable ? This patch should at least be backported to 3.15, where uas support has been declared stable. With uas it is trivial to trigger the BUG_ON (and break any further device hotplugging) since uas allows for tcq, and thus using tags over usb (with all of its hotplug goodness and badness). Regards, Hans -- 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: uas: kernel BUG at block/blk-tag.c:89 is back again :|
On 2014-07-08 13:25, Hans de Goede wrote: Hi, On 07/08/2014 12:35 PM, Jens Axboe wrote: On 2014-07-08 11:56, Christoph Hellwig wrote: On Tue, Jul 08, 2014 at 11:54:14AM +0200, Jens Axboe wrote: I've posted the patch in reply to another report and added Jens to the Cc list. As the block maintainer he need to review and merge it. Which patch is this? This one: --- From: Christoph Hellwig h...@lst.de Subject: block: don't assume last put of shared tags is for the host There is no inherent reason why the last put of a tag structure must be the one for the Scsi_Host, as device model objects can be held for arbitrary periods. Merge blk_free_tags and __blk_free_tags into a single funtion that just release a references and get rid of the BUG() when the host reference wasn't the last. Thanks, applied. I don't think I was ever CC'ed on this one, though. Thanks, good to hear. Can you please add a Cc: stable ? This patch should at least be backported to 3.15, where uas support has been declared stable. With uas it is trivial to trigger the BUG_ON (and break any further device hotplugging) since uas allows for tcq, and thus using tags over usb (with all of its hotplug goodness and badness). I did mark it stable when queuing it up, so should be all set. -- 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
[ANNOUNCE] scsi patch queue tree updated
I've pushed out new version of the for-3.17 core and drivers trees: git://git.infradead.org/users/hch/scsi-queue.git core-for-3.17 git://git.infradead.org/users/hch/scsi-queue.git drivers-for-3.17 In the core tree the biggest news is the old target infrastructure removal, in addition a few warnings due to 64-bit LUNs have been fixed, and the tree has been rebased to 3.16-rc4 to pick up all updates that went into the Linux 3.16 release candidates. The drivers-for-3.17 tree is new, and I should have picked up all properly reviewed patches. Most notably missing from the drivers tree are the mpt2sas and mpt3sas series and the scsi_debug update which need a review, and the megaraid and pm8001 uptdates which need a resend. Missing from the core tree is the scsi-mq work that still needs a proper review. Also notably absent is the flush error handling fix, which still needs a signoff from James and a proper review. As far as I'm concerned that fix should still go into 3.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
Re: scsi-mq V2
On Wed, Jun 25, 2014 at 06:51:47PM +0200, Christoph Hellwig wrote:
Changes from V1:
- rebased on top of the core-for-3.17 branch, most notable the
scsi logging changes
- fixed handling of cmd_list to prevent crashes for some heavy
workloads
- fixed incorrect handling of !target-can_queue
- avoid scheduling a workqueue on I/O completions when no queues
are congested
In addition to the patches in this thread there also is a git available at:
git://git.infradead.org/users/hch/scsi.git scsi-mq.2
I've pushed out a new scsi-mq.3 branch, which has been rebased on the
latest core-for-3.17 tree + the RFC: clean up command setup series
from June 29th. Robert Elliot found a problem with not fully zeroed
out UNMAP CDBs, which is fixed by the saner discard handling in that
series.
There is a new patch to factor the code from the above series for
blk-mq use, which I've attached below. Besides that the only changes
are minor merge fixups in the main blk-mq usage patch.
---
From f925c317c74849666d599926d8ad8f34ef99d5cf Mon Sep 17 00:00:00 2001
From: Christoph Hellwig h...@lst.de
Date: Tue, 8 Jul 2014 13:16:17 +0200
Subject: scsi: add scsi_setup_cmnd helper
Factor out command setup code that will be shared with the blk-mq code path.
Signed-off-by: Christoph Hellwig h...@lst.de
---
drivers/scsi/scsi_lib.c | 40 ++--
1 file changed, 22 insertions(+), 18 deletions(-)
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 116f541..61afae8 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -1116,6 +1116,27 @@ static int scsi_setup_fs_cmnd(struct scsi_device *sdev,
struct request *req)
return scsi_cmd_to_driver(cmd)-init_command(cmd);
}
+static int scsi_setup_cmnd(struct scsi_device *sdev, struct request *req)
+{
+ struct scsi_cmnd *cmd = req-special;
+
+ if (!blk_rq_bytes(req))
+ cmd-sc_data_direction = DMA_NONE;
+ else if (rq_data_dir(req) == WRITE)
+ cmd-sc_data_direction = DMA_TO_DEVICE;
+ else
+ cmd-sc_data_direction = DMA_FROM_DEVICE;
+
+ switch (req-cmd_type) {
+ case REQ_TYPE_FS:
+ return scsi_setup_fs_cmnd(sdev, req);
+ case REQ_TYPE_BLOCK_PC:
+ return scsi_setup_blk_pc_cmnd(sdev, req);
+ default:
+ return BLKPREP_KILL;
+ }
+}
+
static int
scsi_prep_state_check(struct scsi_device *sdev, struct request *req)
{
@@ -1219,24 +1240,7 @@ static int scsi_prep_fn(struct request_queue *q, struct
request *req)
goto out;
}
- if (!blk_rq_bytes(req))
- cmd-sc_data_direction = DMA_NONE;
- else if (rq_data_dir(req) == WRITE)
- cmd-sc_data_direction = DMA_TO_DEVICE;
- else
- cmd-sc_data_direction = DMA_FROM_DEVICE;
-
- switch (req-cmd_type) {
- case REQ_TYPE_FS:
- ret = scsi_setup_fs_cmnd(sdev, req);
- break;
- case REQ_TYPE_BLOCK_PC:
- ret = scsi_setup_blk_pc_cmnd(sdev, req);
- break;
- default:
- ret = BLKPREP_KILL;
- }
-
+ ret = scsi_setup_cmnd(sdev, req);
out:
return scsi_prep_return(q, req, ret);
}
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dummy scsi read or scsi command periodically for external USB Hard Disk
hi Alan: 2014-07-08 1:02 GMT+08:00 Alan Stern st...@rowland.harvard.edu: On Tue, 8 Jul 2014, loody wrote: An alternative is to write a positive value, such as 24, to /sys/block/sdX/events_poll_msecs where X is replaced with the proper drive letter. (24 ms = 240 s = 4 m.) I'm not sure this will work, but it's worth a try. I cannot find events_poll_msecs you mentioned in my system. Is this capability related to kernel version? ( my kernel version is 2.6.38.8 ) Well, the in-kernel disk events mechanism was added in 2.6.38, but it may not have been implemented for your type of drive. You are correct. i can see events_poll_msecs when I change my kernel to 3.8.0 But the device still disconnect. I have some question. 1. when I cat /sys/block/sdX/events, I get the answer as media_change. is there any events type we can choose, such as read capability or inquiry. Probably you don't actually need to do a read. Simply opening the device file ought to be sufficient. 2. the open device you mean is like open(/dev/sda1)? thanks for all your kind help, -- Regards, -- 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 v6 0/2] ata: Fix the dma state machine lockup for APM X-Gene SoC
On Mon, Jul 07, 2014 at 10:33:03PM +0530, Suman Tripathi wrote: This patch addresses the dma state machine lockup for APM X-Gene SoC. Signed-off-by: Loc Ho l...@apm.com Signed-off-by: Suman Tripathi stripa...@apm.com Applied to libata/for-3.16-fixes. 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: dummy scsi read or scsi command periodically for external USB Hard Disk
On Tue, 8 Jul 2014, loody wrote: You are correct. i can see events_poll_msecs when I change my kernel to 3.8.0 But the device still disconnect. I have some question. 1. when I cat /sys/block/sdX/events, I get the answer as media_change. is there any events type we can choose, such as read capability or inquiry. The only other event type is eject_request. But that applies to CD drives, not disk drives. Probably you don't actually need to do a read. Simply opening the device file ought to be sufficient. 2. the open device you mean is like open(/dev/sda1)? Yes. That will send a SCSI TEST UNIT READY command, the same as disk events polling. You can use usbmon to verify this. However, maybe TEST UNIT READY won't work. Your drive might need to see a READ or WRITE command. If that's the case then neither events_poll_msecs nor a simple open() will help. Have you tried using hdparm with the -B or -S flag? 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: dummy scsi read or scsi command periodically for external USB Hard Disk
hi Alan: 2014-07-09 0:00 GMT+08:00 Alan Stern st...@rowland.harvard.edu: On Tue, 8 Jul 2014, loody wrote: You are correct. i can see events_poll_msecs when I change my kernel to 3.8.0 But the device still disconnect. I have some question. 1. when I cat /sys/block/sdX/events, I get the answer as media_change. is there any events type we can choose, such as read capability or inquiry. The only other event type is eject_request. But that applies to CD drives, not disk drives. Probably you don't actually need to do a read. Simply opening the device file ought to be sufficient. 2. the open device you mean is like open(/dev/sda1)? Yes. That will send a SCSI TEST UNIT READY command, the same as disk events polling. You can use usbmon to verify this. However, maybe TEST UNIT READY won't work. Your drive might need to see a READ or WRITE command. If that's the case then neither events_poll_msecs nor a simple open() will help. Have you tried using hdparm with the -B or -S flag? there is one thing pop in my mind. if events_poll_msecs is used for media_change, shouldn't we wrap is READ10? the difference seems 1. change SCSI command 2. allocate 512 Byte for 1 sector dummy read the periodically trigging flow should be the same. if you think above is possible, where we should start from? appreciate your help -- Regards, -- 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: dummy scsi read or scsi command periodically for external USB Hard Disk
On Wed, 9 Jul 2014, loody wrote: there is one thing pop in my mind. if events_poll_msecs is used for media_change, shouldn't we wrap is READ10? No. Why should media change polling use READ(10)? TEST UNIT READY does a good job of detecting media changes. the difference seems 1. change SCSI command 2. allocate 512 Byte for 1 sector dummy read the periodically trigging flow should be the same. if you think above is possible, where we should start from? Why do you want to make this change? 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: [PATCH 03/14] scsi: centralize command re-queueing in scsi_dispatch_fn
-Original Message-
From: Christoph Hellwig [mailto:h...@lst.de]
Sent: Wednesday, 25 June, 2014 11:52 AM
To: James Bottomley
Cc: Jens Axboe; Bart Van Assche; Elliott, Robert (Server Storage); linux-
s...@vger.kernel.org; linux-ker...@vger.kernel.org
Subject: [PATCH 03/14] scsi: centralize command re-queueing in
scsi_dispatch_fn
Make sure we only have the logic for requeing commands in one place.
Signed-off-by: Christoph Hellwig h...@lst.de
---
drivers/scsi/scsi.c | 35 ---
drivers/scsi/scsi_lib.c |9 ++---
2 files changed, 18 insertions(+), 26 deletions(-)
diff --git a/drivers/scsi/scsi.c b/drivers/scsi/scsi.c
index ce5b4e5..dcc43fd 100644
--- a/drivers/scsi/scsi.c
+++ b/drivers/scsi/scsi.c
@@ -648,9 +648,7 @@ int scsi_dispatch_cmd(struct scsi_cmnd *cmd)
* returns an immediate error upwards, and signals
* that the device is no longer present */
cmd-result = DID_NO_CONNECT 16;
- scsi_done(cmd);
- /* return 0 (because the command has been processed) */
- goto out;
+ goto done;
}
/* Check to see if the scsi lld made this device blocked. */
@@ -662,17 +660,9 @@ int scsi_dispatch_cmd(struct scsi_cmnd *cmd)
* occur until the device transitions out of the
* suspend state.
*/
-
- scsi_queue_insert(cmd, SCSI_MLQUEUE_DEVICE_BUSY);
-
SCSI_LOG_MLQUEUE(3, scmd_printk(KERN_INFO, cmd,
queuecommand : device blocked\n));
-
- /*
- * NOTE: rtn is still zero here because we don't need the
- * queue to be plugged on return (it's already stopped)
- */
- goto out;
+ return SCSI_MLQUEUE_DEVICE_BUSY;
}
/*
@@ -696,20 +686,19 @@ int scsi_dispatch_cmd(struct scsi_cmnd *cmd)
cdb_size=%d host-max_cmd_len=%d\n,
cmd-cmd_len, cmd-device-host-max_cmd_len));
cmd-result = (DID_ABORT 16);
-
- scsi_done(cmd);
- goto out;
+ goto done;
}
if (unlikely(host-shost_state == SHOST_DEL)) {
cmd-result = (DID_NO_CONNECT 16);
- scsi_done(cmd);
- } else {
- trace_scsi_dispatch_cmd_start(cmd);
- cmd-scsi_done = scsi_done;
- rtn = host-hostt-queuecommand(host, cmd);
+ goto done;
+
}
+ trace_scsi_dispatch_cmd_start(cmd);
+
+ cmd-scsi_done = scsi_done;
+ rtn = host-hostt-queuecommand(host, cmd);
if (rtn) {
trace_scsi_dispatch_cmd_error(cmd, rtn);
if (rtn != SCSI_MLQUEUE_DEVICE_BUSY
@@ -718,12 +707,12 @@ int scsi_dispatch_cmd(struct scsi_cmnd *cmd)
SCSI_LOG_MLQUEUE(3, scmd_printk(KERN_INFO, cmd,
queuecommand : request rejected\n));
-
- scsi_queue_insert(cmd, rtn);
}
- out:
return rtn;
+ done:
+ scsi_done(cmd);
+ return 0;
}
Related to the position of the trace_scsi_dispatch_cmd_start()
call... this function does:
1. check sdev_state - goto done
2. check scsi_device_blocked() - return
3. put LUN into CDB for ancient SCSI-1 devices
4. scsi_log_send()
5. check cmd_len - goto done
6. check shost_state - goto done
7. trace_scsi_dispatch_cmd_start()
8. queuecommand()
9. return
10. done:
cmd-scsi_done(cmd) [PATCH 04/14 upgrades it to this]
return 0;
It's inconsistent for logging and tracing to occur after
different number of checks.
In scsi_lib.c, both scsi_done() and scsi_mq_done() always call
trace_scsi_dispatch_cmd_done(), so trace_scsi_dispatch_cmd_start()
should be called before scsi_done() is called. That way the
trace will always have a submission to match each completion.
That means trace should be called before the sdev_state check
(which calls scsi_done()).
I don't know about the scsi_device_blocked check (which just
returns). Should the trace record multiple submissions with
one completion? Maybe both trace_scsi_dispatch_cmd_start()
and trace_scsi_dispatch_cmd_done() should both be called?
scsi_log_completion() is called by scsi_softirq_done() and
scsi_times_out() but not by scsi_done() and scsi_mq_done(), so
scsi_log_send() should not be called unless all the checks
pass and an IO is really queued.
That would lead to something like:
1. check sdev_state - goto done
2. check scsi_device_blocked() - return
3. put LUN into CDB for ancient SCSI-1 devices
5. check cmd_len - goto done
6. check shost_state - goto done
7a. scsi_log_send()
7b. trace_scsi_dispatch_cmd_start()
8. queuecommand()
9. return
10. done:
trace_scsi_dispatch_cmd_start()
cmd-scsi_done(cmd);
return 0;
---
Rob ElliottHP Server Storage
--
To unsubscribe from this list: send
Re: [RFC 1/2] target: Add documentation on the target userspace pass-through driver
[re-adding individual CCs that were dropped] On 07/05/2014 04:29 AM, Alex Elsayed wrote: +Device Discovery: + +Other devices may be using UIO besides TCMU. Unrelated user processes +may also be handling different sets of TCMU devices. TCMU userspace +processes must find their devices by scanning sysfs +class/uio/uio*/name. For TCMU devices, these names will be of the +format: + +tcm-user/subtype/path + +where tcm-user is common for all TCMU-backed UIO devices. subtype +will be a userspace-process-unique string to identify the TCMU device +as expecting to be backed by a certain handler, and path will be an +additional handler-specific string for the user process to configure +the device, if needed. Neither subtype or path can contain ':', +due to LIO limitations. It might be good to change this somewhat; in the vast majority of cases it'd be saner for userspace programs to figure this information out via udev etc. rather than parsing sysfs themselves. This information is still worth documenting, but saying things like must find their devices by scanning sysfs is likely to lead to users of this interface making suboptimal choices. I agree. There's no getting around a certain degree of work required by the backing user program. I'm planning on writing a tcmu-runner program with a plugin interface, that will handle the event loop, device notifications, enumeration, and possibly thread pools, to minimize the amount of boilerplate code each implementation must contain. +Device Events: + +If a new device is added or removed, user processes will recieve a HUP +signal, and should re-scan sysfs. File descriptors for devices no +longer in sysfs should be closed, and new devices should be opened and +handled. Is there a cleaner way to do this? In particular, re-scanning sysfs may cause race conditions (device removed, one of the same name re-added but a different UIO device node; probably more to be found). Perhaps recommend netlink uevents, so that remove+add is noticeable? Also, is the SIGHUP itself the best option? Could we simply require the user process to listen for add/remove uevents to get such change notifications, and thus enforce good behavior? Yes this sounds better, let's do it this way. One use case I'm actually interested in is having userspace provide something other than just SPC - for instance, tgt can provide a virtual tape library or an OSD, and CDemu can provide emulated optical discs from various image formats. Currently, CDemu uses its own out-of-tree driver called VHBA (Virtual Host Bus Adapter) to do pretty much exactly what TCMU+Loopback would accomplish... and in the process misses out on all of the other fabrics, unless you're willing to _re-import_ those devices using PSCSI, which has its own quirks. Perhaps there could be a level 0 (or 4, or whatever) which means explicitly enabled list of commands - maybe as a bitmap that could be passed to the kernel somehow? Hopefully, that could also avoid some of the quirks of PSCSI regarding ALUA and such - if it's not implemented, leave the relevant bits at zero, and LIO handles it. I'm beginning to sour on pass_level and having configurable cmd filtering in the kernel interface. I think a less-clever but simpler approach might be to eliminate filtering, and the user process can return CHECK_CONDITION, INVALID COMMAND OPERATION CODE for commands it doesn't wish to support. TCMU checks for this, and the pending command thus returned can still be emulated by LIO (it looks like we could just re-call sbc_parse_cdb and target_execute_cmd). This does look really nice, thanks for writing it! Thanks for your helpful feedback! :) -- Andy -- 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/8] Drivers: scsi: storvsc: Bug fixes and improvements
In this patch set I have fixed a few bugs and implemented some enhancements. K. Y. Srinivasan (8): Drivers: scsi: storvsc: Change the limits to reflect the values on the host Drivers: scsi: storvsc: Filter commands based on the storage protocol version Drivers: scsi: storvsc: Fix a bug in handling VMBUS protocol version Drivers: scsi: storvsc: Filter WRITE_SAME_16 Drivers: scsi: storvsc: Fix a bug in the handling of SRB status flags Drivers: scsi: storvsc: Implement an abort handler drivers: scsi: storvsc: Set srb_flags in all cases drivers: scsi: storvsc: Correctly handle TEST_UNIT_READY failure drivers/scsi/storvsc_drv.c | 125 --- 1 files changed, 93 insertions(+), 32 deletions(-) -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/8] Drivers: scsi: storvsc: Filter commands based on the storage protocol version
Going forward it is possible that some of the commands that are not currently
implemented will be implemented on future Windows hosts. Make command filtering
depend on the host version.
Signed-off-by: K. Y. Srinivasan k...@microsoft.com
Cc: sta...@vger.kernel.org
---
drivers/scsi/storvsc_drv.c | 11 ---
1 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
index 2e4131c..759853c 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -1556,9 +1556,14 @@ static int storvsc_queuecommand(struct Scsi_Host *host,
struct scsi_cmnd *scmnd)
struct vmscsi_request *vm_srb;
struct stor_mem_pools *memp = scmnd-device-hostdata;
- if (!storvsc_scsi_cmd_ok(scmnd)) {
- scmnd-scsi_done(scmnd);
- return 0;
+ if (vmstor_current_major = VMSTOR_WIN8_MAJOR) {
+ /*
+* On legacy hosts filter unimplemented commands.
+*/
+ if (!storvsc_scsi_cmd_ok(scmnd)) {
+ scmnd-scsi_done(scmnd);
+ return 0;
+ }
}
request_size = sizeof(struct storvsc_cmd_request);
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 8/8] drivers: scsi: storvsc: Correctly handle TEST_UNIT_READY failure
On some Windows hosts on FC SANs, TEST_UNIT_READY can return SRB_STATUS_ERROR. Correctly handle this. Signed-off-by: K. Y. Srinivasan k...@microsoft.com Cc: sta...@vger.kernel.org --- drivers/scsi/storvsc_drv.c |7 +++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c index 6540fb6..9afdd6d 100644 --- a/drivers/scsi/storvsc_drv.c +++ b/drivers/scsi/storvsc_drv.c @@ -1023,6 +1023,13 @@ static void storvsc_handle_error(struct vmscsi_request *vm_srb, case ATA_12: set_host_byte(scmnd, DID_PASSTHROUGH); break; + /* +* On Some Windows hosts TEST_UNIT_READY command can return +* SRB_STATUS_ERROR, let the upper level code deal with it +* based on the sense information. +*/ + case TEST_UNIT_READY: + break; default: set_host_byte(scmnd, DID_TARGET_FAILURE); } -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/8] Drivers: scsi: storvsc: Change the limits to reflect the values on the host
Hyper-V hosts can support multiple targets and multiple channels and larger
number of
LUNs per target. Update the code to reflect this. With this patch we can
correctly
enumerate all the paths in a multi-path storage environment.
Signed-off-by: K. Y. Srinivasan k...@microsoft.com
Cc: sta...@vger.kernel.org
---
drivers/scsi/storvsc_drv.c | 53 ---
1 files changed, 39 insertions(+), 14 deletions(-)
diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
index 9969fa1..2e4131c 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -331,16 +331,19 @@ static int storvsc_timeout = 180;
static void storvsc_on_channel_callback(void *context);
/*
- * In Hyper-V, each port/path/target maps to 1 scsi host adapter. In
- * reality, the path/target is not used (ie always set to 0) so our
- * scsi host adapter essentially has 1 bus with 1 target that contains
- * up to 256 luns.
+ * In Hyper-V, each port/path/target maps to 1 scsi host adapter.
*/
-#define STORVSC_MAX_LUNS_PER_TARGET64
-#define STORVSC_MAX_TARGETS1
-#define STORVSC_MAX_CHANNELS 1
+#define STORVSC_MAX_LUNS_PER_TARGET255
+#define STORVSC_MAX_TARGETS2
+#define STORVSC_MAX_CHANNELS 8
+#define STORVSC_FC_MAX_LUNS_PER_TARGET 255
+#define STORVSC_FC_MAX_TARGETS 128
+#define STORVSC_FC_MAX_CHANNELS8
+#define STORVSC_IDE_MAX_LUNS_PER_TARGET64
+#define STORVSC_IDE_MAX_TARGETS1
+#define STORVSC_IDE_MAX_CHANNELS 1
struct storvsc_cmd_request {
struct list_head entry;
@@ -1690,7 +1693,7 @@ static struct scsi_host_template scsi_driver = {
.slave_alloc = storvsc_device_alloc,
.slave_destroy =storvsc_device_destroy,
.slave_configure = storvsc_device_configure,
- .cmd_per_lun = 1,
+ .cmd_per_lun = 255,
/* 64 max_queue * 1 target */
.can_queue =STORVSC_MAX_IO_REQUESTS*STORVSC_MAX_TARGETS,
.this_id = -1,
@@ -1789,12 +1792,34 @@ static int storvsc_probe(struct hv_device *device,
host_dev-path = stor_device-path_id;
host_dev-target = stor_device-target_id;
- /* max # of devices per target */
- host-max_lun = STORVSC_MAX_LUNS_PER_TARGET;
- /* max # of targets per channel */
- host-max_id = STORVSC_MAX_TARGETS;
- /* max # of channels */
- host-max_channel = STORVSC_MAX_CHANNELS - 1;
+ switch (dev_id-driver_data) {
+ case SFC_GUID:
+ /* max # of devices per target */
+ host-max_lun = STORVSC_FC_MAX_LUNS_PER_TARGET;
+ /* max # of targets per channel */
+ host-max_id = STORVSC_FC_MAX_TARGETS;
+ /* max # of channels */
+ host-max_channel = STORVSC_FC_MAX_CHANNELS - 1;
+ break;
+
+ case SCSI_GUID:
+ /* max # of devices per target */
+ host-max_lun = STORVSC_MAX_LUNS_PER_TARGET;
+ /* max # of targets per channel */
+ host-max_id = STORVSC_MAX_TARGETS;
+ /* max # of channels */
+ host-max_channel = STORVSC_MAX_CHANNELS - 1;
+ break;
+
+ default:
+ /* max # of devices per target */
+ host-max_lun = STORVSC_IDE_MAX_LUNS_PER_TARGET;
+ /* max # of targets per channel */
+ host-max_id = STORVSC_IDE_MAX_TARGETS;
+ /* max # of channels */
+ host-max_channel = STORVSC_IDE_MAX_CHANNELS - 1;
+ break;
+ }
/* max cmd length */
host-max_cmd_len = STORVSC_MAX_CMD_LEN;
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/8] Drivers: scsi: storvsc: Fix a bug in the handling of SRB status flags
SRB status can have additional information. Mask these out before processing
SRB status.
Signed-off-by: K. Y. Srinivasan k...@microsoft.com
Cc: sta...@vger.kernel.org
---
drivers/scsi/storvsc_drv.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
index 428dbda..8f1b263 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -299,11 +299,14 @@ enum storvsc_request_type {
*/
#define SRB_STATUS_AUTOSENSE_VALID 0x80
+#define SRB_STATUS_QUEUE_FROZEN0x40
#define SRB_STATUS_INVALID_LUN 0x20
#define SRB_STATUS_SUCCESS 0x01
#define SRB_STATUS_ABORTED 0x02
#define SRB_STATUS_ERROR 0x04
+#define SRB_STATUS(status) \
+ (status ~(SRB_STATUS_AUTOSENSE_VALID | SRB_STATUS_QUEUE_FROZEN))
/*
* This is the end of Protocol specific defines.
*/
@@ -1007,7 +1010,7 @@ static void storvsc_handle_error(struct vmscsi_request
*vm_srb,
void (*process_err_fn)(struct work_struct *work);
bool do_work = false;
- switch (vm_srb-srb_status) {
+ switch (SRB_STATUS(vm_srb-srb_status)) {
case SRB_STATUS_ERROR:
/*
* If there is an error; offline the device since all
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/8] Drivers: scsi: storvsc: Fix a bug in handling VMBUS protocol version
Based on the negotiated VMBUS protocol version, we adjust the size of the
storage
protocol messages. The two sizes we currently handle or pre-win8 and post-win8.
Win WS2012 R2, we are negotiating higher VMBUS protocol version than the win8
version. Make adjustments to correctly handle this.
Signed-off-by: K. Y. Srinivasan k...@microsoft.com
Cc: sta...@vger.kernel.org
---
drivers/scsi/storvsc_drv.c | 14 +++---
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
index 759853c..d9d8051 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -1751,19 +1751,19 @@ static int storvsc_probe(struct hv_device *device,
* set state to properly communicate with the host.
*/
- if (vmbus_proto_version == VERSION_WIN8) {
- sense_buffer_size = POST_WIN7_STORVSC_SENSE_BUFFER_SIZE;
- vmscsi_size_delta = 0;
- vmstor_current_major = VMSTOR_WIN8_MAJOR;
- vmstor_current_minor = VMSTOR_WIN8_MINOR;
- } else {
+ if ((vmbus_proto_version == VERSION_WS2008) ||
+(vmbus_proto_version == VERSION_WIN7)) {
sense_buffer_size = PRE_WIN8_STORVSC_SENSE_BUFFER_SIZE;
vmscsi_size_delta = sizeof(struct vmscsi_win8_extension);
vmstor_current_major = VMSTOR_WIN7_MAJOR;
vmstor_current_minor = VMSTOR_WIN7_MINOR;
+ } else {
+ sense_buffer_size = POST_WIN7_STORVSC_SENSE_BUFFER_SIZE;
+ vmscsi_size_delta = 0;
+ vmstor_current_major = VMSTOR_WIN8_MAJOR;
+ vmstor_current_minor = VMSTOR_WIN8_MINOR;
}
-
host = scsi_host_alloc(scsi_driver,
sizeof(struct hv_host_device));
if (!host)
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/8] Drivers: scsi: storvsc: Implement an abort handler
Implement a simple abort handler. The host does not support Abort; just
ensure that all inflight I/Os have been accounted for.
Signed-off-by: K. Y. Srinivasan k...@microsoft.com
---
drivers/scsi/storvsc_drv.c | 22 ++
1 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
index 8f1b263..82fb590 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -1524,6 +1524,27 @@ static int storvsc_host_reset_handler(struct scsi_cmnd
*scmnd)
return SUCCESS;
}
+static int storvsc_host_abort_handler(struct scsi_cmnd *scmnd)
+{
+ struct hv_host_device *host_dev = shost_priv(scmnd-device-host);
+ struct hv_device *device = host_dev-dev;
+
+ struct storvsc_device *stor_device;
+
+
+ stor_device = get_out_stor_device(device);
+ if (!stor_device)
+ return FAILED;
+
+ /*
+* Just wait for all in flight I/O's to complete.
+*/
+
+ storvsc_wait_to_drain(stor_device);
+
+ return SUCCESS;
+}
+
static bool storvsc_scsi_cmd_ok(struct scsi_cmnd *scmnd)
{
bool allowed = true;
@@ -1699,6 +1720,7 @@ static struct scsi_host_template scsi_driver = {
.bios_param = storvsc_get_chs,
.queuecommand = storvsc_queuecommand,
.eh_host_reset_handler =storvsc_host_reset_handler,
+ .eh_abort_handler = storvsc_host_abort_handler,
.slave_alloc = storvsc_device_alloc,
.slave_destroy =storvsc_device_destroy,
.slave_configure = storvsc_device_configure,
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 7/8] drivers: scsi: storvsc: Set srb_flags in all cases
Correctly set SRB flags for all valid I/O directions. Some IHV drivers on the
Windows host require this.
Signed-off-by: K. Y. Srinivasan k...@microsoft.com
Cc: sta...@vger.kernel.org
---
drivers/scsi/storvsc_drv.c | 12 +---
1 files changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
index 82fb590..6540fb6 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -1613,26 +1613,24 @@ static int storvsc_queuecommand(struct Scsi_Host *host,
struct scsi_cmnd *scmnd)
vm_srb = cmd_request-vstor_packet.vm_srb;
vm_srb-win8_extension.time_out_value = 60;
+ vm_srb-win8_extension.srb_flags |=
+ (SRB_FLAGS_QUEUE_ACTION_ENABLE |
+ SRB_FLAGS_DISABLE_SYNCH_TRANSFER);
/* Build the SRB */
switch (scmnd-sc_data_direction) {
case DMA_TO_DEVICE:
vm_srb-data_in = WRITE_TYPE;
vm_srb-win8_extension.srb_flags |= SRB_FLAGS_DATA_OUT;
- vm_srb-win8_extension.srb_flags |=
- (SRB_FLAGS_QUEUE_ACTION_ENABLE |
- SRB_FLAGS_DISABLE_SYNCH_TRANSFER);
break;
case DMA_FROM_DEVICE:
vm_srb-data_in = READ_TYPE;
vm_srb-win8_extension.srb_flags |= SRB_FLAGS_DATA_IN;
- vm_srb-win8_extension.srb_flags |=
- (SRB_FLAGS_QUEUE_ACTION_ENABLE |
- SRB_FLAGS_DISABLE_SYNCH_TRANSFER);
break;
default:
vm_srb-data_in = UNKNOWN_TYPE;
- vm_srb-win8_extension.srb_flags = 0;
+ vm_srb-win8_extension.srb_flags |= (SRB_FLAGS_DATA_IN |
+SRB_FLAGS_DATA_OUT);
break;
}
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/8] Drivers: scsi: storvsc: Filter WRITE_SAME_16
Host does not handle WRITE_SAME_16; filter this command out. This patch
is required to handle large devices (greater than 2 TB disks).
Signed-off-by: K. Y. Srinivasan k...@microsoft.com
Cc: sta...@vger.kernel.org
---
drivers/scsi/storvsc_drv.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
index d9d8051..428dbda 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -1529,6 +1529,7 @@ static bool storvsc_scsi_cmd_ok(struct scsi_cmnd *scmnd)
switch (scsi_op) {
/* the host does not handle WRITE_SAME, log accident usage */
case WRITE_SAME:
+ case WRITE_SAME_16:
/*
* smartd sends this command and the host does not handle
* this. So, don't send it.
--
1.7.4.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
Re: uas - kernel panic on drive connection
Hans, could you comment on this? Thanks. Jonathan -- 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 5/6] scsi: use 64-bit value for 'max_luns'
Christoph Hellwig h...@infradead.org writes: On Tue, Jun 03, 2014 at 10:58:56AM +0200, Hannes Reinecke wrote: Now that we're using 64-bit LUNs internally we need to increase the size of max_luns to 64 bits, too. Signed-off-by: Hannes Reinecke h...@suse.de Reviewed-by: Christoph Hellwig h...@infradead.org Reviewed-by: Ewan Milne emi...@redhat.com I just noticed that this has changes to the module param code. These should be split into a separate patch and be ACKed by the modules maintainer. I'd still love to take the change through the SCSI tree to be able to get this into 3.17 easily. moduleparam changes below: diff --git a/include/linux/moduleparam.h b/include/linux/moduleparam.h index 204a677..21e2ba6 100644 --- a/include/linux/moduleparam.h +++ b/include/linux/moduleparam.h @@ -381,6 +381,11 @@ extern int param_set_ulong(const char *val, const struct kernel_param *kp); extern int param_get_ulong(char *buffer, const struct kernel_param *kp); #define param_check_ulong(name, p) __param_check(name, p, unsigned long) +extern struct kernel_param_ops param_ops_ullong; +extern int param_set_ullong(const char *val, const struct kernel_param *kp); +extern int param_get_ullong(char *buffer, const struct kernel_param *kp); +#define param_check_ullong(name, p) __param_check(name, p, unsigned long long) + extern struct kernel_param_ops param_ops_charp; extern int param_set_charp(const char *val, const struct kernel_param *kp); extern int param_get_charp(char *buffer, const struct kernel_param *kp); diff --git a/kernel/params.c b/kernel/params.c index b00142e..2b2a9dd 100644 --- a/kernel/params.c +++ b/kernel/params.c @@ -253,6 +253,7 @@ STANDARD_PARAM_DEF(int, int, %i, kstrtoint); STANDARD_PARAM_DEF(uint, unsigned int, %u, kstrtouint); STANDARD_PARAM_DEF(long, long, %li, kstrtol); STANDARD_PARAM_DEF(ulong, unsigned long, %lu, kstrtoul); +STANDARD_PARAM_DEF(ullong, unsigned long long, %llu, kstrtoull); Thanks Christoph! Acked-by: Rusty Russell ru...@rustcorp.com.au Cheers, Rusty. -- 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: dummy scsi read or scsi command periodically for external USB Hard Disk
hi Alan: 2014-07-09 3:26 GMT+08:00 Alan Stern st...@rowland.harvard.edu: On Wed, 9 Jul 2014, loody wrote: there is one thing pop in my mind. if events_poll_msecs is used for media_change, shouldn't we wrap is READ10? No. Why should media change polling use READ(10)? TEST UNIT READY does a good job of detecting media changes. the difference seems 1. change SCSI command 2. allocate 512 Byte for 1 sector dummy read the periodically trigging flow should be the same. if you think above is possible, where we should start from? Why do you want to make this change? on that usb hard disk, no matter media_change or TEST_UNIT_READY, keep polling the device every 3mins. the disconnection still happen. So I am wondering, I can use the existence wheel, such as echo 4 /sys/block/sda/events_poll_ msecs. but what it really do is read sector, not media_change or test_unit_ready. thanks for your kind help -- 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
