Re: [PATCH 1/2] Convert target drivers to use sbitmap
On 5/15/18 10:11 AM, Jens Axboe wrote: > On 5/15/18 10:00 AM, Matthew Wilcox wrote: >> From: Matthew Wilcox <mawil...@microsoft.com> >> >> The sbitmap and the percpu_ida perform essentially the same task, >> allocating tags for commands. Since the sbitmap is more used than >> the percpu_ida, convert the percpu_ida users to the sbitmap API. > > It should also be the same performance as percpu_ida in light use, and > performs much better at > 50% utilization of the tag space. I think > that's better justification than "more used than". Had to search long and hard for the perf numbers I did for percpu_ida on higher utilization, but here it is: https://lkml.org/lkml/2014/4/22/553 -- Jens Axboe -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] Convert target drivers to use sbitmap
On 5/15/18 10:00 AM, Matthew Wilcox wrote:
> From: Matthew Wilcox <mawil...@microsoft.com>
>
> The sbitmap and the percpu_ida perform essentially the same task,
> allocating tags for commands. Since the sbitmap is more used than
> the percpu_ida, convert the percpu_ida users to the sbitmap API.
It should also be the same performance as percpu_ida in light use, and
performs much better at > 50% utilization of the tag space. I think
that's better justification than "more used than".
> diff --git a/drivers/target/iscsi/iscsi_target_util.c
> b/drivers/target/iscsi/iscsi_target_util.c
> index 4435bf374d2d..28bcffae609f 100644
> --- a/drivers/target/iscsi/iscsi_target_util.c
> +++ b/drivers/target/iscsi/iscsi_target_util.c
> @@ -17,7 +17,7 @@
>
> **/
>
> #include
> -#include
> +#include
> #include /* ipv6_addr_equal() */
> #include
> #include
> @@ -147,6 +147,28 @@ void iscsit_free_r2ts_from_list(struct iscsi_cmd *cmd)
> spin_unlock_bh(>r2t_lock);
> }
>
> +int iscsit_wait_for_tag(struct se_session *se_sess, int state, int *cpup)
> +{
> + int tag = -1;
> + DEFINE_WAIT(wait);
> + struct sbq_wait_state *ws;
> +
> + if (state == TASK_RUNNING)
> + return tag;
> +
> + ws = _sess->sess_tag_pool.ws[0];
> + for (;;) {
> + prepare_to_wait_exclusive(>wait, , state);
> + if (signal_pending_state(state, current))
> + break;
> + schedule();
> + tag = sbitmap_queue_get(_sess->sess_tag_pool, cpup);
> + }
> +
> + finish_wait(>wait, );
> + return tag;
> +}
Seems like that should be:
ws = _sess->sess_tag_pool.ws[0];
for (;;) {
prepare_to_wait_exclusive(>wait, , state);
if (signal_pending_state(state, current))
break;
tag = sbitmap_queue_get(_sess->sess_tag_pool, cpup);
if (tag != -1)
break;
schedule();
}
finish_wait(>wait, );
return tag;
> /*
> * May be called from software interrupt (timer) context for allocating
> * iSCSI NopINs.
> @@ -155,9 +177,11 @@ struct iscsi_cmd *iscsit_allocate_cmd(struct iscsi_conn
> *conn, int state)
> {
> struct iscsi_cmd *cmd;
> struct se_session *se_sess = conn->sess->se_sess;
> - int size, tag;
> + int size, tag, cpu;
>
> - tag = percpu_ida_alloc(_sess->sess_tag_pool, state);
> + tag = sbitmap_queue_get(_sess->sess_tag_pool, );
> + if (tag < 0)
> + tag = iscsit_wait_for_tag(se_sess, state, );
> if (tag < 0)
> return NULL;
Might make sense to just roll the whole thing into iscsi_get_tag(), that
would be cleaner.
sbitmap should provide a helper for that, but we can do that cleanup
later. That would encapsulate things like the per-cpu caching hint too,
for instance.
Rest looks fine to me.
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] aio: remove retry and cancel
On 2012-10-16 19:15, Benjamin LaHaise wrote: On Tue, Oct 16, 2012 at 10:00:54AM -0700, Zach Brown wrote: Not all IOs will complete within a bounded amount of time. Think of things like pipes, network send/receive, even the USB gadget code. Yes, I know. That's the theoretical position. But reality doesn't match that view. People aren't using it. If the But that's an issue of the lack of support for the functionality. The kernel doesn't implement the functionality for 99.99% of file descriptors, so of course it's not going to be used. If, as we were chatting about, other uses can be made possible by using a thread pool or some as yet undecided approach, it will be required. Let's address the lack of support issue before deprecating required parts of the API. Or make the case to rip everything out. Come on, this has been the case for, what, 10 years? Or for however long that we've had this aio interface. I'd be happy just bypassing the cancel, in fact I did just that to actually make aio scale to any extent at all. But using the lack of a support as an argument to keep that interface is just a non-starter to begin with. It's clearly NEVER goint to get done. usb gadget code can do without then the actual users of aio can be made a wee bit faster without having to build cancel code without users to hammer on it. Gadget cannot. The code has no control over when a request completes. Think of things like talking to a USB serial port or keyboard directly. Afaik it is getting used for USB direct access in a number of cases, which goes to show that if the functionality is implemented, people will use it. IMHO, just bypassing the cancel bits for things that don't implement it (that is, anything but usb gadget) is trivial. It's part of the lots of low hanging fruit in aio. -- Jens Axboe -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] 2.6.24-git usb reset problems
On Wed, Jan 30 2008, James Bottomley wrote: On Wed, 2008-01-30 at 11:38 +0100, Jens Axboe wrote: On Wed, Jan 30 2008, Geert Uytterhoeven wrote: On Tue, 29 Jan 2008, Jens Axboe wrote: On Tue, Jan 29 2008, Jens Axboe wrote: On Tue, Jan 29 2008, James Bottomley wrote: On Tue, 2008-01-29 at 11:10 -0800, Matthew Dharm wrote: For some reason, usb_sg_init is boned during auto-sense. OK, that's implicating the scsi_eh_prep_cmnd() in the auto sense code ... that was also an update in 2.6.24 yeah, already found the bug - it's assuming -request_buffer holds the sglist, oops. Preparing a fix. ok here goes, this saves and restores the sg table correctly. it also fixes the usb bug for me. I can confirm this patch fixes the errors I was seeing with current linux-2.6.git for the USB memory card readers in a Dell TFT connected to a PS3. James, we need a fix for this pushed asap. So either we should merge the below now, or push the bidi patchset that also fixes this. It all depends on when you want to merge the bidi patches... The SCSI patch set (including the bidirectional pieces) is waiting in scsi-misc ... just for forms sake, could you confirm that it actually fixes the problem and I'll push it. Certainly, I'll give it a spin tonight. -- Jens Axboe - To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] 2.6.24-git usb reset problems
On Wed, Jan 30 2008, Jens Axboe wrote: On Wed, Jan 30 2008, James Bottomley wrote: On Wed, 2008-01-30 at 11:38 +0100, Jens Axboe wrote: On Wed, Jan 30 2008, Geert Uytterhoeven wrote: On Tue, 29 Jan 2008, Jens Axboe wrote: On Tue, Jan 29 2008, Jens Axboe wrote: On Tue, Jan 29 2008, James Bottomley wrote: On Tue, 2008-01-29 at 11:10 -0800, Matthew Dharm wrote: For some reason, usb_sg_init is boned during auto-sense. OK, that's implicating the scsi_eh_prep_cmnd() in the auto sense code ... that was also an update in 2.6.24 yeah, already found the bug - it's assuming -request_buffer holds the sglist, oops. Preparing a fix. ok here goes, this saves and restores the sg table correctly. it also fixes the usb bug for me. I can confirm this patch fixes the errors I was seeing with current linux-2.6.git for the USB memory card readers in a Dell TFT connected to a PS3. James, we need a fix for this pushed asap. So either we should merge the below now, or push the bidi patchset that also fixes this. It all depends on when you want to merge the bidi patches... The SCSI patch set (including the bidirectional pieces) is waiting in scsi-misc ... just for forms sake, could you confirm that it actually fixes the problem and I'll push it. Certainly, I'll give it a spin tonight. Confirmed, pulling your scsi-misc branch into current -git makes the problem go away as well. -- Jens Axboe - To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] 2.6.24-git usb reset problems
On Tue, Jan 29 2008, Boaz Harrosh wrote: Greg KH wrote: On Mon, Jan 28, 2008 at 09:49:35PM +0100, Jens Axboe wrote: Hi, Running latest -git (head 91525300baf162e83e923b09ca286f9205e21522) and connecting my cf usb storage device yields and endless stream of: Initializing USB Mass Storage driver... scsi6 : SCSI emulation for USB Mass Storage devices usb-storage: device found at 2 usb-storage: waiting for device to settle before scanning usbcore: registered new interface driver usb-storage USB Mass Storage support registered. scsi 6:0:0:0: Direct-Access Generic STORAGE DEVICE 0125 PQ: 0 ANSI: 0 sd 6:0:0:0: [sdb] 4001760 512-byte hardware sectors (2049 MB) sd 6:0:0:0: [sdb] Write Protect is off sd 6:0:0:0: [sdb] Mode Sense: 02 00 00 00 sd 6:0:0:0: [sdb] Assuming drive cache: write through sd 6:0:0:0: [sdb] 4001760 512-byte hardware sectors (2049 MB) sd 6:0:0:0: [sdb] Write Protect is off sd 6:0:0:0: [sdb] Mode Sense: 02 00 00 00 sd 6:0:0:0: [sdb] Assuming drive cache: write through sdb: sdb1 sd 6:0:0:0: [sdb] Attached SCSI removable disk sd 6:0:0:0: Attached scsi generic sg1 type 0 scsi 6:0:0:1: Direct-Access Generic STORAGE DEVICE 0125 PQ: 0 ANSI: 0 usb 5-1: reset high speed USB device using ehci_hcd and address 2 usb 5-1: reset high speed USB device using ehci_hcd and address 2 usb 5-1: reset high speed USB device using ehci_hcd and address 2 usb 5-1: reset high speed USB device using ehci_hcd and address 2 usb 5-1: reset high speed USB device using ehci_hcd and address 2 usb 5-1: reset high speed USB device using ehci_hcd and address 2 usb 5-1: reset high speed USB device using ehci_hcd and address 2 [...] until I disconnect it. The device doesn't work. Worked fine in 2.6.24. I'm attaching boot messages and my .config. That's a bit wierd, as we haven't added any USB patches to the -git tree yet after 2.6.24 :) Could this be caused by some scsi changes perhaps? thanks, greg k-h - Yes it is ;) Jens could you test the patch below? if it works I'll submit a proper patch. Please forgive me for the bug. No difference, still just a lot of resets. -- Jens Axboe - To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] 2.6.24-git usb reset problems
On Tue, Jan 29 2008, Jens Axboe wrote: On Tue, Jan 29 2008, Matthew Dharm wrote: On Tue, Jan 29, 2008 at 07:39:11PM +0100, Jens Axboe wrote: On Tue, Jan 29 2008, Jens Axboe wrote: On Tue, Jan 29 2008, Oliver Neukum wrote: Am Dienstag, 29. Januar 2008 15:11:08 schrieb Jens Axboe: On Tue, Jan 29 2008, Boaz Harrosh wrote: On Tue, Jan 29 2008 at 15:54 +0200, Jens Axboe [EMAIL PROTECTED] wrote: On Tue, Jan 29 2008, Boaz Harrosh wrote: Greg KH wrote: No difference, still just a lot of resets. Where you able to figure out which usb storage transport is used? in drivers/usb/storage/usb.c you have get_protocol() and get_transport() functions. I'm not sure if these get stored in sysfs perhaps. This will pinpoint better where to look. Let me research a bit. Did the quick'n easy and dumped it. Protocol is 'Transparent SCSI' and transport is 'Bulk' You can recompile your kernel with CONFIG_USB_DEBUG and CONFIG_STORAGE_DEBUG That should tell the reason for the resets. Sure, I'll do that. Will post the results tonight. OK, fresh boot with CONFIG_USB_DEBUG and CONFIG_STORAGE_DEBUG. Plugged in the device, waited 10 seconds or so and pulled it out. These are the messages. It all looks good until the MODE_SENSE command, where it only transfers 4 of 192 bytes. No, that's not the problem. This is the problem: It's where the problem starts, otherwise there would not be a need to sense :-) usb-storage: *** thread awakened. usb-storage: Command TEST_UNIT_READY (6 bytes) usb-storage: 00 00 00 00 00 00 usb-storage: Bulk Command S 0x43425355 T 0xd L 0 F 0 Trg 0 LUN 1 CL 6 usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes usb-storage: Status code 0; transferred 31/31 usb-storage: -- transfer complete usb-storage: Bulk command transfer result=0 usb-storage: Attempting to get CSW... usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes usb-storage: Status code 0; transferred 13/13 usb-storage: -- transfer complete usb-storage: Bulk status result = 0 usb-storage: Bulk Status S 0x53425355 T 0xd R 0 Stat 0x1 usb-storage: -- transport indicates command failure usb-storage: Issuing auto-REQUEST_SENSE usb-storage: Bulk Command S 0x43425355 T 0xe L 18 F 128 Trg 0 LUN 1 CL 6 usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes usb-storage: Status code 0; transferred 31/31 usb-storage: -- transfer complete usb-storage: Bulk command transfer result=0 usb-storage: usb_stor_bulk_transfer_sglist: xfer 18 bytes, 1 entries usb-storage: usb_sg_init returned -22 usb-storage: Bulk data transfer result 0x4 usb-storage: -- auto-sense failure usb-storage: storage_pre_reset ehci_hcd :00:1d.7: port 1 high speed ehci_hcd :00:1d.7: GetStatus port 1 status 001005 POWER sig=se0 PE CONNECT usb 5-1: reset high speed USB device using ehci_hcd and address 2 ehci_hcd :00:1d.7: port 1 high speed ehci_hcd :00:1d.7: GetStatus port 1 status 001005 POWER sig=se0 PE CONNECT usb-storage: storage_post_reset usb-storage: usb_reset_composite_device returns 0 usb-storage: scsi cmd done, result=0x7 usb-storage: *** thread sleeping. For some reason, usb_sg_init is boned during auto-sense. My guess would be that sg == NULL, hence the -EINVAL. Yep, trace below: WARNING: at drivers/usb/storage/transport.c:426 usb_stor_bulk_transfer_sglist() Pid: 12536, comm: usb-storage Not tainted 2.6.24 #74 [7810541a] show_trace_log_lvl+0x1a/0x30 [78105e82] show_trace+0x12/0x20 [7810689c] dump_stack+0x6c/0x80 [f83e267e] usb_stor_bulk_transfer_sglist+0x14e/0x160 [usb_storage] [f83e2730] usb_stor_bulk_srb_length+0x30/0x50 [usb_storage] [f83e2762] usb_stor_bulk_srb+0x12/0x20 [usb_storage] [f83e2ce0] usb_stor_Bulk_transport+0x190/0x3d0 [usb_storage] [f83e30d6] usb_stor_invoke_transport+0x1b6/0x320 [usb_storage] [f83e1a38] usb_stor_transparent_scsi_command+0x8/0x10 [usb_storage] [f83e3813] usb_stor_control_thread+0x143/0x2c0 [usb_storage] [7813bc02] kthread+0x42/0x70 [78104fab] kernel_thread_helper+0x7/0x1c === usb-storage: usb_stor_bulk_transfer_sglist: xfer 18 bytes, 1 entries, sg usb-storage: usb_sg_init returned -22 -- Jens Axboe - To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] 2.6.24-git usb reset problems
On Tue, Jan 29 2008, Matthew Dharm wrote: On Tue, Jan 29, 2008 at 07:39:11PM +0100, Jens Axboe wrote: On Tue, Jan 29 2008, Jens Axboe wrote: On Tue, Jan 29 2008, Oliver Neukum wrote: Am Dienstag, 29. Januar 2008 15:11:08 schrieb Jens Axboe: On Tue, Jan 29 2008, Boaz Harrosh wrote: On Tue, Jan 29 2008 at 15:54 +0200, Jens Axboe [EMAIL PROTECTED] wrote: On Tue, Jan 29 2008, Boaz Harrosh wrote: Greg KH wrote: No difference, still just a lot of resets. Where you able to figure out which usb storage transport is used? in drivers/usb/storage/usb.c you have get_protocol() and get_transport() functions. I'm not sure if these get stored in sysfs perhaps. This will pinpoint better where to look. Let me research a bit. Did the quick'n easy and dumped it. Protocol is 'Transparent SCSI' and transport is 'Bulk' You can recompile your kernel with CONFIG_USB_DEBUG and CONFIG_STORAGE_DEBUG That should tell the reason for the resets. Sure, I'll do that. Will post the results tonight. OK, fresh boot with CONFIG_USB_DEBUG and CONFIG_STORAGE_DEBUG. Plugged in the device, waited 10 seconds or so and pulled it out. These are the messages. It all looks good until the MODE_SENSE command, where it only transfers 4 of 192 bytes. No, that's not the problem. This is the problem: It's where the problem starts, otherwise there would not be a need to sense :-) usb-storage: *** thread awakened. usb-storage: Command TEST_UNIT_READY (6 bytes) usb-storage: 00 00 00 00 00 00 usb-storage: Bulk Command S 0x43425355 T 0xd L 0 F 0 Trg 0 LUN 1 CL 6 usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes usb-storage: Status code 0; transferred 31/31 usb-storage: -- transfer complete usb-storage: Bulk command transfer result=0 usb-storage: Attempting to get CSW... usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes usb-storage: Status code 0; transferred 13/13 usb-storage: -- transfer complete usb-storage: Bulk status result = 0 usb-storage: Bulk Status S 0x53425355 T 0xd R 0 Stat 0x1 usb-storage: -- transport indicates command failure usb-storage: Issuing auto-REQUEST_SENSE usb-storage: Bulk Command S 0x43425355 T 0xe L 18 F 128 Trg 0 LUN 1 CL 6 usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes usb-storage: Status code 0; transferred 31/31 usb-storage: -- transfer complete usb-storage: Bulk command transfer result=0 usb-storage: usb_stor_bulk_transfer_sglist: xfer 18 bytes, 1 entries usb-storage: usb_sg_init returned -22 usb-storage: Bulk data transfer result 0x4 usb-storage: -- auto-sense failure usb-storage: storage_pre_reset ehci_hcd :00:1d.7: port 1 high speed ehci_hcd :00:1d.7: GetStatus port 1 status 001005 POWER sig=se0 PE CONNECT usb 5-1: reset high speed USB device using ehci_hcd and address 2 ehci_hcd :00:1d.7: port 1 high speed ehci_hcd :00:1d.7: GetStatus port 1 status 001005 POWER sig=se0 PE CONNECT usb-storage: storage_post_reset usb-storage: usb_reset_composite_device returns 0 usb-storage: scsi cmd done, result=0x7 usb-storage: *** thread sleeping. For some reason, usb_sg_init is boned during auto-sense. My guess would be that sg == NULL, hence the -EINVAL. -- Jens Axboe - To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] 2.6.24-git usb reset problems
On Tue, Jan 29 2008, Jens Axboe wrote:
On Tue, Jan 29 2008, James Bottomley wrote:
On Tue, 2008-01-29 at 11:10 -0800, Matthew Dharm wrote:
On Tue, Jan 29, 2008 at 07:39:11PM +0100, Jens Axboe wrote:
On Tue, Jan 29 2008, Jens Axboe wrote:
On Tue, Jan 29 2008, Oliver Neukum wrote:
Am Dienstag, 29. Januar 2008 15:11:08 schrieb Jens Axboe:
On Tue, Jan 29 2008, Boaz Harrosh wrote:
On Tue, Jan 29 2008 at 15:54 +0200, Jens Axboe [EMAIL
PROTECTED] wrote:
On Tue, Jan 29 2008, Boaz Harrosh wrote:
Greg KH wrote:
No difference, still just a lot of resets.
Where you able to figure out which usb storage transport is
used?
in drivers/usb/storage/usb.c you have get_protocol() and
get_transport()
functions. I'm not sure if these get stored in sysfs perhaps.
This will
pinpoint better where to look. Let me research a bit.
Did the quick'n easy and dumped it. Protocol is 'Transparent
SCSI' and
transport is 'Bulk'
You can recompile your kernel with CONFIG_USB_DEBUG and
CONFIG_STORAGE_DEBUG
That should tell the reason for the resets.
Sure, I'll do that. Will post the results tonight.
OK, fresh boot with CONFIG_USB_DEBUG and CONFIG_STORAGE_DEBUG. Plugged
in the device, waited 10 seconds or so and pulled it out. These are the
messages.
It all looks good until the MODE_SENSE command, where it only transfers
4 of 192 bytes.
No, that's not the problem. This is the problem:
usb-storage: *** thread awakened.
usb-storage: Command TEST_UNIT_READY (6 bytes)
usb-storage: 00 00 00 00 00 00
usb-storage: Bulk Command S 0x43425355 T 0xd L 0 F 0 Trg 0 LUN 1 CL 6
usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes
usb-storage: Status code 0; transferred 31/31
usb-storage: -- transfer complete
usb-storage: Bulk command transfer result=0
usb-storage: Attempting to get CSW...
usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes
usb-storage: Status code 0; transferred 13/13
usb-storage: -- transfer complete
usb-storage: Bulk status result = 0
usb-storage: Bulk Status S 0x53425355 T 0xd R 0 Stat 0x1
usb-storage: -- transport indicates command failure
usb-storage: Issuing auto-REQUEST_SENSE
usb-storage: Bulk Command S 0x43425355 T 0xe L 18 F 128 Trg 0 LUN 1 CL 6
usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes
usb-storage: Status code 0; transferred 31/31
usb-storage: -- transfer complete
usb-storage: Bulk command transfer result=0
usb-storage: usb_stor_bulk_transfer_sglist: xfer 18 bytes, 1 entries
usb-storage: usb_sg_init returned -22
usb-storage: Bulk data transfer result 0x4
usb-storage: -- auto-sense failure
usb-storage: storage_pre_reset
ehci_hcd :00:1d.7: port 1 high speed
ehci_hcd :00:1d.7: GetStatus port 1 status 001005 POWER sig=se0 PE
CONNECT
usb 5-1: reset high speed USB device using ehci_hcd and address 2
ehci_hcd :00:1d.7: port 1 high speed
ehci_hcd :00:1d.7: GetStatus port 1 status 001005 POWER sig=se0 PE
CONNECT
usb-storage: storage_post_reset
usb-storage: usb_reset_composite_device returns 0
usb-storage: scsi cmd done, result=0x7
usb-storage: *** thread sleeping.
For some reason, usb_sg_init is boned during auto-sense.
OK, that's implicating the scsi_eh_prep_cmnd() in the auto sense
code ... that was also an update in 2.6.24
yeah, already found the bug - it's assuming -request_buffer holds the
sglist, oops. Preparing a fix.
ok here goes, this saves and restores the sg table correctly. it also
fixes the usb bug for me.
diff --git a/drivers/scsi/scsi_error.c b/drivers/scsi/scsi_error.c
index 547e85a..12770ef 100644
--- a/drivers/scsi/scsi_error.c
+++ b/drivers/scsi/scsi_error.c
@@ -622,13 +622,15 @@ void scsi_eh_prep_cmnd(struct scsi_cmnd *scmd, struct
scsi_eh_save *ses,
ses-use_sg = scmd-use_sg;
ses-resid = scmd-resid;
ses-result = scmd-result;
+ memcpy(ses-sense_sgl, scmd-sg_table, sizeof(ses-sense_sgl));
if (sense_bytes) {
scmd-request_bufflen = min_t(unsigned,
SCSI_SENSE_BUFFERSIZE, sense_bytes);
sg_init_one(ses-sense_sgl, scmd-sense_buffer,
scmd-request_bufflen);
- scmd-request_buffer = ses-sense_sgl;
+ scmd-sg_table.sgl = ses-sense_sgl;
+ scmd-sg_table.nents = scmd-sg_table.orig_nents = 1;
scmd-sc_data_direction = DMA_FROM_DEVICE;
scmd-use_sg = 1;
memset(scmd-cmnd, 0, sizeof(scmd-cmnd));
@@ -679,6 +681,7 @@ void scsi_eh_restore_cmnd(struct scsi_cmnd* scmd, struct
scsi_eh_save *ses)
scmd-request_bufflen
Re: [BUG] 2.6.24-git usb reset problems
On Tue, Jan 29 2008, Boaz Harrosh wrote:
On Tue, Jan 29 2008 at 21:45 +0200, Jens Axboe [EMAIL PROTECTED] wrote:
On Tue, Jan 29 2008, Jens Axboe wrote:
On Tue, Jan 29 2008, James Bottomley wrote:
On Tue, 2008-01-29 at 11:10 -0800, Matthew Dharm wrote:
On Tue, Jan 29, 2008 at 07:39:11PM +0100, Jens Axboe wrote:
On Tue, Jan 29 2008, Jens Axboe wrote:
On Tue, Jan 29 2008, Oliver Neukum wrote:
Am Dienstag, 29. Januar 2008 15:11:08 schrieb Jens Axboe:
On Tue, Jan 29 2008, Boaz Harrosh wrote:
On Tue, Jan 29 2008 at 15:54 +0200, Jens Axboe [EMAIL PROTECTED]
wrote:
On Tue, Jan 29 2008, Boaz Harrosh wrote:
Greg KH wrote:
No difference, still just a lot of resets.
Where you able to figure out which usb storage transport is used?
in drivers/usb/storage/usb.c you have get_protocol() and
get_transport()
functions. I'm not sure if these get stored in sysfs perhaps. This
will
pinpoint better where to look. Let me research a bit.
Did the quick'n easy and dumped it. Protocol is 'Transparent SCSI'
and
transport is 'Bulk'
You can recompile your kernel with CONFIG_USB_DEBUG and
CONFIG_STORAGE_DEBUG
That should tell the reason for the resets.
Sure, I'll do that. Will post the results tonight.
OK, fresh boot with CONFIG_USB_DEBUG and CONFIG_STORAGE_DEBUG. Plugged
in the device, waited 10 seconds or so and pulled it out. These are the
messages.
It all looks good until the MODE_SENSE command, where it only transfers
4 of 192 bytes.
No, that's not the problem. This is the problem:
usb-storage: *** thread awakened.
usb-storage: Command TEST_UNIT_READY (6 bytes)
usb-storage: 00 00 00 00 00 00
usb-storage: Bulk Command S 0x43425355 T 0xd L 0 F 0 Trg 0 LUN 1 CL 6
usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes
usb-storage: Status code 0; transferred 31/31
usb-storage: -- transfer complete
usb-storage: Bulk command transfer result=0
usb-storage: Attempting to get CSW...
usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes
usb-storage: Status code 0; transferred 13/13
usb-storage: -- transfer complete
usb-storage: Bulk status result = 0
usb-storage: Bulk Status S 0x53425355 T 0xd R 0 Stat 0x1
usb-storage: -- transport indicates command failure
usb-storage: Issuing auto-REQUEST_SENSE
usb-storage: Bulk Command S 0x43425355 T 0xe L 18 F 128 Trg 0 LUN 1 CL 6
usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes
usb-storage: Status code 0; transferred 31/31
usb-storage: -- transfer complete
usb-storage: Bulk command transfer result=0
usb-storage: usb_stor_bulk_transfer_sglist: xfer 18 bytes, 1 entries
usb-storage: usb_sg_init returned -22
usb-storage: Bulk data transfer result 0x4
usb-storage: -- auto-sense failure
usb-storage: storage_pre_reset
ehci_hcd :00:1d.7: port 1 high speed
ehci_hcd :00:1d.7: GetStatus port 1 status 001005 POWER sig=se0 PE
CONNECT
usb 5-1: reset high speed USB device using ehci_hcd and address 2
ehci_hcd :00:1d.7: port 1 high speed
ehci_hcd :00:1d.7: GetStatus port 1 status 001005 POWER sig=se0 PE
CONNECT
usb-storage: storage_post_reset
usb-storage: usb_reset_composite_device returns 0
usb-storage: scsi cmd done, result=0x7
usb-storage: *** thread sleeping.
For some reason, usb_sg_init is boned during auto-sense.
OK, that's implicating the scsi_eh_prep_cmnd() in the auto sense
code ... that was also an update in 2.6.24
yeah, already found the bug - it's assuming -request_buffer holds the
sglist, oops. Preparing a fix.
ok here goes, this saves and restores the sg table correctly. it also
fixes the usb bug for me.
diff --git a/drivers/scsi/scsi_error.c b/drivers/scsi/scsi_error.c
index 547e85a..12770ef 100644
--- a/drivers/scsi/scsi_error.c
+++ b/drivers/scsi/scsi_error.c
@@ -622,13 +622,15 @@ void scsi_eh_prep_cmnd(struct scsi_cmnd *scmd, struct
scsi_eh_save *ses,
ses-use_sg = scmd-use_sg;
ses-resid = scmd-resid;
ses-result = scmd-result;
+ memcpy(ses-sense_sgl, scmd-sg_table, sizeof(ses-sense_sgl));
if (sense_bytes) {
scmd-request_bufflen = min_t(unsigned,
SCSI_SENSE_BUFFERSIZE, sense_bytes);
sg_init_one(ses-sense_sgl, scmd-sense_buffer,
scmd-request_bufflen);
- scmd-request_buffer = ses-sense_sgl;
+ scmd-sg_table.sgl = ses-sense_sgl;
+ scmd-sg_table.nents = scmd-sg_table.orig_nents = 1;
scmd-sc_data_direction = DMA_FROM_DEVICE;
scmd-use_sg = 1;
memset(scmd-cmnd, 0, sizeof(scmd-cmnd));
@@ -679,6 +681,7 @@ void scsi_eh_restore_cmnd(struct scsi_cmnd* scmd,
struct scsi_eh_save *ses)
scmd-request_bufflen = ses-bufflen;
scmd-request_buffer = ses-buffer;
scmd-use_sg = ses-use_sg;
+ memcpy(scmd-sg_table, ses-sg_table, sizeof(scmd-sg_table
