* Maximum data size in a single transfer for MS driver @ 2010-02-17 12:37 Ramya Desai [not found] ` <3e7aae31002170437i52ba4ba1w10c1ff224d9b37ef-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 0 siblings, 1 reply; 40+ messages in thread From: Ramya Desai @ 2010-02-17 12:37 UTC (permalink / raw) To: USB list, linux-scsi-u79uwXL29TY76Z2rM5mHXA; +Cc: Greg KH, Alan Stern Dear All, What is the number of maximum sectors that SCSI can send to MS driver in a single data transfer? I changed the max_sectors in struct scsi_host_template usb_stor_host_template structure to 2048. Still, SCSI is sending 1024 sectors (512 KB) in a single data transfer. I know that my device supports 1 MB data in a sigle transfer. How can I change this to 1 MB? Thanks and Regards, RD -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 40+ messages in thread
[parent not found: <3e7aae31002170437i52ba4ba1w10c1ff224d9b37ef-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: Maximum data size in a single transfer for MS driver [not found] ` <3e7aae31002170437i52ba4ba1w10c1ff224d9b37ef-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> @ 2010-02-17 15:02 ` James Bottomley 2010-02-18 8:46 ` Ramya Desai 0 siblings, 1 reply; 40+ messages in thread From: James Bottomley @ 2010-02-17 15:02 UTC (permalink / raw) To: Ramya Desai Cc: USB list, linux-scsi-u79uwXL29TY76Z2rM5mHXA, Greg KH, Alan Stern On Wed, 2010-02-17 at 18:07 +0530, Ramya Desai wrote: > What is the number of maximum sectors that SCSI can send to MS driver > in a single data transfer? I have no idea what the MS driver is, so it's impossible to answer specifically. Generically, for drivers that expect a contiguous sg list, then 128 elements (512k) is the maximum. For drivers updated to use the sg chaining API (which is at least all of those in drivers/scsi), there is no maximum except what the hardware is limited to. > I changed the max_sectors in struct scsi_host_template > usb_stor_host_template structure to 2048. Still, SCSI is sending 1024 > sectors (512 KB) in a single data transfer. > I know that my device supports 1 MB data in a sigle transfer. How can > I change this to 1 MB? As long as the driver supports chaining, you increase it in /sys/block/dev>/queue/max_sectors_kb. For compatibility reasons this stays clamped at 512 unless a user specifically raises it. James -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Maximum data size in a single transfer for MS driver 2010-02-17 15:02 ` James Bottomley @ 2010-02-18 8:46 ` Ramya Desai 2010-02-18 15:47 ` James Bottomley 0 siblings, 1 reply; 40+ messages in thread From: Ramya Desai @ 2010-02-18 8:46 UTC (permalink / raw) To: James Bottomley; +Cc: USB list, linux-scsi, Greg KH, Alan Stern On Wed, Feb 17, 2010 at 8:32 PM, James Bottomley <James.Bottomley@suse.de> wrote: > I have no idea what the MS driver is, so it's impossible to answer > specifically. MS means mass storage driver only. > As long as the driver supports chaining, you increase it > in /sys/block/dev>/queue/max_sectors_kb. For compatibility reasons this > stays clamped at 512 unless a user specifically raises it. The max_sectors value is defined in struct scsi_host_template usb_stor_host_template structure in scsiglue.c file (drivers/usb/storage). If I change the max_sectors value in this scsiglue.c file it reflects in the /sys/block/<dev>/queue/max_sectors_kb and /sys/block/<dev>/queue/max_hw_sectors_kb. However, when I set the max_sectors to 1024 it reflected as 512 in /sys/block/<dev>/queue/max_sectors_kb and /sys/block/<dev>/queue/max_hw_sectors_kb. If I change the max_sectors to 1536 or 2048 in scsiglue.c file, still it reflected as 512 in /sys/block/<dev>/queue/max_sectors_kb and 768 or 1024 in /sys/block/<dev>/queue/max_hw_sectors_kb. I have changed the value in /sys/block/<dev>/queue/max_sectors_kb to 1024 with the following command. echo 1024 > /sys/block/<dev>/queue/max_sectors_kb. The file shows 1024, but still, I received only 512 KB data transfer buffers (transfer length in srb) from SCSI layer in my mass storage driver. Here, my question is, how can my mass storage driver receives the 1024 KB data transfer buffers (transfer length in srb) from SCSI layer. Please let me know. Thanks in advance. Thanks and Regards, RD ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Maximum data size in a single transfer for MS driver 2010-02-18 8:46 ` Ramya Desai @ 2010-02-18 15:47 ` James Bottomley [not found] ` <1266508049.4355.37.camel-0iu6Cu4xQGLYCGPCin2YbQ@public.gmane.org> 2010-02-19 12:43 ` Ramya Desai 0 siblings, 2 replies; 40+ messages in thread From: James Bottomley @ 2010-02-18 15:47 UTC (permalink / raw) To: Ramya Desai; +Cc: USB list, linux-scsi, Greg KH, Alan Stern On Thu, 2010-02-18 at 14:16 +0530, Ramya Desai wrote: > On Wed, Feb 17, 2010 at 8:32 PM, James Bottomley > <James.Bottomley@suse.de> wrote: > > > I have no idea what the MS driver is, so it's impossible to answer > > specifically. > > MS means mass storage driver only. OK, still don't know what that is ... but Randy decoded this for me; he said you mean a driver under drivers/usb/storage? In that case, it looks like the helpers in protocol.c do use chaining correctly (as long as the driver isn't doing direct dma), but there's a clamp on the sg table size in scsiglue.c: .sg_tablesize = SG_ALL That would have to be changed to SCSI_MAX_SG_CHAIN_SEGMENTS to enable chaining. James ^ permalink raw reply [flat|nested] 40+ messages in thread
[parent not found: <1266508049.4355.37.camel-0iu6Cu4xQGLYCGPCin2YbQ@public.gmane.org>]
* Re: Maximum data size in a single transfer for MS driver [not found] ` <1266508049.4355.37.camel-0iu6Cu4xQGLYCGPCin2YbQ@public.gmane.org> @ 2010-02-18 16:24 ` Alan Stern [not found] ` <Pine.LNX.4.44L0.1002181115120.1294-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org> 0 siblings, 1 reply; 40+ messages in thread From: Alan Stern @ 2010-02-18 16:24 UTC (permalink / raw) To: James Bottomley Cc: Ramya Desai, USB list, linux-scsi-u79uwXL29TY76Z2rM5mHXA, Greg KH On Thu, 18 Feb 2010, James Bottomley wrote: > On Thu, 2010-02-18 at 14:16 +0530, Ramya Desai wrote: > > On Wed, Feb 17, 2010 at 8:32 PM, James Bottomley > > <James.Bottomley-l3A5Bk7waGM@public.gmane.org> wrote: > > > > > I have no idea what the MS driver is, so it's impossible to answer > > > specifically. > > > > MS means mass storage driver only. > > OK, still don't know what that is ... but Randy decoded this for me; he > said you mean a driver under drivers/usb/storage? Yes, Ramya is talking about usb-storage. > In that case, it looks like the helpers in protocol.c do use chaining > correctly (as long as the driver isn't doing direct dma), but there's a > clamp on the sg table size in scsiglue.c: > > .sg_tablesize = SG_ALL > > That would have to be changed to SCSI_MAX_SG_CHAIN_SEGMENTS to enable > chaining. Is there any reason not to make this change in the standard kernel? I believe that the subdrivers which don't use the helpers in protocol.c also handle chaining correctly. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 40+ messages in thread
[parent not found: <Pine.LNX.4.44L0.1002181115120.1294-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>]
* Re: Maximum data size in a single transfer for MS driver [not found] ` <Pine.LNX.4.44L0.1002181115120.1294-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org> @ 2010-02-18 16:30 ` James Bottomley [not found] ` <1266510627.4355.41.camel-0iu6Cu4xQGLYCGPCin2YbQ@public.gmane.org> 0 siblings, 1 reply; 40+ messages in thread From: James Bottomley @ 2010-02-18 16:30 UTC (permalink / raw) To: Alan Stern Cc: Ramya Desai, USB list, linux-scsi-u79uwXL29TY76Z2rM5mHXA, Greg KH On Thu, 2010-02-18 at 11:24 -0500, Alan Stern wrote: > On Thu, 18 Feb 2010, James Bottomley wrote: > > > On Thu, 2010-02-18 at 14:16 +0530, Ramya Desai wrote: > > > On Wed, Feb 17, 2010 at 8:32 PM, James Bottomley > > > <James.Bottomley-l3A5Bk7waGM@public.gmane.org> wrote: > > > > > > > I have no idea what the MS driver is, so it's impossible to answer > > > > specifically. > > > > > > MS means mass storage driver only. > > > > OK, still don't know what that is ... but Randy decoded this for me; he > > said you mean a driver under drivers/usb/storage? > > Yes, Ramya is talking about usb-storage. > > > In that case, it looks like the helpers in protocol.c do use chaining > > correctly (as long as the driver isn't doing direct dma), but there's a > > clamp on the sg table size in scsiglue.c: > > > > .sg_tablesize = SG_ALL > > > > That would have to be changed to SCSI_MAX_SG_CHAIN_SEGMENTS to enable > > chaining. > > Is there any reason not to make this change in the standard kernel? I > believe that the subdrivers which don't use the helpers in protocol.c > also handle chaining correctly. As long as you're sure that's the case, it should be perfectly fine to do this. On some platforms you'll see the transfer sg list length jump from 128 to 2048 ... so any drivers not using the protocol.c helpers not only have to be using chaining ... they also have to have enough hardware slots (or manually tune sg_tablesize themselves) ... this was the reason why we've been raising the limit individually in SCSI drivers (a lot can't handle the large sg list table sizes). James -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 40+ messages in thread
[parent not found: <1266510627.4355.41.camel-0iu6Cu4xQGLYCGPCin2YbQ@public.gmane.org>]
* Re: Maximum data size in a single transfer for MS driver [not found] ` <1266510627.4355.41.camel-0iu6Cu4xQGLYCGPCin2YbQ@public.gmane.org> @ 2010-02-18 16:51 ` Alan Stern 0 siblings, 0 replies; 40+ messages in thread From: Alan Stern @ 2010-02-18 16:51 UTC (permalink / raw) To: James Bottomley Cc: Ramya Desai, USB list, linux-scsi-u79uwXL29TY76Z2rM5mHXA, Greg KH On Thu, 18 Feb 2010, James Bottomley wrote: > > > In that case, it looks like the helpers in protocol.c do use chaining > > > correctly (as long as the driver isn't doing direct dma), but there's a > > > clamp on the sg table size in scsiglue.c: > > > > > > .sg_tablesize = SG_ALL > > > > > > That would have to be changed to SCSI_MAX_SG_CHAIN_SEGMENTS to enable > > > chaining. > > > > Is there any reason not to make this change in the standard kernel? I > > believe that the subdrivers which don't use the helpers in protocol.c > > also handle chaining correctly. > > As long as you're sure that's the case, it should be perfectly fine to > do this. On some platforms you'll see the transfer sg list length jump > from 128 to 2048 ... so any drivers not using the protocol.c helpers not > only have to be using chaining ... they also have to have enough > hardware slots (or manually tune sg_tablesize themselves) ... this was > the reason why we've been raising the limit individually in SCSI drivers > (a lot can't handle the large sg list table sizes). It shouldn't be much of a problem. The slots aren't stored in the hardware anyway; they are data structures set up in RAM and accessed via a coherent DMA mapping. The only limitations are available memory and latency. (In fact the memory issue is not always trivial. With one type of USB controller, the memory required for the transfer descriptors is half as large as the data buffers themselves! Luckily these controllers don't support high-speed operation, so they won't be used very often with large storage devices.) Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Maximum data size in a single transfer for MS driver 2010-02-18 15:47 ` James Bottomley [not found] ` <1266508049.4355.37.camel-0iu6Cu4xQGLYCGPCin2YbQ@public.gmane.org> @ 2010-02-19 12:43 ` Ramya Desai 2010-02-19 14:26 ` James Bottomley 1 sibling, 1 reply; 40+ messages in thread From: Ramya Desai @ 2010-02-19 12:43 UTC (permalink / raw) To: James Bottomley; +Cc: USB list, linux-scsi, Greg KH, Alan Stern > In that case, it looks like the helpers in protocol.c do use chaining > correctly (as long as the driver isn't doing direct dma), but there's a > clamp on the sg table size in scsiglue.c: > > .sg_tablesize = SG_ALL > > That would have to be changed to SCSI_MAX_SG_CHAIN_SEGMENTS to enable > chaining. Even after changing .sg_tablesize to SCSI_MAX_SG_CHAIN_SEGMENTS, I am getting the same results (maximum 512KB of data transfer buffers in scsi_command). Is there any thing, that I am missing. Do I need to send any logs to analyze the problem? Regards, RD ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Maximum data size in a single transfer for MS driver 2010-02-19 12:43 ` Ramya Desai @ 2010-02-19 14:26 ` James Bottomley 2010-02-22 12:50 ` Ramya Desai 0 siblings, 1 reply; 40+ messages in thread From: James Bottomley @ 2010-02-19 14:26 UTC (permalink / raw) To: Ramya Desai; +Cc: USB list, linux-scsi, Greg KH, Alan Stern On Fri, 2010-02-19 at 18:13 +0530, Ramya Desai wrote: > > In that case, it looks like the helpers in protocol.c do use chaining > > correctly (as long as the driver isn't doing direct dma), but there's a > > clamp on the sg table size in scsiglue.c: > > > > .sg_tablesize = SG_ALL > > > > That would have to be changed to SCSI_MAX_SG_CHAIN_SEGMENTS to enable > > chaining. > > Even after changing .sg_tablesize to SCSI_MAX_SG_CHAIN_SEGMENTS, I am > getting the same results (maximum 512KB of data transfer buffers in > scsi_command). > Is there any thing, that I am missing. Do I need to send any logs to > analyze the problem? Before we get into that, what architecture is this? There are a few, like arm that don't have architecture support for chaining, so they can never go over 128 segments. James ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Maximum data size in a single transfer for MS driver 2010-02-19 14:26 ` James Bottomley @ 2010-02-22 12:50 ` Ramya Desai [not found] ` <3e7aae31002220450o6f83d2f3n45c795d70ef01f72-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 0 siblings, 1 reply; 40+ messages in thread From: Ramya Desai @ 2010-02-22 12:50 UTC (permalink / raw) To: James Bottomley; +Cc: USB list, linux-scsi, Greg KH, Alan Stern On Fri, Feb 19, 2010 at 7:56 PM, James Bottomley <James.Bottomley@suse.de> wrote: > Before we get into that, what architecture is this? There are a few, > like arm that don't have architecture support for chaining, so they can > never go over 128 segments. I am using the desktop PC to access my device. i.e, Intel processor with x86 architecture. Thanks and Regards, RD -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 40+ messages in thread
[parent not found: <3e7aae31002220450o6f83d2f3n45c795d70ef01f72-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: Maximum data size in a single transfer for MS driver [not found] ` <3e7aae31002220450o6f83d2f3n45c795d70ef01f72-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> @ 2010-02-22 13:06 ` James Bottomley 2010-02-22 14:15 ` Ramya Desai 2010-02-22 17:44 ` Alan Stern 0 siblings, 2 replies; 40+ messages in thread From: James Bottomley @ 2010-02-22 13:06 UTC (permalink / raw) To: Ramya Desai Cc: USB list, linux-scsi-u79uwXL29TY76Z2rM5mHXA, Greg KH, Alan Stern On Mon, 2010-02-22 at 18:20 +0530, Ramya Desai wrote: > On Fri, Feb 19, 2010 at 7:56 PM, James Bottomley > <James.Bottomley-l3A5Bk7waGM@public.gmane.org> wrote: > > > Before we get into that, what architecture is this? There are a few, > > like arm that don't have architecture support for chaining, so they can > > never go over 128 segments. > > I am using the desktop PC to access my device. i.e, Intel processor > with x86 architecture. OK, so now see what max_hw_sectors_kb says ... if it's still 512 and you're sure you've got sg_tablesize set to something higher, there's likely something in the USB stack resetting it ... I suppose it's possible there's something else in your kernel doing that for the architecture, but you could rule that out by looking at max_hw_sectors_kb for either a SCSI or libata device and verifying it's much higher than 512. James -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Maximum data size in a single transfer for MS driver 2010-02-22 13:06 ` James Bottomley @ 2010-02-22 14:15 ` Ramya Desai 2010-02-22 17:44 ` Alan Stern 1 sibling, 0 replies; 40+ messages in thread From: Ramya Desai @ 2010-02-22 14:15 UTC (permalink / raw) To: James Bottomley; +Cc: USB list, linux-scsi, Greg KH, Alan Stern On Mon, Feb 22, 2010 at 6:36 PM, James Bottomley <James.Bottomley@suse.de> wrote: > OK, so now see what max_hw_sectors_kb says ... if it's still 512 and > you're sure you've got sg_tablesize set to something higher, there's > likely something in the USB stack resetting it ... I suppose it's > possible there's something else in your kernel doing that for the > architecture, but you could rule that out by looking at > max_hw_sectors_kb for either a SCSI or libata device and verifying it's > much higher than 512. when I set the max_sectors to 1024 in scsiglue.c(drivers/usb/storage), it reflected as 512 in /sys/block/<dev>/queue/max_sectors_kb and /sys/block/<dev>/queue/max_hw_sectors_kb. If I change the max_sectors to 1536 or 2048 in scsiglue.c file, still it reflected as 512 in /sys/block/<dev>/queue/max_sectors_kb and 768 or 1024 in /sys/block/<dev>/queue/max_hw_sectors_kb. Thanks and Regards, RD ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Maximum data size in a single transfer for MS driver 2010-02-22 13:06 ` James Bottomley 2010-02-22 14:15 ` Ramya Desai @ 2010-02-22 17:44 ` Alan Stern 2010-02-22 18:07 ` Alan Stern [not found] ` <Pine.LNX.4.44L0.1002221232160.1251-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org> 1 sibling, 2 replies; 40+ messages in thread From: Alan Stern @ 2010-02-22 17:44 UTC (permalink / raw) To: James Bottomley; +Cc: Ramya Desai, USB list, linux-scsi, Greg KH On Mon, 22 Feb 2010, James Bottomley wrote: > On Mon, 2010-02-22 at 18:20 +0530, Ramya Desai wrote: > > On Fri, Feb 19, 2010 at 7:56 PM, James Bottomley > > <James.Bottomley@suse.de> wrote: > > > > > Before we get into that, what architecture is this? There are a few, > > > like arm that don't have architecture support for chaining, so they can > > > never go over 128 segments. > > > > I am using the desktop PC to access my device. i.e, Intel processor > > with x86 architecture. > > OK, so now see what max_hw_sectors_kb says ... if it's still 512 and > you're sure you've got sg_tablesize set to something higher, there's > likely something in the USB stack resetting it ... I suppose it's > possible there's something else in your kernel doing that for the > architecture, but you could rule that out by looking at > max_hw_sectors_kb for either a SCSI or libata device and verifying it's > much higher than 512. Usb-storage sets max_sectors to 240 in the host template. For some reason, the block layer also changes max_hw_sectors to the same value (see block/blk-settings.c:blk_queue_max_sectors()). The value can be changed by writing to /sys/block/sdX/device/max_sectors (where X is the drive letter). Note that this value is in 512-byte blocks, not in KB. However it is limited to SCSI_DEFAULT_MAX_SECTORS, which is 1024, corresponding to 512 MB. If larger transfers are needed then drivers/usb/storage/scsiglue.c:store_max_sectors() must be changed. Alan Stern ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Maximum data size in a single transfer for MS driver 2010-02-22 17:44 ` Alan Stern @ 2010-02-22 18:07 ` Alan Stern [not found] ` <Pine.LNX.4.44L0.1002221232160.1251-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org> 1 sibling, 0 replies; 40+ messages in thread From: Alan Stern @ 2010-02-22 18:07 UTC (permalink / raw) To: James Bottomley; +Cc: Ramya Desai, USB list, linux-scsi, Greg KH On Mon, 22 Feb 2010, Alan Stern wrote: > The value can be changed by writing to > /sys/block/sdX/device/max_sectors (where X is the drive letter). Note > that this value is in 512-byte blocks, not in KB. However it is > limited to SCSI_DEFAULT_MAX_SECTORS, which is 1024, corresponding to > 512 MB. If larger transfers are needed then ------^ Typo: this should be 512 KB. Alan Stern ^ permalink raw reply [flat|nested] 40+ messages in thread
[parent not found: <Pine.LNX.4.44L0.1002221232160.1251-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>]
* Re: Maximum data size in a single transfer for MS driver [not found] ` <Pine.LNX.4.44L0.1002221232160.1251-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org> @ 2010-02-23 15:29 ` Ramya Desai 2010-02-23 16:49 ` Alan Stern 0 siblings, 1 reply; 40+ messages in thread From: Ramya Desai @ 2010-02-23 15:29 UTC (permalink / raw) To: Alan Stern Cc: James Bottomley, USB list, linux-scsi-u79uwXL29TY76Z2rM5mHXA, Greg KH On Mon, Feb 22, 2010 at 11:14 PM, Alan Stern <stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz@public.gmane.org> wrote: Dear Alan, Thanks for the information. > Usb-storage sets max_sectors to 240 in the host template. For some > reason, the block layer also changes max_hw_sectors to the same value > (see block/blk-settings.c:blk_queue_max_sectors()). I am setting the max_sectors in host template (scsiglue.c file). When the max_sectors value is <= 1024, then only the max_sectors_kb and max_hw_sectors_kb are same in the sys interface. However, if the max_sectors value is > 1024 then the values in the sys interface files are different as shown in block/blk-setting.c:blk_queue_max_sectors(). if (BLK_DEF_MAX_SECTORS > max_sectors) q->limits.max_hw_sectors = q->limits.max_sectors = max_sectors; else { q->limits.max_sectors = BLK_DEF_MAX_SECTORS; q->limits.max_hw_sectors = max_sectors; } I guess, in my case, it enters into the ELSE part. I tried to debug these sources (block/blk-setting.c), but I am not able to do it. Please let me know, how can I get the debug statements from this file? > The value can be changed by writing to > /sys/block/sdX/device/max_sectors (where X is the drive letter). Note > that this value is in 512-byte blocks, not in KB. However it is > limited to SCSI_DEFAULT_MAX_SECTORS, which is 1024, corresponding to > 512 MB. If larger transfers are needed then > drivers/usb/storage/scsiglue.c:store_max_sectors() must be changed. I have chaged the value in /sys/block/sdb/queue/max_sectors_kb through echo command. Even after this change, I have received only 1024 sectors (512 KB) data transfer buffers in my SCSI command. Even I have modified the store_max_sectors() function code in the scsiglue.c file. But, there is no luck and still I received 1024 sectors (512 KB) transfer buffers in the scsi_command. Please let me know, if you need any additional information. Thanks and Regards, RD. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Maximum data size in a single transfer for MS driver 2010-02-23 15:29 ` Ramya Desai @ 2010-02-23 16:49 ` Alan Stern 2010-02-23 17:00 ` Martin K. Petersen 0 siblings, 1 reply; 40+ messages in thread From: Alan Stern @ 2010-02-23 16:49 UTC (permalink / raw) To: Ramya Desai Cc: James Bottomley, Jens Axboe, USB list, SCSI development list, Greg KH On Tue, 23 Feb 2010, Ramya Desai wrote: > On Mon, Feb 22, 2010 at 11:14 PM, Alan Stern <stern@rowland.harvard.edu> wrote: > > Dear Alan, > > Thanks for the information. > > > Usb-storage sets max_sectors to 240 in the host template. For some > > reason, the block layer also changes max_hw_sectors to the same value > > (see block/blk-settings.c:blk_queue_max_sectors()). > > I am setting the max_sectors in host template (scsiglue.c file). When > the max_sectors value is <= 1024, then only the max_sectors_kb and > max_hw_sectors_kb are same in the sys interface. However, if the > max_sectors value is > 1024 then the values in the sys interface files > are different as shown in block/blk-setting.c:blk_queue_max_sectors(). > > if (BLK_DEF_MAX_SECTORS > max_sectors) > q->limits.max_hw_sectors = q->limits.max_sectors = max_sectors; > else { > q->limits.max_sectors = BLK_DEF_MAX_SECTORS; > q->limits.max_hw_sectors = max_sectors; > } James or Jens, is there a reason why this routine limits max_sectors to 1024? And is there a reason why it sets both max_sectors and max_hw_sectors, leaving no way to change one without the other? Are drivers supposed to assign values directly to q->limits.max_sectors? Shouldn't there be a cleaner API for all this? Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Maximum data size in a single transfer for MS driver 2010-02-23 16:49 ` Alan Stern @ 2010-02-23 17:00 ` Martin K. Petersen 2010-02-23 18:01 ` Alan Stern 2010-02-25 16:37 ` Alan Stern 0 siblings, 2 replies; 40+ messages in thread From: Martin K. Petersen @ 2010-02-23 17:00 UTC (permalink / raw) To: Alan Stern Cc: Ramya Desai, James Bottomley, Jens Axboe, USB list, SCSI development list, Greg KH >>>>> "Alan" == Alan Stern <stern@rowland.harvard.edu> writes: Alan> James or Jens, is there a reason why this routine limits Alan> max_sectors to 1024? Alan> And is there a reason why it sets both max_sectors and Alan> max_hw_sectors, leaving no way to change one without the other? The rationale being that we don't want the default value to be too large because it makes I/O choppy on single-spindle setups. If the device driver supports bigger requests we set the hard limit to whatever they support. But filesystem I/O is capped at the default limit which is 1024 for modern devices (and 255 for crappy ones). You can change the current soft limit on a per-device basis in /sys/block/<dev>/queue/max_sectors_kb. I agree it would be nice to have a system-wide default that's not a #define. But given that a lot of queues are created early that's not so easy to do. Alan> Are drivers supposed to assign values directly to Alan> q-> limits.max_sectors? Shouldn't there be a cleaner API for all Alan> this? Drivers are supposed to set the hard limit. The soft limit is a fs/block layer value and none of the device driver's business. -- Martin K. Petersen Oracle Linux Engineering ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Maximum data size in a single transfer for MS driver 2010-02-23 17:00 ` Martin K. Petersen @ 2010-02-23 18:01 ` Alan Stern [not found] ` <Pine.LNX.4.44L0.1002231253320.1308-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org> 2010-02-25 16:37 ` Alan Stern 1 sibling, 1 reply; 40+ messages in thread From: Alan Stern @ 2010-02-23 18:01 UTC (permalink / raw) To: Martin K. Petersen Cc: Ramya Desai, James Bottomley, Jens Axboe, USB list, SCSI development list, Greg KH On Tue, 23 Feb 2010, Martin K. Petersen wrote: > >>>>> "Alan" == Alan Stern <stern@rowland.harvard.edu> writes: > > Alan> James or Jens, is there a reason why this routine limits > Alan> max_sectors to 1024? > > Alan> And is there a reason why it sets both max_sectors and > Alan> max_hw_sectors, leaving no way to change one without the other? > > The rationale being that we don't want the default value to be too large > because it makes I/O choppy on single-spindle setups. > > If the device driver supports bigger requests we set the hard limit to > whatever they support. But filesystem I/O is capped at the default > limit which is 1024 for modern devices (and 255 for crappy ones). > > You can change the current soft limit on a per-device basis in > /sys/block/<dev>/queue/max_sectors_kb. > > I agree it would be nice to have a system-wide default that's not a > #define. But given that a lot of queues are created early that's not so > easy to do. > > > Alan> Are drivers supposed to assign values directly to > Alan> q-> limits.max_sectors? Shouldn't there be a cleaner API for all > Alan> this? > > Drivers are supposed to set the hard limit. The soft limit is a > fs/block layer value and none of the device driver's business. So Ramya, it looks like you need to edit store_max_sectors() in drivers/usb/storage/scsiglue.c. Get rid of the " && ms <= SCSI_DEFAULT_MAX_SECTORS" part. Then you should be able to write a large value to /sys/block/sdX/device/max_sectors to increase the hardware limit. The new value divided by 2 will show up in /sys/block/sdX/queue/max_hw_sectors_kb. Once that limit is increased, you can write a large value to /sys/block/sdX/queue/max_sectors_kb. That should give you long transfer lengths. Alan Stern ^ permalink raw reply [flat|nested] 40+ messages in thread
[parent not found: <Pine.LNX.4.44L0.1002231253320.1308-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>]
* Re: Maximum data size in a single transfer for MS driver [not found] ` <Pine.LNX.4.44L0.1002231253320.1308-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org> @ 2010-02-24 13:07 ` Ramya Desai 2010-02-24 13:12 ` Jens Axboe 2010-02-24 16:30 ` Alan Stern 0 siblings, 2 replies; 40+ messages in thread From: Ramya Desai @ 2010-02-24 13:07 UTC (permalink / raw) To: Alan Stern Cc: Martin K. Petersen, James Bottomley, Jens Axboe, USB list, SCSI development list, Greg KH On Tue, Feb 23, 2010 at 11:31 PM, Alan Stern <stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz@public.gmane.org> wrote: Dear Alan, Thanks a lot. > So Ramya, it looks like you need to edit store_max_sectors() in > drivers/usb/storage/scsiglue.c. Get rid of the " && ms <= > SCSI_DEFAULT_MAX_SECTORS" part. > > Then you should be able to write a large value to > /sys/block/sdX/device/max_sectors to increase the hardware limit. The > new value divided by 2 will show up in > /sys/block/sdX/queue/max_hw_sectors_kb. > > Once that limit is increased, you can write a large value to > /sys/block/sdX/queue/max_sectors_kb. That should give you long > transfer lengths. I did exactly. I removed the following statement from store_max_sectors (drivers/usb/storage/scsiglue.c) function. " && ms <= SCSI_DEFAULT_MAX_SECTORS". I also changed the .max_sectors = 2048 in the host template. Then I restarted the system and build the usb-storage without any issue. After inserting my device, I found 1024 in /sys/block/sdb/device/max_sectors. So, I tried to increase the value through echo 2048 > /sys/block/sdb/device/max_sectors. When I do this, it invoked the store_max_sectors() in the scsiglue.c file and able to see ms (the variable in the store_max_sectors()) is 2048. But, the value in the /sys/block/sdb/device/max_sectors is still 1024 only. When I looked into the /sys/block/sdb/queue/max_hw_sectors_kb, it shows 1024, which is 2048 sectors. Then, I tried to increase the value in /sys/block/sdb/queue/max_sectors_kb through echo 1024 > /sys/block/sdb/queue/max_sectors_kb. After this, I saw 1024 in the /sys/block/sdb/queue/max_sectors_kb. When I see 1024 in /sys/block/sdb/queue/max_sectors_kb then I found 2048 in /sys/block/sdb/device/max_sectors. However, this time, still my device received 512 KB (1024) data transfer buffers in scsi_command. Please let me know If I missed any thing here? Thanks and Regards, RD. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Maximum data size in a single transfer for MS driver 2010-02-24 13:07 ` Ramya Desai @ 2010-02-24 13:12 ` Jens Axboe 2010-02-24 16:30 ` Alan Stern 1 sibling, 0 replies; 40+ messages in thread From: Jens Axboe @ 2010-02-24 13:12 UTC (permalink / raw) To: Ramya Desai Cc: Alan Stern, Martin K. Petersen, James Bottomley, USB list, SCSI development list, Greg KH On Wed, Feb 24 2010, Ramya Desai wrote: > On Tue, Feb 23, 2010 at 11:31 PM, Alan Stern <stern@rowland.harvard.edu> wrote: > > Dear Alan, > > Thanks a lot. > > > So Ramya, it looks like you need to edit store_max_sectors() in > > drivers/usb/storage/scsiglue.c. Get rid of the " && ms <= > > SCSI_DEFAULT_MAX_SECTORS" part. > > > > Then you should be able to write a large value to > > /sys/block/sdX/device/max_sectors to increase the hardware limit. The > > new value divided by 2 will show up in > > /sys/block/sdX/queue/max_hw_sectors_kb. > > > > Once that limit is increased, you can write a large value to > > /sys/block/sdX/queue/max_sectors_kb. That should give you long > > transfer lengths. > > I did exactly. I removed the following statement from > store_max_sectors (drivers/usb/storage/scsiglue.c) function. > " && ms <= SCSI_DEFAULT_MAX_SECTORS". I also changed the .max_sectors > = 2048 in the host template. > > Then I restarted the system and build the usb-storage without any issue. > > After inserting my device, I found 1024 in > /sys/block/sdb/device/max_sectors. So, I tried to increase the value > through echo 2048 > /sys/block/sdb/device/max_sectors. When I do this, > it invoked the store_max_sectors() in the scsiglue.c file and able to > see ms (the variable in the store_max_sectors()) is 2048. But, the > value in the /sys/block/sdb/device/max_sectors is still 1024 only. > > When I looked into the /sys/block/sdb/queue/max_hw_sectors_kb, it > shows 1024, which is 2048 sectors. Then, I tried to increase the value > in /sys/block/sdb/queue/max_sectors_kb through echo 1024 > > /sys/block/sdb/queue/max_sectors_kb. After this, I saw 1024 in the > /sys/block/sdb/queue/max_sectors_kb. When I see 1024 in > /sys/block/sdb/queue/max_sectors_kb then I found 2048 in > /sys/block/sdb/device/max_sectors. However, this time, still my device > received 512 KB (1024) data transfer buffers in scsi_command. > > Please let me know If I missed any thing here? You cannot make max_sectors_kb larger than max_hw_sectors_kb, as the latter implies a hardware restriction (as seen by the block layer). Drivers should not fiddle with max_sectors_kb, they should only concern themselves with max_hw_sectors. The former is then set to a reasonable value, which is either the system default or the hardware limit, which ever one is lower. -- Jens Axboe -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Maximum data size in a single transfer for MS driver 2010-02-24 13:07 ` Ramya Desai 2010-02-24 13:12 ` Jens Axboe @ 2010-02-24 16:30 ` Alan Stern 2010-02-24 19:07 ` Jens Axboe 2010-02-25 14:44 ` Ramya Desai 1 sibling, 2 replies; 40+ messages in thread From: Alan Stern @ 2010-02-24 16:30 UTC (permalink / raw) To: Ramya Desai Cc: Martin K. Petersen, James Bottomley, Jens Axboe, USB list, SCSI development list, Greg KH On Wed, 24 Feb 2010, Ramya Desai wrote: > I did exactly. I removed the following statement from > store_max_sectors (drivers/usb/storage/scsiglue.c) function. > " && ms <= SCSI_DEFAULT_MAX_SECTORS". I also changed the .max_sectors > = 2048 in the host template. > > Then I restarted the system and build the usb-storage without any issue. > > After inserting my device, I found 1024 in > /sys/block/sdb/device/max_sectors. So, I tried to increase the value > through echo 2048 > /sys/block/sdb/device/max_sectors. When I do this, > it invoked the store_max_sectors() in the scsiglue.c file and able to > see ms (the variable in the store_max_sectors()) is 2048. But, the > value in the /sys/block/sdb/device/max_sectors is still 1024 only. That's right. Writing 2048 to that file sets max_hw_sectors to 2048 while leaving max_sectors set at 1024. The value displayed in the file is max_sectors -- it really ought to be max_hw_sectors. You can fix this by editing the show_max_sectors() function in scsiglue.c: change "queue_max_sectors" to "queue_max_hw_sectors". > When I looked into the /sys/block/sdb/queue/max_hw_sectors_kb, it > shows 1024, which is 2048 sectors. As it should be. > Then, I tried to increase the value > in /sys/block/sdb/queue/max_sectors_kb through echo 1024 > > /sys/block/sdb/queue/max_sectors_kb. After this, I saw 1024 in the > /sys/block/sdb/queue/max_sectors_kb. When I see 1024 in > /sys/block/sdb/queue/max_sectors_kb then I found 2048 in > /sys/block/sdb/device/max_sectors. Right, because that file displays max_sectors instead of max_hw_sectors. > However, this time, still my device > received 512 KB (1024) data transfer buffers in scsi_command. At this point everything was set up correctly. I don't know why the transfer lengths are still 512 KB. Maybe someone else has an idea. Alan Stern ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Maximum data size in a single transfer for MS driver 2010-02-24 16:30 ` Alan Stern @ 2010-02-24 19:07 ` Jens Axboe 2010-02-25 14:47 ` Ramya Desai 2010-02-25 14:44 ` Ramya Desai 1 sibling, 1 reply; 40+ messages in thread From: Jens Axboe @ 2010-02-24 19:07 UTC (permalink / raw) To: Alan Stern Cc: Ramya Desai, Martin K. Petersen, James Bottomley, USB list, SCSI development list, Greg KH On Wed, Feb 24 2010, Alan Stern wrote: > > However, this time, still my device > > received 512 KB (1024) data transfer buffers in scsi_command. > > At this point everything was set up correctly. I don't know why the > transfer lengths are still 512 KB. Maybe someone else has an idea. What is the test case issuing the IO? Depending on the device, it may hit other restrictions aside from just maximum transfer length. -- Jens Axboe ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Maximum data size in a single transfer for MS driver 2010-02-24 19:07 ` Jens Axboe @ 2010-02-25 14:47 ` Ramya Desai 0 siblings, 0 replies; 40+ messages in thread From: Ramya Desai @ 2010-02-25 14:47 UTC (permalink / raw) To: Jens Axboe Cc: Alan Stern, Martin K. Petersen, James Bottomley, USB list, SCSI development list, Greg KH On Thu, Feb 25, 2010 at 12:37 AM, Jens Axboe <jens.axboe@oracle.com> wrote: >> At this point everything was set up correctly. I don't know why the >> transfer lengths are still 512 KB. Maybe someone else has an idea. > > What is the test case issuing the IO? Depending on the device, it may > hit other restrictions aside from just maximum transfer length. Dear Jens, We are just copying the data from PC to usb-storage device (drag and drop), host to device. Please let me know, if you need any additional information. Thansk and Regards, RD. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Maximum data size in a single transfer for MS driver 2010-02-24 16:30 ` Alan Stern 2010-02-24 19:07 ` Jens Axboe @ 2010-02-25 14:44 ` Ramya Desai 1 sibling, 0 replies; 40+ messages in thread From: Ramya Desai @ 2010-02-25 14:44 UTC (permalink / raw) To: Alan Stern Cc: Martin K. Petersen, James Bottomley, Jens Axboe, USB list, SCSI development list, Greg KH On Wed, Feb 24, 2010 at 10:00 PM, Alan Stern <stern@rowland.harvard.edu> wrote: > On Wed, 24 Feb 2010, Ramya Desai wrote: > >> I did exactly. I removed the following statement from >> store_max_sectors (drivers/usb/storage/scsiglue.c) function. >> " && ms <= SCSI_DEFAULT_MAX_SECTORS". I also changed the .max_sectors >> = 2048 in the host template. >> >> Then I restarted the system and build the usb-storage without any issue. >> >> After inserting my device, I found 1024 in >> /sys/block/sdb/device/max_sectors. So, I tried to increase the value >> through echo 2048 > /sys/block/sdb/device/max_sectors. When I do this, >> it invoked the store_max_sectors() in the scsiglue.c file and able to >> see ms (the variable in the store_max_sectors()) is 2048. But, the >> value in the /sys/block/sdb/device/max_sectors is still 1024 only. > > That's right. Writing 2048 to that file sets max_hw_sectors to 2048 > while leaving max_sectors set at 1024. The value displayed in the file > is max_sectors -- it really ought to be max_hw_sectors. You can fix > this by editing the show_max_sectors() function in scsiglue.c: change > "queue_max_sectors" to "queue_max_hw_sectors". > >> When I looked into the /sys/block/sdb/queue/max_hw_sectors_kb, it >> shows 1024, which is 2048 sectors. > > As it should be. > >> Then, I tried to increase the value >> in /sys/block/sdb/queue/max_sectors_kb through echo 1024 > >> /sys/block/sdb/queue/max_sectors_kb. After this, I saw 1024 in the >> /sys/block/sdb/queue/max_sectors_kb. When I see 1024 in >> /sys/block/sdb/queue/max_sectors_kb then I found 2048 in >> /sys/block/sdb/device/max_sectors. > > Right, because that file displays max_sectors instead of > max_hw_sectors. > >> However, this time, still my device >> received 512 KB (1024) data transfer buffers in scsi_command. > > At this point everything was set up correctly. I don't know why the > transfer lengths are still 512 KB. Maybe someone else has an idea. > > Alan Stern Dear Alan, James, Martin, Jens Thanks a lot for your valuable information. I will let all you know, If I see any progress. Thanks and Regards, RD. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Maximum data size in a single transfer for MS driver 2010-02-23 17:00 ` Martin K. Petersen 2010-02-23 18:01 ` Alan Stern @ 2010-02-25 16:37 ` Alan Stern 2010-02-25 16:49 ` Martin K. Petersen [not found] ` <Pine.LNX.4.44L0.1002251132170.1686-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org> 1 sibling, 2 replies; 40+ messages in thread From: Alan Stern @ 2010-02-25 16:37 UTC (permalink / raw) To: Martin K. Petersen Cc: Ramya Desai, James Bottomley, Jens Axboe, USB list, SCSI development list, Greg KH On Tue, 23 Feb 2010, Martin K. Petersen wrote: > Alan> Are drivers supposed to assign values directly to > Alan> q-> limits.max_sectors? Shouldn't there be a cleaner API for all > Alan> this? > > Drivers are supposed to set the hard limit. The soft limit is a > fs/block layer value and none of the device driver's business. _How_ are drivers supposed to set the hard limit? If they call blk_queue_max_sectors() then both the hard and soft limits are affected, but at least the hard limit is set correctly. If they call blk_queue_max_hw_sectors() then only the hard limit is affected, but it cannot be set to a value less than 1024 (BLK_DEF_MAX_SECTORS). Wouldn't it be more logical to allow the hard limit to be set to anything at least as large as the page size, and decrease the soft limit if it is larger than the new hard limit? Alan Stern ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Maximum data size in a single transfer for MS driver 2010-02-25 16:37 ` Alan Stern @ 2010-02-25 16:49 ` Martin K. Petersen 2010-02-25 16:53 ` Martin K. Petersen [not found] ` <Pine.LNX.4.44L0.1002251132170.1686-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org> 1 sibling, 1 reply; 40+ messages in thread From: Martin K. Petersen @ 2010-02-25 16:49 UTC (permalink / raw) To: Alan Stern Cc: Martin K. Petersen, Ramya Desai, James Bottomley, Jens Axboe, USB list, SCSI development list, Greg KH >>>>> "Alan" == Alan Stern <stern@rowland.harvard.edu> writes: Alan> If they call blk_queue_max_sectors() then both the hard and soft Alan> limits are affected, but at least the hard limit is set correctly. Yep. Alan> If they call blk_queue_max_hw_sectors() then only the hard limit Alan> is affected, This one is a runt that came in as part of the DM topology enablement. DM ended up doing things differently and it is no longer used. I already have a patch in my queue that removes it. -- Martin K. Petersen Oracle Linux Engineering ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Maximum data size in a single transfer for MS driver 2010-02-25 16:49 ` Martin K. Petersen @ 2010-02-25 16:53 ` Martin K. Petersen 2010-02-25 17:54 ` Jens Axboe [not found] ` <yq1zl2xl0j3.fsf-+q57XtR/GgMb6DWv4sQWN6xOck334EZe@public.gmane.org> 0 siblings, 2 replies; 40+ messages in thread From: Martin K. Petersen @ 2010-02-25 16:53 UTC (permalink / raw) To: Alan Stern Cc: Ramya Desai, James Bottomley, Jens Axboe, USB list, SCSI development list, Greg KH >>>>> "mkp" == Martin K Petersen <martin.petersen@oracle.com> writes: mkp> This one is a runt that came in as part of the DM topology mkp> enablement. DM ended up doing things differently and it is no mkp> longer used. I already have a patch in my queue that removes it. Here it is, btw... block: Remove blk_queue_max_hw_sectors This function is no longer called by any subsystem and can be removed. Also clarify test in blk_queue_max_sectors. Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> --- diff --git a/block/blk-settings.c b/block/blk-settings.c index aaa379b..69b7c67 100644 --- a/block/blk-settings.c +++ b/block/blk-settings.c @@ -226,7 +226,7 @@ void blk_queue_max_sectors(struct request_queue *q, unsigned int max_sectors) __func__, max_sectors); } - if (BLK_DEF_MAX_SECTORS > max_sectors) + if (max_sectors < BLK_DEF_MAX_SECTORS) q->limits.max_hw_sectors = q->limits.max_sectors = max_sectors; else { q->limits.max_sectors = BLK_DEF_MAX_SECTORS; @@ -235,15 +235,6 @@ void blk_queue_max_sectors(struct request_queue *q, unsigned int max_sectors) } EXPORT_SYMBOL(blk_queue_max_sectors); -void blk_queue_max_hw_sectors(struct request_queue *q, unsigned int max_sectors) -{ - if (BLK_DEF_MAX_SECTORS > max_sectors) - q->limits.max_hw_sectors = BLK_DEF_MAX_SECTORS; - else - q->limits.max_hw_sectors = max_sectors; -} -EXPORT_SYMBOL(blk_queue_max_hw_sectors); - /** * blk_queue_max_discard_sectors - set max sectors for a single discard * @q: the request queue for the device diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h index ffb13ad..0b05791 100644 --- a/include/linux/blkdev.h +++ b/include/linux/blkdev.h @@ -921,7 +921,6 @@ extern void blk_cleanup_queue(struct request_queue *); extern void blk_queue_make_request(struct request_queue *, make_request_fn *); extern void blk_queue_bounce_limit(struct request_queue *, u64); extern void blk_queue_max_sectors(struct request_queue *, unsigned int); -extern void blk_queue_max_hw_sectors(struct request_queue *, unsigned int); extern void blk_queue_max_phys_segments(struct request_queue *, unsigned short); extern void blk_queue_max_hw_segments(struct request_queue *, unsigned short); extern void blk_queue_max_segment_size(struct request_queue *, unsigned int); ^ permalink raw reply related [flat|nested] 40+ messages in thread
* Re: Maximum data size in a single transfer for MS driver 2010-02-25 16:53 ` Martin K. Petersen @ 2010-02-25 17:54 ` Jens Axboe [not found] ` <yq1zl2xl0j3.fsf-+q57XtR/GgMb6DWv4sQWN6xOck334EZe@public.gmane.org> 1 sibling, 0 replies; 40+ messages in thread From: Jens Axboe @ 2010-02-25 17:54 UTC (permalink / raw) To: Martin K. Petersen Cc: Alan Stern, Ramya Desai, James Bottomley, USB list, SCSI development list, Greg KH On Thu, Feb 25 2010, Martin K. Petersen wrote: > >>>>> "mkp" == Martin K Petersen <martin.petersen@oracle.com> writes: > > mkp> This one is a runt that came in as part of the DM topology > mkp> enablement. DM ended up doing things differently and it is no > mkp> longer used. I already have a patch in my queue that removes it. > > Here it is, btw... > > > block: Remove blk_queue_max_hw_sectors > > This function is no longer called by any subsystem and can be removed. > > Also clarify test in blk_queue_max_sectors. That works, we badly need to clean this crap up, I had not noticed it had gone this wrong. I'll shove this into 2.6.34, thanks. -- Jens Axboe ^ permalink raw reply [flat|nested] 40+ messages in thread
[parent not found: <yq1zl2xl0j3.fsf-+q57XtR/GgMb6DWv4sQWN6xOck334EZe@public.gmane.org>]
* Re: Maximum data size in a single transfer for MS driver [not found] ` <yq1zl2xl0j3.fsf-+q57XtR/GgMb6DWv4sQWN6xOck334EZe@public.gmane.org> @ 2010-02-25 18:28 ` Alan Stern 2010-02-25 19:05 ` Martin K. Petersen 0 siblings, 1 reply; 40+ messages in thread From: Alan Stern @ 2010-02-25 18:28 UTC (permalink / raw) To: Martin K. Petersen Cc: Ramya Desai, James Bottomley, Jens Axboe, USB list, SCSI development list, Greg KH On Thu, 25 Feb 2010, Martin K. Petersen wrote: > >>>>> "mkp" == Martin K Petersen <martin.petersen-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org> writes: > > mkp> This one is a runt that came in as part of the DM topology > mkp> enablement. DM ended up doing things differently and it is no > mkp> longer used. I already have a patch in my queue that removes it. > > Here it is, btw... > > > block: Remove blk_queue_max_hw_sectors > > This function is no longer called by any subsystem and can be removed. > > Also clarify test in blk_queue_max_sectors. > > Signed-off-by: Martin K. Petersen <martin.petersen-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org> > > --- > > diff --git a/block/blk-settings.c b/block/blk-settings.c > index aaa379b..69b7c67 100644 > --- a/block/blk-settings.c > +++ b/block/blk-settings.c > @@ -226,7 +226,7 @@ void blk_queue_max_sectors(struct request_queue *q, unsigned int max_sectors) > __func__, max_sectors); > } > > - if (BLK_DEF_MAX_SECTORS > max_sectors) > + if (max_sectors < BLK_DEF_MAX_SECTORS) > q->limits.max_hw_sectors = q->limits.max_sectors = max_sectors; > else { > q->limits.max_sectors = BLK_DEF_MAX_SECTORS; Why is max_sectors changed? If it is already smaller than the new value of max_hw_sectors, shouldn't it remain the same? Or to put it another way, shouldn't the code look more like this? q->limits.max_hw_sectors = max(max_sectors, BLK_DEF_MAX_SECTORS); if (q->limits.max_sectors > q->limits.max_hw_sectors) q->limits.max_sectors = q->limits.max_hw_sectors; Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Maximum data size in a single transfer for MS driver 2010-02-25 18:28 ` Alan Stern @ 2010-02-25 19:05 ` Martin K. Petersen [not found] ` <yq1iq9lkueh.fsf-+q57XtR/GgMb6DWv4sQWN6xOck334EZe@public.gmane.org> 0 siblings, 1 reply; 40+ messages in thread From: Martin K. Petersen @ 2010-02-25 19:05 UTC (permalink / raw) To: Alan Stern Cc: Martin K. Petersen, Ramya Desai, James Bottomley, Jens Axboe, USB list, SCSI development list, Greg KH >>>>> "Alan" == Alan Stern <stern@rowland.harvard.edu> writes: Alan> Why is max_sectors changed? If it is already smaller than the new Alan> value of max_hw_sectors, shouldn't it remain the same? We have a lot of legacy device drivers kicking around in the tree so the default max request size remains the conservative SAFE_MAX_SECTORS (255). When a low level driver explicitly tells us that it can support bigger requests we take the opportunity to increase the soft limit to the block layer default (1024). Also, this function is generally called at block device creation time so it's not like we're overwriting an existing user setting. -- Martin K. Petersen Oracle Linux Engineering ^ permalink raw reply [flat|nested] 40+ messages in thread
[parent not found: <yq1iq9lkueh.fsf-+q57XtR/GgMb6DWv4sQWN6xOck334EZe@public.gmane.org>]
* Re: Maximum data size in a single transfer for MS driver [not found] ` <yq1iq9lkueh.fsf-+q57XtR/GgMb6DWv4sQWN6xOck334EZe@public.gmane.org> @ 2010-02-25 19:47 ` Alan Stern 2010-02-26 3:37 ` Martin K. Petersen 0 siblings, 1 reply; 40+ messages in thread From: Alan Stern @ 2010-02-25 19:47 UTC (permalink / raw) To: Martin K. Petersen Cc: Ramya Desai, James Bottomley, Jens Axboe, USB list, SCSI development list, Greg KH On Thu, 25 Feb 2010, Martin K. Petersen wrote: > >>>>> "Alan" == Alan Stern <stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz@public.gmane.org> writes: > > Alan> Why is max_sectors changed? If it is already smaller than the new > Alan> value of max_hw_sectors, shouldn't it remain the same? > > We have a lot of legacy device drivers kicking around in the tree so the > default max request size remains the conservative SAFE_MAX_SECTORS > (255). > > When a low level driver explicitly tells us that it can support bigger > requests we take the opportunity to increase the soft limit to the block > layer default (1024). > > Also, this function is generally called at block device creation time so > it's not like we're overwriting an existing user setting. With usb-storage we've got a situation where the function can be called later than device creation time. This is because there's such a wide variety among USB devices, there's no way for the driver always to know the device's actual capabilities -- sometimes the user has to tell it. This should work out okay with your code. I just have to change usb-storage so that the value it reports to the user in the attribute file is max_hw_sectors instead of max_sectors, to reflect what's actually being changed. BTW, how come you didn't write it like this? q->limits.max_hw_sectors = max_sectors; if (max_sectors < BLK_DEF_MAX_SECTORS) q->limits.max_sectors = max_sectors; else q->limits.max_sectors = BLK_DEF_MAX_SECTORS; For me this is easier to understand. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Maximum data size in a single transfer for MS driver 2010-02-25 19:47 ` Alan Stern @ 2010-02-26 3:37 ` Martin K. Petersen 0 siblings, 0 replies; 40+ messages in thread From: Martin K. Petersen @ 2010-02-26 3:37 UTC (permalink / raw) To: Alan Stern Cc: Martin K. Petersen, Ramya Desai, James Bottomley, Jens Axboe, USB list, SCSI development list, Greg KH >>>>> "Alan" == Alan Stern <stern@rowland.harvard.edu> writes: Alan> BTW, how come you didn't write it like this? Alan> q->limits.max_hw_sectors = max_sectors; Alan> if (max_sectors < BLK_DEF_MAX_SECTORS) Alan> q->limits.max_sectors = max_sectors; Alan> else Alan> q->limits.max_sectors = BLK_DEF_MAX_SECTORS; Alan> For me this is easier to understand. No particular reason. Once the test args were swapped the original code was clear to me. However, we could do: q->limits.max_hw_sectors = max_hw_sectors; q->limits.max_sectors = min(max_hw_sectors, BLK_DEF_MAX_SECTORS); -- Martin K. Petersen Oracle Linux Engineering ^ permalink raw reply [flat|nested] 40+ messages in thread
[parent not found: <Pine.LNX.4.44L0.1002251132170.1686-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>]
* Re: Maximum data size in a single transfer for MS driver [not found] ` <Pine.LNX.4.44L0.1002251132170.1686-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org> @ 2010-02-25 17:52 ` Jens Axboe 0 siblings, 0 replies; 40+ messages in thread From: Jens Axboe @ 2010-02-25 17:52 UTC (permalink / raw) To: Alan Stern Cc: Martin K. Petersen, Ramya Desai, James Bottomley, USB list, SCSI development list, Greg KH On Thu, Feb 25 2010, Alan Stern wrote: > On Tue, 23 Feb 2010, Martin K. Petersen wrote: > > > Alan> Are drivers supposed to assign values directly to > > Alan> q-> limits.max_sectors? Shouldn't there be a cleaner API for all > > Alan> this? > > > > Drivers are supposed to set the hard limit. The soft limit is a > > fs/block layer value and none of the device driver's business. > > _How_ are drivers supposed to set the hard limit? > > If they call blk_queue_max_sectors() then both the hard and soft limits > are affected, but at least the hard limit is set correctly. blk_queue_max_hw_sectors(). I can understand the confusion though, the comment is crap for blk_queue_max_sectors(). Mostly because the logic isn't as clean as it should be, I'll try and get that cleaned up. > If they call blk_queue_max_hw_sectors() then only the hard limit is > affected, but it cannot be set to a value less than 1024 > (BLK_DEF_MAX_SECTORS). Wouldn't it be more logical to allow the hard > limit to be set to anything at least as large as the page size, and > decrease the soft limit if it is larger than the new hard limit? The driver really should only set the hard limit, they should not change the soft setting. We cannot easily support < page size software not hardware limit. -- Jens Axboe -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Maximum data size in a single transfer for MS driver
@ 2010-02-25 16:59 scameron
2010-02-25 17:00 ` scameron
2010-02-25 17:18 ` scameron
0 siblings, 2 replies; 40+ messages in thread
From: scameron @ 2010-02-25 16:59 UTC (permalink / raw)
To: linux-scsi; +Cc: James.Bottomley, scameron, axboe
James.Bottomley@suse.de wrote:
> On Mon, 2010-02-22 at 18:20 +0530, Ramya Desai wrote:
> > On Fri, Feb 19, 2010 at 7:56 PM, James Bottomley
> > <James.Bottomley@suse.de> wrote:
> >
> > > Before we get into that, what architecture is this? There are a few,
> > > like arm that don't have architecture support for chaining, so they can
> > > never go over 128 segments.
> >
> > I am using the desktop PC to access my device. i.e, Intel processor
> > with x86 architecture.
>
> OK, so now see what max_hw_sectors_kb says ... if it's still 512 and
> you're sure you've got sg_tablesize set to something higher, there's
> likely something in the USB stack resetting it ... I suppose it's
> possible there's something else in your kernel doing that for the
> architecture, but you could rule that out by looking at
> max_hw_sectors_kb for either a SCSI or libata device and verifying it's
> much higher than 512.
>
> James
>
I might be off in the weeds, but I noticed this while looking at a similar
512k limit hpsa was hitting in the last few days, and I came across this,
in block/blk-settings.c:
void blk_queue_max_hw_sectors(struct request_queue *q, unsigned int max_sectors)
{
if (BLK_DEF_MAX_SECTORS > max_sectors)
q->limits.max_hw_sectors = BLK_DEF_MAX_SECTORS;
else
q->limits.max_hw_sectors = max_sectors;
}
EXPORT_SYMBOL(blk_queue_max_hw_sectors);
And BLK_DEF_MAX_SECTORS is 1024 (means, 512k), from blkdev.h:
#define MAX_PHYS_SEGMENTS 128
#define MAX_HW_SEGMENTS 128
#define SAFE_MAX_SECTORS 255
#define BLK_DEF_MAX_SECTORS 1024
So if you try to set max_hw_sectors to allow more than 512k via
blk_queue_max_hw_sectors(), it will cap it at 512k.
YOu can set q->limits.max_hw_sectors to a bigger number yourself
without using the helper function, though I don't know if that's
cool (though it seems to work with cciss, for example.) I haven't
tried it with hpsa, though did try changing blkdev.h BLK_DEF_MAX_SECTORS,
and rebuilding the kernel, and was able to get by the 512k limit.
-- steve
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Maximum data size in a single transfer for MS driver 2010-02-25 16:59 scameron @ 2010-02-25 17:00 ` scameron 2010-02-25 17:18 ` scameron 1 sibling, 0 replies; 40+ messages in thread From: scameron @ 2010-02-25 17:00 UTC (permalink / raw) To: linux-scsi; +Cc: James.Bottomley, axboe On Thu, Feb 25, 2010 at 10:59:01AM -0600, scameron@beardog.cce.hp.com wrote: > void blk_queue_max_hw_sectors(struct request_queue *q, unsigned int max_sectors) > { > if (BLK_DEF_MAX_SECTORS > max_sectors) > q->limits.max_hw_sectors = BLK_DEF_MAX_SECTORS; > else > q->limits.max_hw_sectors = max_sectors; > } > EXPORT_SYMBOL(blk_queue_max_hw_sectors); > > So if you try to set max_hw_sectors to allow more than 512k via No, I'm an idiot, nevermind. BLK_DEF_MAX_SECTORS is the minimum. -- steve ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Maximum data size in a single transfer for MS driver 2010-02-25 16:59 scameron 2010-02-25 17:00 ` scameron @ 2010-02-25 17:18 ` scameron 2010-02-25 17:28 ` Martin K. Petersen 1 sibling, 1 reply; 40+ messages in thread From: scameron @ 2010-02-25 17:18 UTC (permalink / raw) To: linux-scsi; +Cc: James.Bottomley, axboe, scameron BLK_DEF_MAX_SECTORS seems to act as a cap, as a MAXIMUM possible value for q->limits->max_sectors in blk_queue_max_sectors, but as a MINIMUM for q->limits.max_hw_sectors in blk_queue_max_hw_sectors. Is that intentional? Is this code in block/blk-settings.c correct? void blk_queue_max_sectors(struct request_queue *q, unsigned int max_sectors) { if ((max_sectors << 9) < PAGE_CACHE_SIZE) { max_sectors = 1 << (PAGE_CACHE_SHIFT - 9); printk(KERN_INFO "%s: set to minimum %d\n", __func__, max_sectors); } if (BLK_DEF_MAX_SECTORS > max_sectors) q->limits.max_hw_sectors = q->limits.max_sectors = max_sectors; else { q->limits.max_sectors = BLK_DEF_MAX_SECTORS; q->limits.max_hw_sectors = max_sectors; } } EXPORT_SYMBOL(blk_queue_max_sectors); void blk_queue_max_hw_sectors(struct request_queue *q, unsigned int max_sectors) { if (BLK_DEF_MAX_SECTORS > max_sectors) q->limits.max_hw_sectors = BLK_DEF_MAX_SECTORS; else q->limits.max_hw_sectors = max_sectors; } EXPORT_SYMBOL(blk_queue_max_hw_sectors); ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Maximum data size in a single transfer for MS driver 2010-02-25 17:18 ` scameron @ 2010-02-25 17:28 ` Martin K. Petersen 2010-02-25 17:41 ` Boaz Harrosh 0 siblings, 1 reply; 40+ messages in thread From: Martin K. Petersen @ 2010-02-25 17:28 UTC (permalink / raw) To: scameron; +Cc: linux-scsi, James.Bottomley, axboe >>>>> "scameron" == scameron <scameron@beardog.cce.hp.com> writes: scameron> BLK_DEF_MAX_SECTORS seems to act as a cap, as a MAXIMUM scameron> possible value for q->limits->max_sectors in blk_queue_max_sectors, scameron> but as a MINIMUM for q->limits.max_hw_sectors in scameron> blk_queue_max_hw_sectors. Please read the entire thread. blk_queue_max_hw_sectors() is dead, it was never used except briefly by DM. Device drivers should use blk_queue_max_sectors() to set their hard limit. max_sectors is a block layer soft limit that can be overridden on a per-device basis in /sys/block/foo/queue/max_sectors_kb. -- Martin K. Petersen Oracle Linux Engineering ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Maximum data size in a single transfer for MS driver 2010-02-25 17:28 ` Martin K. Petersen @ 2010-02-25 17:41 ` Boaz Harrosh 2010-02-25 17:58 ` Martin K. Petersen 2010-02-25 19:07 ` Martin K. Petersen 0 siblings, 2 replies; 40+ messages in thread From: Boaz Harrosh @ 2010-02-25 17:41 UTC (permalink / raw) To: Martin K. Petersen; +Cc: scameron, linux-scsi, James.Bottomley, axboe On 02/25/2010 09:28 AM, Martin K. Petersen wrote: >>>>>> "scameron" == scameron <scameron@beardog.cce.hp.com> writes: > > scameron> BLK_DEF_MAX_SECTORS seems to act as a cap, as a MAXIMUM > scameron> possible value for q->limits->max_sectors in blk_queue_max_sectors, > scameron> but as a MINIMUM for q->limits.max_hw_sectors in > scameron> blk_queue_max_hw_sectors. > > Please read the entire thread. > > blk_queue_max_hw_sectors() is dead, it was never used except briefly by > DM. Device drivers should use blk_queue_max_sectors() to set their hard > limit. > > max_sectors is a block layer soft limit that can be overridden on a > per-device basis in /sys/block/foo/queue/max_sectors_kb. > It seems like the confusion calls for a rename. We are made to believe that the accessors naming convention is the same as the queue member it changes. But here it is named as another very confusing member. At least if the name is not changed, a big fat comment is do, that says this is for drivers to change the *max_hw_sectors* though it is named after that other - not for drivers - member. Just my $0.017 Boaz ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Maximum data size in a single transfer for MS driver 2010-02-25 17:41 ` Boaz Harrosh @ 2010-02-25 17:58 ` Martin K. Petersen 2010-02-25 19:07 ` Martin K. Petersen 1 sibling, 0 replies; 40+ messages in thread From: Martin K. Petersen @ 2010-02-25 17:58 UTC (permalink / raw) To: Boaz Harrosh Cc: Martin K. Petersen, scameron, linux-scsi, James.Bottomley, axboe >>>>> "Boaz" == Boaz Harrosh <bharrosh@panasas.com> writes: Boaz> It seems like the confusion calls for a rename. We are made to Boaz> believe that the accessors naming convention is the same as the Boaz> queue member it changes. But here it is named as another very Boaz> confusing member. Boaz> At least if the name is not changed, a big fat comment is do, that Boaz> says this is for drivers to change the *max_hw_sectors* though it Boaz> is named after that other - not for drivers - member. I'm fine with renaming the function after the hw variant is gone. -- Martin K. Petersen Oracle Linux Engineering ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Maximum data size in a single transfer for MS driver 2010-02-25 17:41 ` Boaz Harrosh 2010-02-25 17:58 ` Martin K. Petersen @ 2010-02-25 19:07 ` Martin K. Petersen 1 sibling, 0 replies; 40+ messages in thread From: Martin K. Petersen @ 2010-02-25 19:07 UTC (permalink / raw) To: Boaz Harrosh Cc: Martin K. Petersen, scameron, linux-scsi, James.Bottomley, axboe Boaz> It seems like the confusion calls for a rename. We are made to Boaz> believe that the accessors naming convention is the same as the Boaz> queue member it changes. But here it is named as another very Boaz> confusing member. Like this, maybe? block: Rename blk_queue_max_sectors to blk_queue_max_hw_sectors The block layer calling convention is blk_queue_<limit name>. blk_queue_max_sectors predates this practice, leading to some confusion. Rename the function to appropriately reflect that its intended use is to set max_hw_sectors and update and expand the documentation. Also introduce a temporary wrapper for backwards compability. This can be removed after the merge window is closed. Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> --- diff --git a/arch/um/drivers/ubd_kern.c b/arch/um/drivers/ubd_kern.c index 5ff5546..c2051b0 100644 --- a/arch/um/drivers/ubd_kern.c +++ b/arch/um/drivers/ubd_kern.c @@ -747,7 +747,7 @@ static int ubd_open_dev(struct ubd *ubd_dev) ubd_dev->fd = fd; if(ubd_dev->cow.file != NULL){ - blk_queue_max_sectors(ubd_dev->queue, 8 * sizeof(long)); + blk_queue_max_hw_sectors(ubd_dev->queue, 8 * sizeof(long)); err = -ENOMEM; ubd_dev->cow.bitmap = vmalloc(ubd_dev->cow.bitmap_len); diff --git a/block/blk-settings.c b/block/blk-settings.c index 69b7c67..1a56840 100644 --- a/block/blk-settings.c +++ b/block/blk-settings.c @@ -154,7 +154,7 @@ void blk_queue_make_request(struct request_queue *q, make_request_fn *mfn) q->unplug_timer.data = (unsigned long)q; blk_set_default_limits(&q->limits); - blk_queue_max_sectors(q, SAFE_MAX_SECTORS); + blk_queue_max_hw_sectors(q, SAFE_MAX_SECTORS); /* * If the caller didn't supply a lock, fall back to our embedded @@ -210,15 +210,22 @@ void blk_queue_bounce_limit(struct request_queue *q, u64 dma_mask) EXPORT_SYMBOL(blk_queue_bounce_limit); /** - * blk_queue_max_sectors - set max sectors for a request for this queue + * blk_queue_max_hw_sectors - set max sectors for a request for this queue * @q: the request queue for the device * @max_sectors: max sectors in the usual 512b unit * * Description: - * Enables a low level driver to set an upper limit on the size of - * received requests. + * Enables a low level driver to set a hard upper limit, + * max_hw_sectors, on the size of requests. max_hw_sectors is set by + * the device driver based upon the combined capabilities of I/O + * controller and storage device. + * + * max_sectors is a soft limit imposed by the block layer for + * filesystem type requests. This value can be overridden on a + * per-device basis in /sys/block/<device>/queue/max_sectors_kb. + * The soft limit can not exceed max_hw_sectors. **/ -void blk_queue_max_sectors(struct request_queue *q, unsigned int max_sectors) +void blk_queue_max_hw_sectors(struct request_queue *q, unsigned int max_sectors) { if ((max_sectors << 9) < PAGE_CACHE_SIZE) { max_sectors = 1 << (PAGE_CACHE_SHIFT - 9); @@ -233,7 +240,7 @@ void blk_queue_max_sectors(struct request_queue *q, unsigned int max_sectors) q->limits.max_hw_sectors = max_sectors; } } -EXPORT_SYMBOL(blk_queue_max_sectors); +EXPORT_SYMBOL(blk_queue_max_hw_sectors); /** * blk_queue_max_discard_sectors - set max sectors for a single discard diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c index d096fbc..bea003a 100644 --- a/drivers/ata/libata-scsi.c +++ b/drivers/ata/libata-scsi.c @@ -1097,7 +1097,7 @@ static int ata_scsi_dev_config(struct scsi_device *sdev, dev->flags |= ATA_DFLAG_NO_UNLOAD; /* configure max sectors */ - blk_queue_max_sectors(sdev->request_queue, dev->max_sectors); + blk_queue_max_hw_sectors(sdev->request_queue, dev->max_sectors); if (dev->class == ATA_DEV_ATAPI) { struct request_queue *q = sdev->request_queue; diff --git a/drivers/block/DAC960.c b/drivers/block/DAC960.c index ce1fa92..8c4f937 100644 --- a/drivers/block/DAC960.c +++ b/drivers/block/DAC960.c @@ -2535,7 +2535,7 @@ static bool DAC960_RegisterBlockDevice(DAC960_Controller_T *Controller) RequestQueue->queuedata = Controller; blk_queue_max_hw_segments(RequestQueue, Controller->DriverScatterGatherLimit); blk_queue_max_phys_segments(RequestQueue, Controller->DriverScatterGatherLimit); - blk_queue_max_sectors(RequestQueue, Controller->MaxBlocksPerCommand); + blk_queue_max_hw_sectors(RequestQueue, Controller->MaxBlocksPerCommand); disk->queue = RequestQueue; sprintf(disk->disk_name, "rd/c%dd%d", Controller->ControllerNumber, n); disk->major = MajorNumber; diff --git a/drivers/block/brd.c b/drivers/block/brd.c index 4f68843..c6ddeac 100644 --- a/drivers/block/brd.c +++ b/drivers/block/brd.c @@ -434,7 +434,7 @@ static struct brd_device *brd_alloc(int i) goto out_free_dev; blk_queue_make_request(brd->brd_queue, brd_make_request); blk_queue_ordered(brd->brd_queue, QUEUE_ORDERED_TAG, NULL); - blk_queue_max_sectors(brd->brd_queue, 1024); + blk_queue_max_hw_sectors(brd->brd_queue, 1024); blk_queue_bounce_limit(brd->brd_queue, BLK_BOUNCE_ANY); disk = brd->brd_disk = alloc_disk(1 << part_shift); diff --git a/drivers/block/cciss.c b/drivers/block/cciss.c index 9291614..4f8198e 100644 --- a/drivers/block/cciss.c +++ b/drivers/block/cciss.c @@ -1801,7 +1801,7 @@ static int cciss_add_disk(ctlr_info_t *h, struct gendisk *disk, /* This is a limit in the driver and could be eliminated. */ blk_queue_max_phys_segments(disk->queue, h->maxsgentries); - blk_queue_max_sectors(disk->queue, h->cciss_max_sectors); + blk_queue_max_hw_sectors(disk->queue, h->cciss_max_sectors); blk_queue_softirq_done(disk->queue, cciss_softirq_done); diff --git a/drivers/block/drbd/drbd_nl.c b/drivers/block/drbd/drbd_nl.c index 1292e06..9b55e64 100644 --- a/drivers/block/drbd/drbd_nl.c +++ b/drivers/block/drbd/drbd_nl.c @@ -709,7 +709,7 @@ void drbd_setup_queue_param(struct drbd_conf *mdev, unsigned int max_seg_s) __mu max_seg_s = min(queue_max_sectors(b) * queue_logical_block_size(b), max_seg_s); - blk_queue_max_sectors(q, max_seg_s >> 9); + blk_queue_max_hw_sectors(q, max_seg_s >> 9); blk_queue_max_phys_segments(q, max_segments ? max_segments : MAX_PHYS_SEGMENTS); blk_queue_max_hw_segments(q, max_segments ? max_segments : MAX_HW_SEGMENTS); blk_queue_max_segment_size(q, max_seg_s); diff --git a/drivers/block/floppy.c b/drivers/block/floppy.c index 3266b4f..b9b1170 100644 --- a/drivers/block/floppy.c +++ b/drivers/block/floppy.c @@ -4234,7 +4234,7 @@ static int __init floppy_init(void) err = -ENOMEM; goto out_unreg_driver; } - blk_queue_max_sectors(floppy_queue, 64); + blk_queue_max_hw_sectors(floppy_queue, 64); blk_register_region(MKDEV(FLOPPY_MAJOR, 0), 256, THIS_MODULE, floppy_find, NULL, NULL); diff --git a/drivers/block/hd.c b/drivers/block/hd.c index d5cdce0..5116c65 100644 --- a/drivers/block/hd.c +++ b/drivers/block/hd.c @@ -719,7 +719,7 @@ static int __init hd_init(void) return -ENOMEM; } - blk_queue_max_sectors(hd_queue, 255); + blk_queue_max_hw_sectors(hd_queue, 255); init_timer(&device_timer); device_timer.function = hd_times_out; blk_queue_logical_block_size(hd_queue, 512); diff --git a/drivers/block/mg_disk.c b/drivers/block/mg_disk.c index 02b2583..5416c9a 100644 --- a/drivers/block/mg_disk.c +++ b/drivers/block/mg_disk.c @@ -980,7 +980,7 @@ static int mg_probe(struct platform_device *plat_dev) __func__, __LINE__); goto probe_err_6; } - blk_queue_max_sectors(host->breq, MG_MAX_SECTS); + blk_queue_max_hw_sectors(host->breq, MG_MAX_SECTS); blk_queue_logical_block_size(host->breq, MG_SECTOR_SIZE); init_timer(&host->timer); diff --git a/drivers/block/paride/pd.c b/drivers/block/paride/pd.c index 569e39e..e712cd5 100644 --- a/drivers/block/paride/pd.c +++ b/drivers/block/paride/pd.c @@ -906,7 +906,7 @@ static int __init pd_init(void) if (!pd_queue) goto out1; - blk_queue_max_sectors(pd_queue, cluster); + blk_queue_max_hw_sectors(pd_queue, cluster); if (register_blkdev(major, name)) goto out2; diff --git a/drivers/block/pktcdvd.c b/drivers/block/pktcdvd.c index 68b5957..a3bfd24 100644 --- a/drivers/block/pktcdvd.c +++ b/drivers/block/pktcdvd.c @@ -2360,7 +2360,7 @@ static int pkt_open_dev(struct pktcdvd_device *pd, fmode_t write) * even if the size is a multiple of the packet size. */ spin_lock_irq(q->queue_lock); - blk_queue_max_sectors(q, pd->settings.size); + blk_queue_max_hw_sectors(q, pd->settings.size); spin_unlock_irq(q->queue_lock); set_bit(PACKET_WRITABLE, &pd->flags); } else { @@ -2662,7 +2662,7 @@ static void pkt_init_queue(struct pktcdvd_device *pd) blk_queue_make_request(q, pkt_make_request); blk_queue_logical_block_size(q, CD_FRAMESIZE); - blk_queue_max_sectors(q, PACKET_MAX_SECTORS); + blk_queue_max_hw_sectors(q, PACKET_MAX_SECTORS); blk_queue_merge_bvec(q, pkt_merge_bvec); q->queuedata = pd; } diff --git a/drivers/block/ps3disk.c b/drivers/block/ps3disk.c index 03a130d..9cd1a4a 100644 --- a/drivers/block/ps3disk.c +++ b/drivers/block/ps3disk.c @@ -474,7 +474,7 @@ static int __devinit ps3disk_probe(struct ps3_system_bus_device *_dev) blk_queue_bounce_limit(queue, BLK_BOUNCE_HIGH); - blk_queue_max_sectors(queue, dev->bounce_size >> 9); + blk_queue_max_hw_sectors(queue, dev->bounce_size >> 9); blk_queue_segment_boundary(queue, -1UL); blk_queue_dma_alignment(queue, dev->blk_size-1); blk_queue_logical_block_size(queue, dev->blk_size); diff --git a/drivers/block/ps3vram.c b/drivers/block/ps3vram.c index 1fb6c31..6a0daf8 100644 --- a/drivers/block/ps3vram.c +++ b/drivers/block/ps3vram.c @@ -754,7 +754,7 @@ static int __devinit ps3vram_probe(struct ps3_system_bus_device *dev) blk_queue_max_phys_segments(queue, MAX_PHYS_SEGMENTS); blk_queue_max_hw_segments(queue, MAX_HW_SEGMENTS); blk_queue_max_segment_size(queue, MAX_SEGMENT_SIZE); - blk_queue_max_sectors(queue, SAFE_MAX_SECTORS); + blk_queue_max_hw_sectors(queue, SAFE_MAX_SECTORS); gendisk = alloc_disk(1); if (!gendisk) { diff --git a/drivers/block/sunvdc.c b/drivers/block/sunvdc.c index 411f064..dd30cdd 100644 --- a/drivers/block/sunvdc.c +++ b/drivers/block/sunvdc.c @@ -693,7 +693,7 @@ static int probe_disk(struct vdc_port *port) blk_queue_max_hw_segments(q, port->ring_cookies); blk_queue_max_phys_segments(q, port->ring_cookies); - blk_queue_max_sectors(q, port->max_xfer_size); + blk_queue_max_hw_sectors(q, port->max_xfer_size); g->major = vdc_major; g->first_minor = port->vio.vdev->dev_no << PARTITION_SHIFT; strcpy(g->disk_name, port->disk_name); diff --git a/drivers/block/ub.c b/drivers/block/ub.c index c739b20..79ca5ba 100644 --- a/drivers/block/ub.c +++ b/drivers/block/ub.c @@ -2323,7 +2323,7 @@ static int ub_probe_lun(struct ub_dev *sc, int lnum) blk_queue_max_hw_segments(q, UB_MAX_REQ_SG); blk_queue_max_phys_segments(q, UB_MAX_REQ_SG); blk_queue_segment_boundary(q, 0xffffffff); /* Dubious. */ - blk_queue_max_sectors(q, UB_MAX_SECTORS); + blk_queue_max_hw_sectors(q, UB_MAX_SECTORS); blk_queue_logical_block_size(q, lun->capacity.bsize); lun->disk = disk; diff --git a/drivers/block/viodasd.c b/drivers/block/viodasd.c index a8c8b56..d44ece7 100644 --- a/drivers/block/viodasd.c +++ b/drivers/block/viodasd.c @@ -473,7 +473,7 @@ retry: d->disk = g; blk_queue_max_hw_segments(q, VIOMAXBLOCKDMA); blk_queue_max_phys_segments(q, VIOMAXBLOCKDMA); - blk_queue_max_sectors(q, VIODASD_MAXSECTORS); + blk_queue_max_hw_sectors(q, VIODASD_MAXSECTORS); g->major = VIODASD_MAJOR; g->first_minor = dev_no << PARTITION_SHIFT; if (dev_no >= 26) diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c index 51042f0..53750bb 100644 --- a/drivers/block/virtio_blk.c +++ b/drivers/block/virtio_blk.c @@ -352,7 +352,7 @@ static int __devinit virtblk_probe(struct virtio_device *vdev) blk_queue_bounce_limit(vblk->disk->queue, BLK_BOUNCE_ANY); /* No real sector limit. */ - blk_queue_max_sectors(vblk->disk->queue, -1U); + blk_queue_max_hw_sectors(vblk->disk->queue, -1U); /* Host can optionally specify maximum segment size and number of * segments. */ diff --git a/drivers/block/xd.c b/drivers/block/xd.c index d1fd032..1a325fb 100644 --- a/drivers/block/xd.c +++ b/drivers/block/xd.c @@ -242,7 +242,7 @@ static int __init xd_init(void) } /* xd_maxsectors depends on controller - so set after detection */ - blk_queue_max_sectors(xd_queue, xd_maxsectors); + blk_queue_max_hw_sectors(xd_queue, xd_maxsectors); for (i = 0; i < xd_drives; i++) add_disk(xd_gendisk[i]); diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c index 05a31e5..1bd08b3 100644 --- a/drivers/block/xen-blkfront.c +++ b/drivers/block/xen-blkfront.c @@ -346,7 +346,7 @@ static int xlvbd_init_blk_queue(struct gendisk *gd, u16 sector_size) /* Hard sector size and max sectors impersonate the equiv. hardware. */ blk_queue_logical_block_size(rq, sector_size); - blk_queue_max_sectors(rq, 512); + blk_queue_max_hw_sectors(rq, 512); /* Each segment in a request is up to an aligned page in size. */ blk_queue_segment_boundary(rq, PAGE_SIZE - 1); diff --git a/drivers/cdrom/viocd.c b/drivers/cdrom/viocd.c index 57ca69e..b1dfd23 100644 --- a/drivers/cdrom/viocd.c +++ b/drivers/cdrom/viocd.c @@ -618,7 +618,7 @@ static int viocd_probe(struct vio_dev *vdev, const struct vio_device_id *id) sizeof(gendisk->disk_name)); blk_queue_max_hw_segments(q, 1); blk_queue_max_phys_segments(q, 1); - blk_queue_max_sectors(q, 4096 / 512); + blk_queue_max_hw_sectors(q, 4096 / 512); gendisk->queue = q; gendisk->fops = &viocd_fops; gendisk->flags = GENHD_FL_CD|GENHD_FL_REMOVABLE; diff --git a/drivers/firewire/sbp2.c b/drivers/firewire/sbp2.c index d485cdd..70fef40 100644 --- a/drivers/firewire/sbp2.c +++ b/drivers/firewire/sbp2.c @@ -1571,7 +1571,7 @@ static int sbp2_scsi_slave_configure(struct scsi_device *sdev) sdev->start_stop_pwr_cond = 1; if (lu->tgt->workarounds & SBP2_WORKAROUND_128K_MAX_TRANS) - blk_queue_max_sectors(sdev->request_queue, 128 * 1024 / 512); + blk_queue_max_hw_sectors(sdev->request_queue, 128 * 1024 / 512); blk_queue_max_segment_size(sdev->request_queue, SBP2_MAX_SEG_SIZE); diff --git a/drivers/ide/ide-disk.c b/drivers/ide/ide-disk.c index 7f87801..3b128dc 100644 --- a/drivers/ide/ide-disk.c +++ b/drivers/ide/ide-disk.c @@ -679,7 +679,7 @@ static void ide_disk_setup(ide_drive_t *drive) if (max_s > hwif->rqsize) max_s = hwif->rqsize; - blk_queue_max_sectors(q, max_s); + blk_queue_max_hw_sectors(q, max_s); } printk(KERN_INFO "%s: max request size: %dKiB\n", drive->name, diff --git a/drivers/ide/ide-floppy.c b/drivers/ide/ide-floppy.c index fefbdfc..efd9076 100644 --- a/drivers/ide/ide-floppy.c +++ b/drivers/ide/ide-floppy.c @@ -486,7 +486,7 @@ static void ide_floppy_setup(ide_drive_t *drive) drive->atapi_flags |= IDE_AFLAG_ZIP_DRIVE; /* This value will be visible in the /proc/ide/hdx/settings */ drive->pc_delay = IDEFLOPPY_PC_DELAY; - blk_queue_max_sectors(drive->queue, 64); + blk_queue_max_hw_sectors(drive->queue, 64); } /* @@ -494,7 +494,7 @@ static void ide_floppy_setup(ide_drive_t *drive) * nasty clicking noises without it, so please don't remove this. */ if (strncmp((char *)&id[ATA_ID_PROD], "IOMEGA Clik!", 11) == 0) { - blk_queue_max_sectors(drive->queue, 64); + blk_queue_max_hw_sectors(drive->queue, 64); drive->atapi_flags |= IDE_AFLAG_CLIK_DRIVE; /* IOMEGA Clik! drives do not support lock/unlock commands */ drive->dev_flags &= ~IDE_DFLAG_DOORLOCKING; diff --git a/drivers/ide/ide-probe.c b/drivers/ide/ide-probe.c index 4d76ba4..1ec8b31 100644 --- a/drivers/ide/ide-probe.c +++ b/drivers/ide/ide-probe.c @@ -774,7 +774,7 @@ static int ide_init_queue(ide_drive_t *drive) if (hwif->rqsize < max_sectors) max_sectors = hwif->rqsize; - blk_queue_max_sectors(q, max_sectors); + blk_queue_max_hw_sectors(q, max_sectors); #ifdef CONFIG_PCI /* When we have an IOMMU, we may have a problem where pci_map_sg() diff --git a/drivers/ieee1394/sbp2.c b/drivers/ieee1394/sbp2.c index f199896..c88696a 100644 --- a/drivers/ieee1394/sbp2.c +++ b/drivers/ieee1394/sbp2.c @@ -2020,7 +2020,7 @@ static int sbp2scsi_slave_configure(struct scsi_device *sdev) if (lu->workarounds & SBP2_WORKAROUND_POWER_CONDITION) sdev->start_stop_pwr_cond = 1; if (lu->workarounds & SBP2_WORKAROUND_128K_MAX_TRANS) - blk_queue_max_sectors(sdev->request_queue, 128 * 1024 / 512); + blk_queue_max_hw_sectors(sdev->request_queue, 128 * 1024 / 512); blk_queue_max_segment_size(sdev->request_queue, SBP2_MAX_SEG_SIZE); return 0; diff --git a/drivers/md/linear.c b/drivers/md/linear.c index 7409d5f..7d7714d 100644 --- a/drivers/md/linear.c +++ b/drivers/md/linear.c @@ -177,7 +177,7 @@ static linear_conf_t *linear_conf(mddev_t *mddev, int raid_disks) */ if (rdev->bdev->bd_disk->queue->merge_bvec_fn && queue_max_sectors(mddev->queue) > (PAGE_SIZE>>9)) - blk_queue_max_sectors(mddev->queue, PAGE_SIZE>>9); + blk_queue_max_hw_sectors(mddev->queue, PAGE_SIZE>>9); conf->array_sectors += rdev->sectors; cnt++; diff --git a/drivers/md/multipath.c b/drivers/md/multipath.c index cc8caa7..bb810a0 100644 --- a/drivers/md/multipath.c +++ b/drivers/md/multipath.c @@ -308,7 +308,7 @@ static int multipath_add_disk(mddev_t *mddev, mdk_rdev_t *rdev) */ if (q->merge_bvec_fn && queue_max_sectors(q) > (PAGE_SIZE>>9)) - blk_queue_max_sectors(mddev->queue, PAGE_SIZE>>9); + blk_queue_max_hw_sectors(mddev->queue, PAGE_SIZE>>9); conf->working_disks++; mddev->degraded--; @@ -478,7 +478,7 @@ static int multipath_run (mddev_t *mddev) * a merge_bvec_fn to be involved in multipath */ if (rdev->bdev->bd_disk->queue->merge_bvec_fn && queue_max_sectors(mddev->queue) > (PAGE_SIZE>>9)) - blk_queue_max_sectors(mddev->queue, PAGE_SIZE>>9); + blk_queue_max_hw_sectors(mddev->queue, PAGE_SIZE>>9); if (!test_bit(Faulty, &rdev->flags)) conf->working_disks++; diff --git a/drivers/md/raid0.c b/drivers/md/raid0.c index 086dec4..3007f1c 100644 --- a/drivers/md/raid0.c +++ b/drivers/md/raid0.c @@ -182,7 +182,7 @@ static int create_strip_zones(mddev_t *mddev) if (rdev1->bdev->bd_disk->queue->merge_bvec_fn && queue_max_sectors(mddev->queue) > (PAGE_SIZE>>9)) - blk_queue_max_sectors(mddev->queue, PAGE_SIZE>>9); + blk_queue_max_hw_sectors(mddev->queue, PAGE_SIZE>>9); if (!smallest || (rdev1->sectors < smallest->sectors)) smallest = rdev1; @@ -325,7 +325,7 @@ static int raid0_run(mddev_t *mddev) } if (md_check_no_bitmap(mddev)) return -EINVAL; - blk_queue_max_sectors(mddev->queue, mddev->chunk_sectors); + blk_queue_max_hw_sectors(mddev->queue, mddev->chunk_sectors); mddev->queue->queue_lock = &mddev->queue->__queue_lock; ret = create_strip_zones(mddev); diff --git a/drivers/md/raid1.c b/drivers/md/raid1.c index 51da0f7..df2fa68 100644 --- a/drivers/md/raid1.c +++ b/drivers/md/raid1.c @@ -1158,7 +1158,7 @@ static int raid1_add_disk(mddev_t *mddev, mdk_rdev_t *rdev) */ if (rdev->bdev->bd_disk->queue->merge_bvec_fn && queue_max_sectors(mddev->queue) > (PAGE_SIZE>>9)) - blk_queue_max_sectors(mddev->queue, PAGE_SIZE>>9); + blk_queue_max_hw_sectors(mddev->queue, PAGE_SIZE>>9); p->head_position = 0; rdev->raid_disk = mirror; @@ -2103,7 +2103,7 @@ static int run(mddev_t *mddev) */ if (rdev->bdev->bd_disk->queue->merge_bvec_fn && queue_max_sectors(mddev->queue) > (PAGE_SIZE>>9)) - blk_queue_max_sectors(mddev->queue, PAGE_SIZE>>9); + blk_queue_max_hw_sectors(mddev->queue, PAGE_SIZE>>9); } mddev->degraded = 0; diff --git a/drivers/md/raid10.c b/drivers/md/raid10.c index ae3153b..b2b00f7 100644 --- a/drivers/md/raid10.c +++ b/drivers/md/raid10.c @@ -1161,7 +1161,7 @@ static int raid10_add_disk(mddev_t *mddev, mdk_rdev_t *rdev) */ if (rdev->bdev->bd_disk->queue->merge_bvec_fn && queue_max_sectors(mddev->queue) > (PAGE_SIZE>>9)) - blk_queue_max_sectors(mddev->queue, PAGE_SIZE>>9); + blk_queue_max_hw_sectors(mddev->queue, PAGE_SIZE>>9); p->head_position = 0; rdev->raid_disk = mirror; @@ -2260,7 +2260,7 @@ static int run(mddev_t *mddev) */ if (rdev->bdev->bd_disk->queue->merge_bvec_fn && queue_max_sectors(mddev->queue) > (PAGE_SIZE>>9)) - blk_queue_max_sectors(mddev->queue, PAGE_SIZE>>9); + blk_queue_max_hw_sectors(mddev->queue, PAGE_SIZE>>9); disk->head_position = 0; } diff --git a/drivers/memstick/core/mspro_block.c b/drivers/memstick/core/mspro_block.c index bd83fa0..44d4178 100644 --- a/drivers/memstick/core/mspro_block.c +++ b/drivers/memstick/core/mspro_block.c @@ -1226,7 +1226,7 @@ static int mspro_block_init_disk(struct memstick_dev *card) blk_queue_prep_rq(msb->queue, mspro_block_prepare_req); blk_queue_bounce_limit(msb->queue, limit); - blk_queue_max_sectors(msb->queue, MSPRO_BLOCK_MAX_PAGES); + blk_queue_max_hw_sectors(msb->queue, MSPRO_BLOCK_MAX_PAGES); blk_queue_max_phys_segments(msb->queue, MSPRO_BLOCK_MAX_SEGS); blk_queue_max_hw_segments(msb->queue, MSPRO_BLOCK_MAX_SEGS); blk_queue_max_segment_size(msb->queue, diff --git a/drivers/message/i2o/i2o_block.c b/drivers/message/i2o/i2o_block.c index e39986a..d033cfd 100644 --- a/drivers/message/i2o/i2o_block.c +++ b/drivers/message/i2o/i2o_block.c @@ -1066,7 +1066,7 @@ static int i2o_block_probe(struct device *dev) queue->queuedata = i2o_blk_dev; blk_queue_max_phys_segments(queue, I2O_MAX_PHYS_SEGMENTS); - blk_queue_max_sectors(queue, max_sectors); + blk_queue_max_hw_sectors(queue, max_sectors); blk_queue_max_hw_segments(queue, i2o_sg_tablesize(c, body_size)); osm_debug("max sectors = %d\n", queue->max_sectors); diff --git a/drivers/mmc/card/queue.c b/drivers/mmc/card/queue.c index c5a7a85..09b633d 100644 --- a/drivers/mmc/card/queue.c +++ b/drivers/mmc/card/queue.c @@ -154,7 +154,7 @@ int mmc_init_queue(struct mmc_queue *mq, struct mmc_card *card, spinlock_t *lock if (mq->bounce_buf) { blk_queue_bounce_limit(mq->queue, BLK_BOUNCE_ANY); - blk_queue_max_sectors(mq->queue, bouncesz / 512); + blk_queue_max_hw_sectors(mq->queue, bouncesz / 512); blk_queue_max_phys_segments(mq->queue, bouncesz / 512); blk_queue_max_hw_segments(mq->queue, bouncesz / 512); blk_queue_max_segment_size(mq->queue, bouncesz); @@ -180,7 +180,7 @@ int mmc_init_queue(struct mmc_queue *mq, struct mmc_card *card, spinlock_t *lock if (!mq->bounce_buf) { blk_queue_bounce_limit(mq->queue, limit); - blk_queue_max_sectors(mq->queue, + blk_queue_max_hw_sectors(mq->queue, min(host->max_blk_count, host->max_req_size / 512)); blk_queue_max_phys_segments(mq->queue, host->max_phys_segs); blk_queue_max_hw_segments(mq->queue, host->max_hw_segs); diff --git a/drivers/s390/block/dasd.c b/drivers/s390/block/dasd.c index 5905936..14b1e25 100644 --- a/drivers/s390/block/dasd.c +++ b/drivers/s390/block/dasd.c @@ -2129,7 +2129,7 @@ static void dasd_setup_queue(struct dasd_block *block) blk_queue_logical_block_size(block->request_queue, block->bp_block); max = block->base->discipline->max_blocks << block->s2b_shift; - blk_queue_max_sectors(block->request_queue, max); + blk_queue_max_hw_sectors(block->request_queue, max); blk_queue_max_phys_segments(block->request_queue, -1L); blk_queue_max_hw_segments(block->request_queue, -1L); /* with page sized segments we can translate each segement into diff --git a/drivers/s390/char/tape_block.c b/drivers/s390/char/tape_block.c index 8d3d720..509ed05 100644 --- a/drivers/s390/char/tape_block.c +++ b/drivers/s390/char/tape_block.c @@ -222,7 +222,7 @@ tapeblock_setup_device(struct tape_device * device) goto cleanup_queue; blk_queue_logical_block_size(blkdat->request_queue, TAPEBLOCK_HSEC_SIZE); - blk_queue_max_sectors(blkdat->request_queue, TAPEBLOCK_MAX_SEC); + blk_queue_max_hw_sectors(blkdat->request_queue, TAPEBLOCK_MAX_SEC); blk_queue_max_phys_segments(blkdat->request_queue, -1L); blk_queue_max_hw_segments(blkdat->request_queue, -1L); blk_queue_max_segment_size(blkdat->request_queue, -1L); diff --git a/drivers/scsi/ipr.c b/drivers/scsi/ipr.c index 9e52d16..032f0d0 100644 --- a/drivers/scsi/ipr.c +++ b/drivers/scsi/ipr.c @@ -3674,7 +3674,7 @@ static int ipr_slave_configure(struct scsi_device *sdev) if (ipr_is_vset_device(res)) { blk_queue_rq_timeout(sdev->request_queue, IPR_VSET_RW_TIMEOUT); - blk_queue_max_sectors(sdev->request_queue, IPR_VSET_MAX_SECTORS); + blk_queue_max_hw_sectors(sdev->request_queue, IPR_VSET_MAX_SECTORS); } if (ipr_is_vset_device(res) || ipr_is_scsi_disk(res)) sdev->allow_restart = 1; diff --git a/drivers/scsi/pmcraid.c b/drivers/scsi/pmcraid.c index b6f1ef9..9b1c143 100644 --- a/drivers/scsi/pmcraid.c +++ b/drivers/scsi/pmcraid.c @@ -235,7 +235,7 @@ static int pmcraid_slave_configure(struct scsi_device *scsi_dev) scsi_dev->allow_restart = 1; blk_queue_rq_timeout(scsi_dev->request_queue, PMCRAID_VSET_IO_TIMEOUT); - blk_queue_max_sectors(scsi_dev->request_queue, + blk_queue_max_hw_sectors(scsi_dev->request_queue, PMCRAID_VSET_MAX_SECTORS); } diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c index c664242..ac3cca7 100644 --- a/drivers/scsi/scsi_lib.c +++ b/drivers/scsi/scsi_lib.c @@ -1627,7 +1627,7 @@ struct request_queue *__scsi_alloc_queue(struct Scsi_Host *shost, blk_queue_max_hw_segments(q, shost->sg_tablesize); blk_queue_max_phys_segments(q, SCSI_MAX_SG_CHAIN_SEGMENTS); - blk_queue_max_sectors(q, shost->max_sectors); + blk_queue_max_hw_sectors(q, shost->max_sectors); blk_queue_bounce_limit(q, scsi_calculate_bounce_limit(shost)); blk_queue_segment_boundary(q, shost->dma_boundary); dma_set_seg_boundary(dev, shost->dma_boundary); diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c index 012f73a..5d9b513 100644 --- a/drivers/scsi/scsi_scan.c +++ b/drivers/scsi/scsi_scan.c @@ -879,7 +879,7 @@ static int scsi_add_lun(struct scsi_device *sdev, unsigned char *inq_result, * broken RA4x00 Compaq Disk Array */ if (*bflags & BLIST_MAX_512) - blk_queue_max_sectors(sdev->request_queue, 512); + blk_queue_max_hw_sectors(sdev->request_queue, 512); /* * Some devices may not want to have a start command automatically diff --git a/drivers/usb/storage/scsiglue.c b/drivers/usb/storage/scsiglue.c index e5e6df3..aadc16b 100644 --- a/drivers/usb/storage/scsiglue.c +++ b/drivers/usb/storage/scsiglue.c @@ -134,14 +134,14 @@ static int slave_configure(struct scsi_device *sdev) if (us->fflags & US_FL_MAX_SECTORS_MIN) max_sectors = PAGE_CACHE_SIZE >> 9; if (queue_max_sectors(sdev->request_queue) > max_sectors) - blk_queue_max_sectors(sdev->request_queue, + blk_queue_max_hw_sectors(sdev->request_queue, max_sectors); } else if (sdev->type == TYPE_TAPE) { /* Tapes need much higher max_sector limits, so just * raise it to the maximum possible (4 GB / 512) and * let the queue segment size sort out the real limit. */ - blk_queue_max_sectors(sdev->request_queue, 0x7FFFFF); + blk_queue_max_hw_sectors(sdev->request_queue, 0x7FFFFF); } /* Some USB host controllers can't do DMA; they have to use PIO. @@ -495,7 +495,7 @@ static ssize_t store_max_sectors(struct device *dev, struct device_attribute *at unsigned short ms; if (sscanf(buf, "%hu", &ms) > 0 && ms <= SCSI_DEFAULT_MAX_SECTORS) { - blk_queue_max_sectors(sdev->request_queue, ms); + blk_queue_max_hw_sectors(sdev->request_queue, ms); return strlen(buf); } return -EINVAL; diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h index 0b05791..8c0ef3a 100644 --- a/include/linux/blkdev.h +++ b/include/linux/blkdev.h @@ -920,7 +920,14 @@ extern struct request_queue *blk_init_queue(request_fn_proc *, spinlock_t *); extern void blk_cleanup_queue(struct request_queue *); extern void blk_queue_make_request(struct request_queue *, make_request_fn *); extern void blk_queue_bounce_limit(struct request_queue *, u64); -extern void blk_queue_max_sectors(struct request_queue *, unsigned int); +extern void blk_queue_max_hw_sectors(struct request_queue *, unsigned int); + +/* Temporary compatibility wrapper */ +static inline void blk_queue_max_sectors(struct request_queue *q, unsigned int max) +{ + blk_queue_max_hw_sectors(q, max); +} + extern void blk_queue_max_phys_segments(struct request_queue *, unsigned short); extern void blk_queue_max_hw_segments(struct request_queue *, unsigned short); extern void blk_queue_max_segment_size(struct request_queue *, unsigned int); ^ permalink raw reply related [flat|nested] 40+ messages in thread
end of thread, other threads:[~2010-02-26 3:37 UTC | newest] Thread overview: 40+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2010-02-17 12:37 Maximum data size in a single transfer for MS driver Ramya Desai [not found] ` <3e7aae31002170437i52ba4ba1w10c1ff224d9b37ef-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2010-02-17 15:02 ` James Bottomley 2010-02-18 8:46 ` Ramya Desai 2010-02-18 15:47 ` James Bottomley [not found] ` <1266508049.4355.37.camel-0iu6Cu4xQGLYCGPCin2YbQ@public.gmane.org> 2010-02-18 16:24 ` Alan Stern [not found] ` <Pine.LNX.4.44L0.1002181115120.1294-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org> 2010-02-18 16:30 ` James Bottomley [not found] ` <1266510627.4355.41.camel-0iu6Cu4xQGLYCGPCin2YbQ@public.gmane.org> 2010-02-18 16:51 ` Alan Stern 2010-02-19 12:43 ` Ramya Desai 2010-02-19 14:26 ` James Bottomley 2010-02-22 12:50 ` Ramya Desai [not found] ` <3e7aae31002220450o6f83d2f3n45c795d70ef01f72-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2010-02-22 13:06 ` James Bottomley 2010-02-22 14:15 ` Ramya Desai 2010-02-22 17:44 ` Alan Stern 2010-02-22 18:07 ` Alan Stern [not found] ` <Pine.LNX.4.44L0.1002221232160.1251-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org> 2010-02-23 15:29 ` Ramya Desai 2010-02-23 16:49 ` Alan Stern 2010-02-23 17:00 ` Martin K. Petersen 2010-02-23 18:01 ` Alan Stern [not found] ` <Pine.LNX.4.44L0.1002231253320.1308-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org> 2010-02-24 13:07 ` Ramya Desai 2010-02-24 13:12 ` Jens Axboe 2010-02-24 16:30 ` Alan Stern 2010-02-24 19:07 ` Jens Axboe 2010-02-25 14:47 ` Ramya Desai 2010-02-25 14:44 ` Ramya Desai 2010-02-25 16:37 ` Alan Stern 2010-02-25 16:49 ` Martin K. Petersen 2010-02-25 16:53 ` Martin K. Petersen 2010-02-25 17:54 ` Jens Axboe [not found] ` <yq1zl2xl0j3.fsf-+q57XtR/GgMb6DWv4sQWN6xOck334EZe@public.gmane.org> 2010-02-25 18:28 ` Alan Stern 2010-02-25 19:05 ` Martin K. Petersen [not found] ` <yq1iq9lkueh.fsf-+q57XtR/GgMb6DWv4sQWN6xOck334EZe@public.gmane.org> 2010-02-25 19:47 ` Alan Stern 2010-02-26 3:37 ` Martin K. Petersen [not found] ` <Pine.LNX.4.44L0.1002251132170.1686-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org> 2010-02-25 17:52 ` Jens Axboe 2010-02-25 16:59 scameron 2010-02-25 17:00 ` scameron 2010-02-25 17:18 ` scameron 2010-02-25 17:28 ` Martin K. Petersen 2010-02-25 17:41 ` Boaz Harrosh 2010-02-25 17:58 ` Martin K. Petersen 2010-02-25 19:07 ` Martin K. Petersen
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.