another unusual flag for a really limited device

[Doug Maxey]

Howdy,

Have run across a virtual USB host that needs (yes, I know, a strong
word :) to limit the maximum number of sectors transferred in a single
request to 32. In theory, the device should be fine with 32k, but
when it loses, it never seems to recover without a full reset.

Did some searching in the archives, but saw nothing.

What about something along the lines of adding UL_FL_MAX_SECTORS_32 to
follow the pattern used with MAX_SECTORS_64, thusly?

Based on linus 2.6.24-rc2.

++doug

----
diff --git a/drivers/usb/storage/scsiglue.c b/drivers/usb/storage/scsiglue.c
index 1ba19ea..3fe0712 100644
--- a/drivers/usb/storage/scsiglue.c
+++ b/drivers/usb/storage/scsiglue.c
@@ -118,6 +118,10 @@ static int slave_configure(struct scsi_device *sdev)
sdev->request_queue->max_sectors > 64)
blk_queue_max_sectors(sdev->request_queue, 64);

+ if ((us->flags & US_FL_MAX_SECTORS_32) &&
+ sdev->request_queue->max_sectors > 32)
+ blk_queue_max_sectors(sdev->request_queue, 32);
+
/* We can't put these settings in slave_alloc() because that gets
* called before the device type is known. Consequently these
* settings can't be overridden via the scsi devinfo mechanism. */
diff --git a/drivers/usb/storage/unusual_devs.h b/drivers/usb/storage/unusual_devs.h
index 22ab238..56f0b43 100644
--- a/drivers/usb/storage/unusual_devs.h
+++ b/drivers/usb/storage/unusual_devs.h
@@ -376,6 +376,13 @@ UNUSUAL_DEV( 0x04b0, 0x0417, 0x0100, 0x0100,
US_SC_DEVICE, US_PR_DEVICE, NULL,
US_FL_FIX_CAPACITY),

+/* Reported by Doug Maxey (***@austin.ibm.com) */
+UNUSUAL_DEV( 0x04b3, 0x4003, 0x0110, 0x0110,
+ "IBM",
+ "IBM RSA2",
+ US_SC_DEVICE, US_PR_CB, NULL,
+ US_FL_MAX_SECTORS_32),
+
/* BENQ DC5330
* Reported by Manuel Fombuena <***@ya.com> and
* Frank Copeland <***@thingy.apana.org.au> */
diff --git a/include/linux/usb_usual.h b/include/linux/usb_usual.h
index 1b792b9..37bb4a0 100644
--- a/include/linux/usb_usual.h
+++ b/include/linux/usb_usual.h
@@ -48,7 +48,10 @@
US_FLAG(IGNORE_DEVICE, 0x00000800) \
/* Don't claim device */ \
US_FLAG(CAPACITY_HEURISTICS, 0x00001000) \
- /* sometimes sizes is too big */
+ /* sometimes sizes is too big */ \
+ US_FLAG(MAX_SECTORS_32, 0x00001000) \
+ /* Sets max_sectors to 32 */
+

#define US_FLAG(name, value) US_FL_##name = value ,
enum { US_DO_ALL_FLAGS };



-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
linux-usb-***@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

[Pete Zaitcev]

Post by Doug Maxey
What about something along the lines of adding UL_FL_MAX_SECTORS_32 to
follow the pattern used with MAX_SECTORS_64, thusly?

Certain versions of RSA-II might require different values of the limit,
so I would rather see an init function than a flag, if possible in 2.6.

-- Pete

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
linux-usb-***@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

[Matthew Dharm]

Post by Doug Maxey
Have run across a virtual USB host that needs (yes, I know, a strong
word :) to limit the maximum number of sectors transferred in a single
request to 32. In theory, the device should be fine with 32k, but
when it loses, it never seems to recover without a full reset.
Did some searching in the archives, but saw nothing.
What about something along the lines of adding UL_FL_MAX_SECTORS_32 to
follow the pattern used with MAX_SECTORS_64, thusly?
Based on linus 2.6.24-rc2.

I can't say I'm really happy about another flag, but I can't exactly object
too strongly. This is probably the best fix we're going to find.

Tho, I'm seriously tempted to make the choice MAX_SECTORS_64 and
MAX_SECTORS_1 -- if a device can't handle 64 sectors at a time, then let's
just limit it to 1 and call it a day. Otherwise we're going to wind up
with MAX_SECTORS_32, _16, _8, _4, and _2 someday.

Matt

[Alan Stern]

Post by Matthew Dharm

Post by Doug Maxey
Have run across a virtual USB host that needs (yes, I know, a strong
word :) to limit the maximum number of sectors transferred in a single
request to 32. In theory, the device should be fine with 32k, but
when it loses, it never seems to recover without a full reset.
Did some searching in the archives, but saw nothing.
What about something along the lines of adding UL_FL_MAX_SECTORS_32 to
follow the pattern used with MAX_SECTORS_64, thusly?
Based on linus 2.6.24-rc2.

I can't say I'm really happy about another flag, but I can't exactly object
too strongly. This is probably the best fix we're going to find.
Tho, I'm seriously tempted to make the choice MAX_SECTORS_64 and
MAX_SECTORS_1 -- if a device can't handle 64 sectors at a time, then let's
just limit it to 1 and call it a day. Otherwise we're going to wind up
with MAX_SECTORS_32, _16, _8, _4, and _2 someday.

1 won't work; max_sectors has to be at least the size of a memory
page. This is enforced by the block layer's request_queue routines.
But we certainly could have a MAX_SECTORS_MIN flag.

Alan Stern


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
linux-usb-***@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

[Matthew Dharm]

Post by Alan Stern

Post by Matthew Dharm

Post by Doug Maxey
Have run across a virtual USB host that needs (yes, I know, a strong
word :) to limit the maximum number of sectors transferred in a single
request to 32. In theory, the device should be fine with 32k, but
when it loses, it never seems to recover without a full reset.
Did some searching in the archives, but saw nothing.
What about something along the lines of adding UL_FL_MAX_SECTORS_32 to
follow the pattern used with MAX_SECTORS_64, thusly?
Based on linus 2.6.24-rc2.

I can't say I'm really happy about another flag, but I can't exactly object
too strongly. This is probably the best fix we're going to find.
Tho, I'm seriously tempted to make the choice MAX_SECTORS_64 and
MAX_SECTORS_1 -- if a device can't handle 64 sectors at a time, then let's
just limit it to 1 and call it a day. Otherwise we're going to wind up
with MAX_SECTORS_32, _16, _8, _4, and _2 someday.

1 won't work; max_sectors has to be at least the size of a memory
page. This is enforced by the block layer's request_queue routines.
But we certainly could have a MAX_SECTORS_MIN flag.

So, for most systems, the limit is 8?

Whatever our functional lower limit is, I think agree that a _MIN flag
would make sense.

I'm somewhat tempted to actually just convert the _64 flag to a _MIN flag,
and make the issue of finding an "optimal" value a userspace problem. I
think you can get to this parameter via sysfs, right?

Matt

[Alan Stern]

Post by Matthew Dharm

Post by Alan Stern
1 won't work; max_sectors has to be at least the size of a memory
page. This is enforced by the block layer's request_queue routines.
But we certainly could have a MAX_SECTORS_MIN flag.

So, for most systems, the limit is 8?

Yep. And I guess 16 for 64-bit systems.

Post by Matthew Dharm
Whatever our functional lower limit is, I think agree that a _MIN flag
would make sense.
I'm somewhat tempted to actually just convert the _64 flag to a _MIN flag,
and make the issue of finding an "optimal" value a userspace problem. I
think you can get to this parameter via sysfs, right?

In fact there are two separate sysfs interfaces for that parameter!
One in usb-storage and one in the generic block queue code. In theory
we could remove ours, but it's already an established userspace API so
we should hesitate before getting rid of it.

I'm not so sure about converting the _64 flag. It's reasonable to
think that a large number of devices will be limited to 64-KB
transfers, both because of the 16-bit boundary and because of legacy
ATA bus limitations. Going down to minimum-sized transfers will add a
lot of overhead and slow things down quite a bit. I'd prefer to avoid
it whenever possible.

(Having a MAX_SECTORS_64 flag rather than MAX_SECTORS_128 is kind of an
accident of history. There's maybe only one device which actually
needs to be limited to 32 KB as far as I know, as opposed to a fair
number that need to be limited to 64 KB. Still, it's done now...)

Alan Stern


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
linux-usb-***@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

[Matthew Dharm]

Post by Alan Stern

Post by Matthew Dharm
I'm somewhat tempted to actually just convert the _64 flag to a _MIN flag,
and make the issue of finding an "optimal" value a userspace problem. I
think you can get to this parameter via sysfs, right?

In fact there are two separate sysfs interfaces for that parameter!
One in usb-storage and one in the generic block queue code. In theory
we could remove ours, but it's already an established userspace API so
we should hesitate before getting rid of it.

We should at least be thinking about merging them. It's not like ours
manipulates anything usb-storage or SCSI specific; it just calls
blk_queue_max_sectors

Perhaps we could turn ours into a symlink to the one provided by the block
queue code?

Matt

[Doug Maxey]

Post by Matthew Dharm

Post by Alan Stern

Post by Matthew Dharm
I'm somewhat tempted to actually just convert the _64 flag to a _MIN flag,
and make the issue of finding an "optimal" value a userspace problem. I
think you can get to this parameter via sysfs, right?

In fact there are two separate sysfs interfaces for that parameter!
One in usb-storage and one in the generic block queue code. In theory
we could remove ours, but it's already an established userspace API so
we should hesitate before getting rid of it.

We should at least be thinking about merging them. It's not like ours
manipulates anything usb-storage or SCSI specific; it just calls
blk_queue_max_sectors
Perhaps we could turn ours into a symlink to the one provided by the block
queue code?

Any pointer to an example? Or do I finally need to really get in and
study the sysfs code? :)

++doug


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
linux-usb-***@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

[Alan Stern]

Post by Matthew Dharm

Post by Alan Stern

Post by Matthew Dharm
I'm somewhat tempted to actually just convert the _64 flag to a _MIN flag,
and make the issue of finding an "optimal" value a userspace problem. I
think you can get to this parameter via sysfs, right?

In fact there are two separate sysfs interfaces for that parameter!
One in usb-storage and one in the generic block queue code. In theory
we could remove ours, but it's already an established userspace API so
we should hesitate before getting rid of it.

We should at least be thinking about merging them. It's not like ours
manipulates anything usb-storage or SCSI specific; it just calls
blk_queue_max_sectors
Perhaps we could turn ours into a symlink to the one provided by the block
queue code?

I wish we could. Our file handles values in units of sectors (512
bytes) and the other sysfs entry handles values in units of KB. It's
even named "max_sectors_kb".

Alan Stern


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
linux-usb-***@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

[Matthew Dharm]

Post by Alan Stern

Post by Matthew Dharm

Post by Alan Stern

Post by Matthew Dharm
I'm somewhat tempted to actually just convert the _64 flag to a _MIN flag,
and make the issue of finding an "optimal" value a userspace problem. I
think you can get to this parameter via sysfs, right?

In fact there are two separate sysfs interfaces for that parameter!
One in usb-storage and one in the generic block queue code. In theory
we could remove ours, but it's already an established userspace API so
we should hesitate before getting rid of it.

We should at least be thinking about merging them. It's not like ours
manipulates anything usb-storage or SCSI specific; it just calls
blk_queue_max_sectors
Perhaps we could turn ours into a symlink to the one provided by the block
queue code?

I wish we could. Our file handles values in units of sectors (512
bytes) and the other sysfs entry handles values in units of KB. It's
even named "max_sectors_kb".

I'm guessing that it's worse than that... I'll bet that we handle a number
of sectors, regardless of sector size. So a sector might not be 512 bytes.

Matt

[Alan Stern]

Post by Matthew Dharm

Post by Alan Stern
I wish we could. Our file handles values in units of sectors (512
bytes) and the other sysfs entry handles values in units of KB. It's
even named "max_sectors_kb".

I'm guessing that it's worse than that... I'll bet that we handle a number
of sectors, regardless of sector size. So a sector might not be 512 bytes.

No, things aren't _that_ bad! The block layer documentation states the
value is in terms of "logical" sectors that are always 512 bytes, not
"hardware" sectors that are whatever the device wants them to be.

Alan Stern


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
linux-usb-***@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

[Doug Maxey]

Post by Alan Stern

Post by Matthew Dharm

Post by Alan Stern
I wish we could. Our file handles values in units of sectors (512
bytes) and the other sysfs entry handles values in units of KB. It's
even named "max_sectors_kb".

I'm guessing that it's worse than that... I'll bet that we handle a number
of sectors, regardless of sector size. So a sector might not be 512 bytes.

No, things aren't _that_ bad! The block layer documentation states the
value is in terms of "logical" sectors that are always 512 bytes, not
"hardware" sectors that are whatever the device wants them to be.

And on that note, and incorporating the requested changes, here is a
new patch.

Post by Alan Stern
From ff01889fac202ffb657a06e74ecd406c4229394d Mon Sep 17 00:00:00 2001

From: Doug Maxey <***@austin.ibm.com>
Date: Tue, 27 Nov 2007 18:42:42 -0600
Subject: [PATCH 1/1] usb-storage: limit devices that cannot handle 32k transfers

When a device cannot handle the smallest previously limited transfer
size (64 blocks) without stalling, limit the device to the amount of
packets that fit in a platform native page.

Cc: Mathew Dharm <mdharm-***@one-eyed-alien.net>
Cc: Alan Stern <***@rowland.harvard.edu>
Cc: Pete Zaitcev <***@redhat.com>
Signed-off-by: Doug Maxey <***@austin.ibm.com>
---
drivers/usb/storage/scsiglue.c | 11 +++++++++++
drivers/usb/storage/unusual_devs.h | 7 +++++++
include/linux/usb_usual.h | 5 ++++-
3 files changed, 22 insertions(+), 1 deletions(-)

diff --git a/drivers/usb/storage/scsiglue.c b/drivers/usb/storage/scsiglue.c
index 1ba19ea..c071bca 100644
--- a/drivers/usb/storage/scsiglue.c
+++ b/drivers/usb/storage/scsiglue.c
@@ -118,6 +118,17 @@ static int slave_configure(struct scsi_device *sdev)
sdev->request_queue->max_sectors > 64)
blk_queue_max_sectors(sdev->request_queue, 64);

+ /* And at least one more device needs an even smaller max.
+ * When testing the native PAGE_SIZE, clamp at 8k. No need
+ * allow a 64K or even 16M page in there.
+ */
+ if (us->flags & US_FL_MAX_SECTORS_MIN) {
+ int min = min(PAGE_SIZE, 8192) / 512;
+
+ if (sdev->request_queue->max_sectors > min)
+ blk_queue_max_sectors(sdev->request_queue, min);
+ }
+
/* We can't put these settings in slave_alloc() because that gets
* called before the device type is known. Consequently these
* settings can't be overridden via the scsi devinfo mechanism. */
diff --git a/drivers/usb/storage/unusual_devs.h b/drivers/usb/storage/unusual_devs.h
index 22ab238..f464b18 100644
--- a/drivers/usb/storage/unusual_devs.h
+++ b/drivers/usb/storage/unusual_devs.h
@@ -376,6 +376,13 @@ UNUSUAL_DEV( 0x04b0, 0x0417, 0x0100, 0x0100,
US_SC_DEVICE, US_PR_DEVICE, NULL,
US_FL_FIX_CAPACITY),

+/* Reported by Doug Maxey (***@austin.ibm.com) */
+UNUSUAL_DEV( 0x04b3, 0x4001, 0x0110, 0x0110,
+ "IBM",
+ "IBM RSA2",
+ US_SC_DEVICE, US_PR_CB, NULL,
+ US_FL_MAX_SECTORS_MIN),
+
/* BENQ DC5330
* Reported by Manuel Fombuena <***@ya.com> and
* Frank Copeland <***@thingy.apana.org.au> */
diff --git a/include/linux/usb_usual.h b/include/linux/usb_usual.h
index 1b792b9..5e182e5 100644
--- a/include/linux/usb_usual.h
+++ b/include/linux/usb_usual.h
@@ -48,7 +48,10 @@
US_FLAG(IGNORE_DEVICE, 0x00000800) \
/* Don't claim device */ \
US_FLAG(CAPACITY_HEURISTICS, 0x00001000) \
- /* sometimes sizes is too big */
+ /* sometimes sizes is too big */ \
+ US_FLAG(MAX_SECTORS_MIN,0x00001000) \
+ /* Sets max_sectors to arch min */
+

#define US_FLAG(name, value) US_FL_##name = value ,
enum { US_DO_ALL_FLAGS };
--
1.5.3.6




-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
linux-usb-***@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

[Pete Zaitcev]

Post by Doug Maxey
+++ b/include/linux/usb_usual.h
@@ -48,7 +48,10 @@
US_FLAG(IGNORE_DEVICE, 0x00000800) \
/* Don't claim device */ \
US_FLAG(CAPACITY_HEURISTICS, 0x00001000) \
- /* sometimes sizes is too big */
+ /* sometimes sizes is too big */ \
+ US_FLAG(MAX_SECTORS_MIN,0x00001000) \
+ /* Sets max_sectors to arch min */

Are you sure you didn't want 0x2000 here?

-- Pete

-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
linux-usb-***@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

[Doug Maxey]

Post by Pete Zaitcev

Post by Doug Maxey
+++ b/include/linux/usb_usual.h
@@ -48,7 +48,10 @@
US_FLAG(IGNORE_DEVICE, 0x00000800) \
/* Don't claim device */ \
US_FLAG(CAPACITY_HEURISTICS, 0x00001000) \
- /* sometimes sizes is too big */
+ /* sometimes sizes is too big */ \
+ US_FLAG(MAX_SECTORS_MIN,0x00001000) \
+ /* Sets max_sectors to arch min */

Are you sure you didn't want 0x2000 here?

Doesn't matter to me. Was shifting to the left in sequence, I thought.

If I did move it, want to resort the list?

++doug


-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
linux-usb-***@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

[Matthew Dharm]

Post by Doug Maxey

Post by Pete Zaitcev

Post by Doug Maxey
+++ b/include/linux/usb_usual.h
@@ -48,7 +48,10 @@
US_FLAG(IGNORE_DEVICE, 0x00000800) \
/* Don't claim device */ \
US_FLAG(CAPACITY_HEURISTICS, 0x00001000) \
- /* sometimes sizes is too big */
+ /* sometimes sizes is too big */ \
+ US_FLAG(MAX_SECTORS_MIN,0x00001000) \
+ /* Sets max_sectors to arch min */

Are you sure you didn't want 0x2000 here?

Doesn't matter to me. Was shifting to the left in sequence, I thought.

Shifting left *is* what you want. But you used the same value as
CAPACITY_HEURISTICS -- they must all be unique.

Matt

[Doug Maxey]

Post by Matthew Dharm

Post by Doug Maxey

Post by Pete Zaitcev

Post by Doug Maxey
+++ b/include/linux/usb_usual.h
@@ -48,7 +48,10 @@
US_FLAG(IGNORE_DEVICE, 0x00000800) \
/* Don't claim device */ \
US_FLAG(CAPACITY_HEURISTICS, 0x00001000) \
- /* sometimes sizes is too big */
+ /* sometimes sizes is too big */ \
+ US_FLAG(MAX_SECTORS_MIN,0x00001000) \
+ /* Sets max_sectors to arch min */

Are you sure you didn't want 0x2000 here?

Doesn't matter to me. Was shifting to the left in sequence, I thought.

Shifting left *is* what you want. But you used the same value as
CAPACITY_HEURISTICS -- they must all be unique.

buh? what? we can't have duplicate (or overloaded> flags? :->

++doug


-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
linux-usb-***@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

[Doug Maxey]

From cebb5133e9f63af086a8600f52dbe13060eb0007 Mon Sep 17 00:00:00 2001

From: Doug Maxey <***@austin.ibm.com>
Date: Tue, 27 Nov 2007 18:42:42 -0600
Subject: [PATCH 1/1] usb-storage: limit devices that cannot handle 32k transfers

When a device cannot handle the smallest previously limited transfer
size (64 blocks) without stalling, limit the device to the amount of
packets that fit in a platform native page.

This version does not duplicate the CAPACITY_HEURISTICS flag.

Cc: Mathew Dharm <mdharm-***@one-eyed-alien.net>
Cc: Alan Stern <***@rowland.harvard.edu>
Cc: Pete Zaitcev <***@redhat.com>
Signed-off-by: Doug Maxey <***@austin.ibm.com>
---
drivers/usb/storage/scsiglue.c | 11 +++++++++++
drivers/usb/storage/unusual_devs.h | 7 +++++++
include/linux/usb_usual.h | 5 ++++-
3 files changed, 22 insertions(+), 1 deletions(-)

diff --git a/drivers/usb/storage/scsiglue.c b/drivers/usb/storage/scsiglue.c
index 1ba19ea..c071bca 100644
--- a/drivers/usb/storage/scsiglue.c
+++ b/drivers/usb/storage/scsiglue.c
@@ -118,6 +118,17 @@ static int slave_configure(struct scsi_device *sdev)
sdev->request_queue->max_sectors > 64)
blk_queue_max_sectors(sdev->request_queue, 64);

+ /* And at least one more device needs an even smaller max.
+ * When testing the native PAGE_SIZE, clamp at 8k. No need
+ * allow a 64K or even 16M page in there.
+ */
+ if (us->flags & US_FL_MAX_SECTORS_MIN) {
+ int min = min(PAGE_SIZE, 8192) / 512;
+
+ if (sdev->request_queue->max_sectors > min)
+ blk_queue_max_sectors(sdev->request_queue, min);
+ }
+
/* We can't put these settings in slave_alloc() because that gets
* called before the device type is known. Consequently these
* settings can't be overridden via the scsi devinfo mechanism. */
diff --git a/drivers/usb/storage/unusual_devs.h b/drivers/usb/storage/unusual_devs.h
index 22ab238..f464b18 100644
--- a/drivers/usb/storage/unusual_devs.h
+++ b/drivers/usb/storage/unusual_devs.h
@@ -376,6 +376,13 @@ UNUSUAL_DEV( 0x04b0, 0x0417, 0x0100, 0x0100,
US_SC_DEVICE, US_PR_DEVICE, NULL,
US_FL_FIX_CAPACITY),

+/* Reported by Doug Maxey (***@austin.ibm.com) */
+UNUSUAL_DEV( 0x04b3, 0x4001, 0x0110, 0x0110,
+ "IBM",
+ "IBM RSA2",
+ US_SC_DEVICE, US_PR_CB, NULL,
+ US_FL_MAX_SECTORS_MIN),
+
/* BENQ DC5330
* Reported by Manuel Fombuena <***@ya.com> and
* Frank Copeland <***@thingy.apana.org.au> */
diff --git a/include/linux/usb_usual.h b/include/linux/usb_usual.h
index 1b792b9..a417b09 100644
--- a/include/linux/usb_usual.h
+++ b/include/linux/usb_usual.h
@@ -48,7 +48,10 @@
US_FLAG(IGNORE_DEVICE, 0x00000800) \
/* Don't claim device */ \
US_FLAG(CAPACITY_HEURISTICS, 0x00001000) \
- /* sometimes sizes is too big */
+ /* sometimes sizes is too big */ \
+ US_FLAG(MAX_SECTORS_MIN,0x00002000) \
+ /* Sets max_sectors to arch min */
+

#define US_FLAG(name, value) US_FL_##name = value ,
enum { US_DO_ALL_FLAGS };
--
1.5.3.6




-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
linux-usb-***@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

[Alan Stern]

Post by Doug Maxey
+ /* And at least one more device needs an even smaller max.
+ * When testing the native PAGE_SIZE, clamp at 8k. No need
+ * allow a 64K or even 16M page in there.
+ */

Why not combine the code for the two flags, as shown in the partial
patch below?

Also, trying to clamp at 8 KB is futile. Read the source code for
blk_queue_max_sectors() in drivers/block/ll_rw_blk.c and you'll see.

Alan Stern


Index: usb-2.6/drivers/usb/storage/scsiglue.c
===================================================================
--- usb-2.6.orig/drivers/usb/storage/scsiglue.c
+++ usb-2.6/drivers/usb/storage/scsiglue.c
@@ -113,10 +113,19 @@ static int slave_configure(struct scsi_d
/* Many devices have trouble transfering more than 32KB at a time,
* while others have trouble with more than 64K. At this time we
* are limiting both to 32K (64 sectores).
+ *
+ * Some other devices have trouble transferring even that much.
+ * We'll limit them to PAGE_CACHE_SIZE, which is the minimum.
*/
- if ((us->flags & US_FL_MAX_SECTORS_64) &&
- sdev->request_queue->max_sectors > 64)
- blk_queue_max_sectors(sdev->request_queue, 64);
+ if (us->flags & (US_FL_MAX_SECTORS_64 | US_FL_MAX_SECTORS_MIN)) {
+ unsigned int max_sectors = 64;
+
+ if (us->flags & US_FL_MAX_SECTORS_MIN)
+ max_sectors = PAGE_CACHE_SIZE >> 9;
+ if (sdev->request_queue->max_sectors > max_sectors)
+ blk_queue_max_sectors(sdev->request_queue,
+ max_sectors);
+ }

/* We can't put these settings in slave_alloc() because that gets
* called before the device type is known. Consequently these


-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
linux-usb-***@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

[Doug Maxey]

Post by Alan Stern

Post by Doug Maxey
+ /* And at least one more device needs an even smaller max.
+ * When testing the native PAGE_SIZE, clamp at 8k. No need
+ * allow a 64K or even 16M page in there.
+ */

Why not combine the code for the two flags, as shown in the partial
patch below?
Also, trying to clamp at 8 KB is futile.

Alright. I was thinking of the remote possibility that the platform
could use use something 64k or larger as the native page size, which
would defeat trying to limit the device. If there were any other
devices out there that required this, and the administrator tried to
stick one in a powerpc, for example, the code would not have the
desired result.

Post by Alan Stern
Read the source code for
blk_queue_max_sectors() in drivers/block/ll_rw_blk.c and you'll see.

will do.

Post by Alan Stern
Alan Stern
Index: usb-2.6/drivers/usb/storage/scsiglue.c
===================================================================
--- usb-2.6.orig/drivers/usb/storage/scsiglue.c
+++ usb-2.6/drivers/usb/storage/scsiglue.c
@@ -113,10 +113,19 @@ static int slave_configure(struct scsi_d
/* Many devices have trouble transfering more than 32KB at a time,
* while others have trouble with more than 64K. At this time we
* are limiting both to 32K (64 sectores).
+ *
+ * Some other devices have trouble transferring even that much.
+ * We'll limit them to PAGE_CACHE_SIZE, which is the minimum.
*/
- if ((us->flags & US_FL_MAX_SECTORS_64) &&
- sdev->request_queue->max_sectors > 64)
- blk_queue_max_sectors(sdev->request_queue, 64);
+ if (us->flags & (US_FL_MAX_SECTORS_64 | US_FL_MAX_SECTORS_MIN)) {
+ unsigned int max_sectors = 64;
+
+ if (us->flags & US_FL_MAX_SECTORS_MIN)
+ max_sectors = PAGE_CACHE_SIZE >> 9;
+ if (sdev->request_queue->max_sectors > max_sectors)
+ blk_queue_max_sectors(sdev->request_queue,
+ max_sectors);
+ }
/* We can't put these settings in slave_alloc() because that gets
* called before the device type is known. Consequently these

-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
linux-usb-***@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

[Doug Maxey]

Post by Doug Maxey

Post by Alan Stern

Post by Doug Maxey
+ /* And at least one more device needs an even smaller max.
+ * When testing the native PAGE_SIZE, clamp at 8k. No need
+ * allow a 64K or even 16M page in there.
+ */

Why not combine the code for the two flags, as shown in the partial
patch below?
Also, trying to clamp at 8 KB is futile.

Alright. I was thinking of the remote possibility that the platform
could use use something 64k or larger as the native page size, which
would defeat trying to limit the device. If there were any other
devices out there that required this, and the administrator tried to
stick one in a powerpc, for example, the code would not have the
desired result.

They lose. Time for someone to fix the device firmware, or just not
use on that class of platform.

Post by Doug Maxey

Post by Alan Stern
Read the source code for
blk_queue_max_sectors() in drivers/block/ll_rw_blk.c and you'll see.

will do.

Indeed, it does clamp the lower limit at PAGE_CACHE_SIZE regardless.
Is the below going upstream, and I just drop my chunk?

Or, do you want me to fold this in?

Post by Doug Maxey

Post by Alan Stern
Alan Stern
Index: usb-2.6/drivers/usb/storage/scsiglue.c
===================================================================
--- usb-2.6.orig/drivers/usb/storage/scsiglue.c
+++ usb-2.6/drivers/usb/storage/scsiglue.c
@@ -113,10 +113,19 @@ static int slave_configure(struct scsi_d
/* Many devices have trouble transfering more than 32KB at a time,
* while others have trouble with more than 64K. At this time we
* are limiting both to 32K (64 sectores).
+ *
+ * Some other devices have trouble transferring even that much.
+ * We'll limit them to PAGE_CACHE_SIZE, which is the minimum.
*/
- if ((us->flags & US_FL_MAX_SECTORS_64) &&
- sdev->request_queue->max_sectors > 64)
- blk_queue_max_sectors(sdev->request_queue, 64);
+ if (us->flags & (US_FL_MAX_SECTORS_64 | US_FL_MAX_SECTORS_MIN)) {
+ unsigned int max_sectors = 64;
+
+ if (us->flags & US_FL_MAX_SECTORS_MIN)
+ max_sectors = PAGE_CACHE_SIZE >> 9;
+ if (sdev->request_queue->max_sectors > max_sectors)
+ blk_queue_max_sectors(sdev->request_queue,
+ max_sectors);
+ }
/* We can't put these settings in slave_alloc() because that gets
* called before the device type is known. Consequently these

-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
linux-usb-***@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

[Alan Stern]

Post by Doug Maxey
Indeed, it does clamp the lower limit at PAGE_CACHE_SIZE regardless.
Is the below going upstream, and I just drop my chunk?
Or, do you want me to fold this in?

The part I wrote should be folded in to your patch.

Alan Stern


-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
linux-usb-***@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

[Doug Maxey]

This version folds in Alan's example.

++doug
---

From f644b337771374178d5585bcedf8153f5b45f2d6 Mon Sep 17 00:00:00 2001

From: Doug Maxey <***@austin.ibm.com>
Date: Tue, 27 Nov 2007 18:42:42 -0600
Subject: [PATCH 1/1] usb-storage: limit devices that cannot handle 32k transfers

When a device cannot handle the smallest previously limited transfer
size (64 blocks) without stalling, limit the device to the amount of
packets that fit in a platform native page.

The lowest possible limit is PAGE_CACHE_SIZE, so if the device is ever
used on a platform that has larger than 8K pages, you lose unless you
can convince the device firmware folks to fix the issue.

Cc: Mathew Dharm <mdharm-***@one-eyed-alien.net>
Cc: Alan Stern <***@rowland.harvard.edu>
Cc: Pete Zaitcev <***@redhat.com>
Signed-off-by: Doug Maxey <***@austin.ibm.com>
---
drivers/usb/storage/scsiglue.c | 12 +++++++++---
drivers/usb/storage/unusual_devs.h | 7 +++++++
include/linux/usb_usual.h | 5 ++++-
3 files changed, 20 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/storage/scsiglue.c b/drivers/usb/storage/scsiglue.c
index 1ba19ea..62e9e94 100644
--- a/drivers/usb/storage/scsiglue.c
+++ b/drivers/usb/storage/scsiglue.c
@@ -114,9 +114,15 @@ static int slave_configure(struct scsi_device *sdev)
* while others have trouble with more than 64K. At this time we
* are limiting both to 32K (64 sectores).
*/
- if ((us->flags & US_FL_MAX_SECTORS_64) &&
- sdev->request_queue->max_sectors > 64)
- blk_queue_max_sectors(sdev->request_queue, 64);
+ if (us->flags & (US_FL_MAX_SECTORS_64 | US_FL_MAX_SECTORS_MIN)) {
+ unsigned int max_sectors = 64;
+
+ if (us->flags & US_FL_MAX_SECTORS_MIN)
+ max_sectors = PAGE_CACHE_SIZE >> 9;
+ if (sdev->request_queue->max_sectors > max_sectors)
+ blk_queue_max_sectors(sdev->request_queue,
+ max_sectors);
+ }

/* We can't put these settings in slave_alloc() because that gets
* called before the device type is known. Consequently these
diff --git a/drivers/usb/storage/unusual_devs.h b/drivers/usb/storage/unusual_devs.h
index 22ab238..f464b18 100644
--- a/drivers/usb/storage/unusual_devs.h
+++ b/drivers/usb/storage/unusual_devs.h
@@ -376,6 +376,13 @@ UNUSUAL_DEV( 0x04b0, 0x0417, 0x0100, 0x0100,
US_SC_DEVICE, US_PR_DEVICE, NULL,
US_FL_FIX_CAPACITY),

+/* Reported by Doug Maxey (***@austin.ibm.com) */
+UNUSUAL_DEV( 0x04b3, 0x4001, 0x0110, 0x0110,
+ "IBM",
+ "IBM RSA2",
+ US_SC_DEVICE, US_PR_CB, NULL,
+ US_FL_MAX_SECTORS_MIN),
+
/* BENQ DC5330
* Reported by Manuel Fombuena <***@ya.com> and
* Frank Copeland <***@thingy.apana.org.au> */
diff --git a/include/linux/usb_usual.h b/include/linux/usb_usual.h
index 1b792b9..a417b09 100644
--- a/include/linux/usb_usual.h
+++ b/include/linux/usb_usual.h
@@ -48,7 +48,10 @@
US_FLAG(IGNORE_DEVICE, 0x00000800) \
/* Don't claim device */ \
US_FLAG(CAPACITY_HEURISTICS, 0x00001000) \
- /* sometimes sizes is too big */
+ /* sometimes sizes is too big */ \
+ US_FLAG(MAX_SECTORS_MIN,0x00002000) \
+ /* Sets max_sectors to arch min */
+

#define US_FLAG(name, value) US_FL_##name = value ,
enum { US_DO_ALL_FLAGS };
--
1.5.3.6




-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
linux-usb-***@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

[Alan Stern]

Post by Doug Maxey
This version folds in Alan's example.
++doug
---
From f644b337771374178d5585bcedf8153f5b45f2d6 Mon Sep 17 00:00:00 2001
Date: Tue, 27 Nov 2007 18:42:42 -0600
Subject: [PATCH 1/1] usb-storage: limit devices that cannot handle 32k transfers
When a device cannot handle the smallest previously limited transfer
size (64 blocks) without stalling, limit the device to the amount of
packets that fit in a platform native page.
The lowest possible limit is PAGE_CACHE_SIZE, so if the device is ever
used on a platform that has larger than 8K pages, you lose unless you
can convince the device firmware folks to fix the issue.

Signed-off-by: Alan Stern <***@rowland.harvard.edu>


-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
linux-usb-***@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

[Doug Maxey]

Post by Doug Maxey
This version folds in Alan's example.
++doug
---
From f644b337771374178d5585bcedf8153f5b45f2d6 Mon Sep 17 00:00:00 2001
Date: Tue, 27 Nov 2007 18:42:42 -0600
Subject: [PATCH 1/1] usb-storage: limit devices that cannot handle 32k transfers
When a device cannot handle the smallest previously limited transfer
size (64 blocks) without stalling, limit the device to the amount of
packets that fit in a platform native page.
The lowest possible limit is PAGE_CACHE_SIZE, so if the device is ever
used on a platform that has larger than 8K pages, you lose unless you
can convince the device firmware folks to fix the issue.

Is there any chance to consider this a bug fix for 2.6.24?

++doug




-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
linux-usb-***@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

[Alan Stern]

Post by Doug Maxey
Is there any chance to consider this a bug fix for 2.6.24?

When you send the patch to Greg, mention below the "---" line that you
would like to have it added to 2.6.24 because it fixes a problem with
existing devices.

Alan Stern


-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
linux-usb-***@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

[Doug Maxey]

From f644b337771374178d5585bcedf8153f5b45f2d6 Mon Sep 17 00:00:00 2001

From: Doug Maxey <***@austin.ibm.com>
Date: Tue, 27 Nov 2007 18:42:42 -0600
Subject: [PATCH 1/1] usb-storage: limit devices that cannot handle 32k transfers

When a device cannot handle the smallest previously limited transfer
size (64 blocks) without stalling, limit the device to the amount of
packets that fit in a platform native page.

The lowest possible limit is PAGE_CACHE_SIZE, so if the device is ever
used on a platform that has larger than 8K pages, you lose unless you
can convince the device firmware folks to fix the issue.

Cc: Mathew Dharm <mdharm-***@one-eyed-alien.net>
Cc: Alan Stern <***@rowland.harvard.edu>
Cc: Pete Zaitcev <***@redhat.com>
Signed-off-by: Doug Maxey <***@austin.ibm.com>
---
Greg,
please consider this for 2.6.24. It does fix a problem with
existing devices.

drivers/usb/storage/scsiglue.c | 12 +++++++++---
drivers/usb/storage/unusual_devs.h | 7 +++++++
include/linux/usb_usual.h | 5 ++++-
3 files changed, 20 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/storage/scsiglue.c b/drivers/usb/storage/scsiglue.c
index 1ba19ea..62e9e94 100644
--- a/drivers/usb/storage/scsiglue.c
+++ b/drivers/usb/storage/scsiglue.c
@@ -114,9 +114,15 @@ static int slave_configure(struct scsi_device *sdev)
* while others have trouble with more than 64K. At this time we
* are limiting both to 32K (64 sectores).
*/
- if ((us->flags & US_FL_MAX_SECTORS_64) &&
- sdev->request_queue->max_sectors > 64)
- blk_queue_max_sectors(sdev->request_queue, 64);
+ if (us->flags & (US_FL_MAX_SECTORS_64 | US_FL_MAX_SECTORS_MIN)) {
+ unsigned int max_sectors = 64;
+
+ if (us->flags & US_FL_MAX_SECTORS_MIN)
+ max_sectors = PAGE_CACHE_SIZE >> 9;
+ if (sdev->request_queue->max_sectors > max_sectors)
+ blk_queue_max_sectors(sdev->request_queue,
+ max_sectors);
+ }

/* We can't put these settings in slave_alloc() because that gets
* called before the device type is known. Consequently these
diff --git a/drivers/usb/storage/unusual_devs.h b/drivers/usb/storage/unusual_devs.h
index 22ab238..f464b18 100644
--- a/drivers/usb/storage/unusual_devs.h
+++ b/drivers/usb/storage/unusual_devs.h
@@ -376,6 +376,13 @@ UNUSUAL_DEV( 0x04b0, 0x0417, 0x0100, 0x0100,
US_SC_DEVICE, US_PR_DEVICE, NULL,
US_FL_FIX_CAPACITY),

+/* Reported by Doug Maxey (***@austin.ibm.com) */
+UNUSUAL_DEV( 0x04b3, 0x4001, 0x0110, 0x0110,
+ "IBM",
+ "IBM RSA2",
+ US_SC_DEVICE, US_PR_CB, NULL,
+ US_FL_MAX_SECTORS_MIN),
+
/* BENQ DC5330
* Reported by Manuel Fombuena <***@ya.com> and
* Frank Copeland <***@thingy.apana.org.au> */
diff --git a/include/linux/usb_usual.h b/include/linux/usb_usual.h
index 1b792b9..a417b09 100644
--- a/include/linux/usb_usual.h
+++ b/include/linux/usb_usual.h
@@ -48,7 +48,10 @@
US_FLAG(IGNORE_DEVICE, 0x00000800) \
/* Don't claim device */ \
US_FLAG(CAPACITY_HEURISTICS, 0x00001000) \
- /* sometimes sizes is too big */
+ /* sometimes sizes is too big */ \
+ US_FLAG(MAX_SECTORS_MIN,0x00002000) \
+ /* Sets max_sectors to arch min */
+

#define US_FLAG(name, value) US_FL_##name = value ,
enum { US_DO_ALL_FLAGS };
--
1.5.3.6




-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
linux-usb-***@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

[Greg KH]

Post by Doug Maxey

From f644b337771374178d5585bcedf8153f5b45f2d6 Mon Sep 17 00:00:00 2001

Date: Tue, 27 Nov 2007 18:42:42 -0600
Subject: [PATCH 1/1] usb-storage: limit devices that cannot handle 32k transfers
When a device cannot handle the smallest previously limited transfer
size (64 blocks) without stalling, limit the device to the amount of
packets that fit in a platform native page.
The lowest possible limit is PAGE_CACHE_SIZE, so if the device is ever
used on a platform that has larger than 8K pages, you lose unless you
can convince the device firmware folks to fix the issue.
---
Greg,
please consider this for 2.6.24. It does fix a problem with
existing devices.

Which "devices"?

And do these devices work properly on older versions of Linux, and this
is a regression fix, or have they just never worked properly?

thanks,

greg k-h

-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
linux-usb-***@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

[Doug Maxey]

Post by Greg KH
Which "devices"?

the RSA2 for xseries

Post by Greg KH
And do these devices work properly on older versions of Linux,

no.

Post by Greg KH
and this
is a regression fix, or have they just never worked properly?

never worked properly. folks had to resort to using local storage.

++doug



-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
linux-usb-***@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

[Doug Maxey]

From f644b337771374178d5585bcedf8153f5b45f2d6 Mon Sep 17 00:00:00 2001

From: Doug Maxey <***@austin.ibm.com>
Date: Tue, 27 Nov 2007 18:42:42 -0600
Subject: [PATCH 1/1] usb-storage: limit devices that cannot handle 32k transfers

When a device cannot handle the smallest previously limited transfer
size (64 blocks) without stalling, limit the device to the amount of
packets that fit in a platform native page.

The lowest possible limit is PAGE_CACHE_SIZE, so if the device is ever
used on a platform that has larger than 8K pages, you lose unless you
can convince the device firmware folks to fix the issue.

Cc: Mathew Dharm <mdharm-***@one-eyed-alien.net>
Cc: Alan Stern <***@rowland.harvard.edu>
Cc: Pete Zaitcev <***@redhat.com>
Signed-off-by: Doug Maxey <***@austin.ibm.com>
---
Greg,
please consider this for 2.6.24.
It does fix a long existing problem with the mentioned device.

drivers/usb/storage/scsiglue.c | 12 +++++++++---
drivers/usb/storage/unusual_devs.h | 7 +++++++
include/linux/usb_usual.h | 5 ++++-
3 files changed, 20 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/storage/scsiglue.c b/drivers/usb/storage/scsiglue.c
index 1ba19ea..62e9e94 100644
--- a/drivers/usb/storage/scsiglue.c
+++ b/drivers/usb/storage/scsiglue.c
@@ -114,9 +114,15 @@ static int slave_configure(struct scsi_device *sdev)
* while others have trouble with more than 64K. At this time we
* are limiting both to 32K (64 sectores).
*/
- if ((us->flags & US_FL_MAX_SECTORS_64) &&
- sdev->request_queue->max_sectors > 64)
- blk_queue_max_sectors(sdev->request_queue, 64);
+ if (us->flags & (US_FL_MAX_SECTORS_64 | US_FL_MAX_SECTORS_MIN)) {
+ unsigned int max_sectors = 64;
+
+ if (us->flags & US_FL_MAX_SECTORS_MIN)
+ max_sectors = PAGE_CACHE_SIZE >> 9;
+ if (sdev->request_queue->max_sectors > max_sectors)
+ blk_queue_max_sectors(sdev->request_queue,
+ max_sectors);
+ }

/* We can't put these settings in slave_alloc() because that gets
* called before the device type is known. Consequently these
diff --git a/drivers/usb/storage/unusual_devs.h b/drivers/usb/storage/unusual_devs.h
index 22ab238..f464b18 100644
--- a/drivers/usb/storage/unusual_devs.h
+++ b/drivers/usb/storage/unusual_devs.h
@@ -376,6 +376,13 @@ UNUSUAL_DEV( 0x04b0, 0x0417, 0x0100, 0x0100,
US_SC_DEVICE, US_PR_DEVICE, NULL,
US_FL_FIX_CAPACITY),

+/* Reported by Doug Maxey (***@austin.ibm.com) */
+UNUSUAL_DEV( 0x04b3, 0x4001, 0x0110, 0x0110,
+ "IBM",
+ "IBM RSA2",
+ US_SC_DEVICE, US_PR_CB, NULL,
+ US_FL_MAX_SECTORS_MIN),
+
/* BENQ DC5330
* Reported by Manuel Fombuena <***@ya.com> and
* Frank Copeland <***@thingy.apana.org.au> */
diff --git a/include/linux/usb_usual.h b/include/linux/usb_usual.h
index 1b792b9..a417b09 100644
--- a/include/linux/usb_usual.h
+++ b/include/linux/usb_usual.h
@@ -48,7 +48,10 @@
US_FLAG(IGNORE_DEVICE, 0x00000800) \
/* Don't claim device */ \
US_FLAG(CAPACITY_HEURISTICS, 0x00001000) \
- /* sometimes sizes is too big */
+ /* sometimes sizes is too big */ \
+ US_FLAG(MAX_SECTORS_MIN,0x00002000) \
+ /* Sets max_sectors to arch min */
+

#define US_FLAG(name, value) US_FL_##name = value ,
enum { US_DO_ALL_FLAGS };
--
1.5.3.6








-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
linux-usb-***@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

[Phil Dibowitz]

Post by Doug Maxey

From f644b337771374178d5585bcedf8153f5b45f2d6 Mon Sep 17 00:00:00 2001

Date: Tue, 27 Nov 2007 18:42:42 -0600
Subject: [PATCH 1/1] usb-storage: limit devices that cannot handle 32k transfers
When a device cannot handle the smallest previously limited transfer
size (64 blocks) without stalling, limit the device to the amount of
packets that fit in a platform native page.
The lowest possible limit is PAGE_CACHE_SIZE, so if the device is ever
used on a platform that has larger than 8K pages, you lose unless you
can convince the device firmware folks to fix the issue.

Short of the weird spacing issues in usb_usual.h, it looks fine to me, and
I'll sign off on it since I wrote the original US_FL_MAX_SECTORS_64 patch if
I recall correctly.

Signed-off-by: Phil Dibowitz <***@ipom.com>
--
Phil Dibowitz ***@ipom.com
Open Source software and tech docs Insanity Palace of Metallica
http://www.phildev.net/ http://www.ipom.com/

"Never write it in C if you can do it in 'awk';
Never do it in 'awk' if 'sed' can handle it;
Never use 'sed' when 'tr' can do the job;
Never invoke 'tr' when 'cat' is sufficient;
Avoid using 'cat' whenever possible" -- Taylor's Laws of Programming