Maximum data size in a single transfer for MS driver

Maximum data size in a single transfer for MS driver

[Ramya Desai]

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

Re: Maximum data size in a single transfer for MS driver

[James Bottomley]

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

Re: Maximum data size in a single transfer for MS driver

[Ramya Desai]

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

Re: Maximum data size in a single transfer for MS driver

[James Bottomley]

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

Re: Maximum data size in a single transfer for MS driver

[Alan Stern]

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

Re: Maximum data size in a single transfer for MS driver

[James Bottomley]

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

Re: Maximum data size in a single transfer for MS driver

[Alan Stern]

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

Re: Maximum data size in a single transfer for MS driver

[Ramya Desai]

> 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

Re: Maximum data size in a single transfer for MS driver

[James Bottomley]

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

Re: Maximum data size in a single transfer for MS driver

[Ramya Desai]

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

Re: Maximum data size in a single transfer for MS driver

[James Bottomley]

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

Re: Maximum data size in a single transfer for MS driver

[Ramya Desai]

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

Re: Maximum data size in a single transfer for MS driver

[Alan Stern]

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

Re: Maximum data size in a single transfer for MS driver

[Alan Stern]

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

Re: Maximum data size in a single transfer for MS driver

[Ramya Desai]

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

Re: Maximum data size in a single transfer for MS driver

[Alan Stern]

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

Re: Maximum data size in a single transfer for MS driver

[Martin K. Petersen]

>>>>> "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

Re: Maximum data size in a single transfer for MS driver

[Alan Stern]

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

Re: Maximum data size in a single transfer for MS driver

[Ramya Desai]

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

Re: Maximum data size in a single transfer for MS driver

[Jens Axboe]

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

Re: Maximum data size in a single transfer for MS driver

[Alan Stern]

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

Re: Maximum data size in a single transfer for MS driver

[Jens Axboe]

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

Re: Maximum data size in a single transfer for MS driver

[Ramya Desai]

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

Re: Maximum data size in a single transfer for MS driver

[Ramya Desai]

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

Re: Maximum data size in a single transfer for MS driver

[Alan Stern]

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

Re: Maximum data size in a single transfer for MS driver

[Martin K. Petersen]

>>>>> "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

Re: Maximum data size in a single transfer for MS driver

[Martin K. Petersen]

>>>>> "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);

Re: Maximum data size in a single transfer for MS driver

[Jens Axboe]

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

Re: Maximum data size in a single transfer for MS driver

[Jens Axboe]

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

Re: Maximum data size in a single transfer for MS driver

[Alan Stern]

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

Re: Maximum data size in a single transfer for MS driver

[Martin K. Petersen]

>>>>> "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

Re: Maximum data size in a single transfer for MS driver

[Alan Stern]

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

Re: Maximum data size in a single transfer for MS driver

[Martin K. Petersen]

>>>>> "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

Re: Maximum data size in a single transfer for MS driver

[Martin K. Petersen]

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);

Re: Maximum data size in a single transfer for MS driver

[Martin K. Petersen]

>>>>> "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

Re: Maximum data size in a single transfer for MS driver

[Boaz Harrosh]

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

Re: Maximum data size in a single transfer for MS driver

[Martin K. Petersen]

>>>>> "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

Re: Maximum data size in a single transfer for MS driver

[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);

Re: Maximum data size in a single transfer for MS driver

[scameron]

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

Re: Maximum data size in a single transfer for MS driver

[scameron]

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