> +static int max_sectors_init (struct us_data *us);
> +
> /* The entries in this table, except for final ones here
> * (USB_MASS_STORAGE_CLASS and the empty entry), correspond,
> * line for line with the entries of us_unsuaul_dev_list[].
> @@ -1071,6 +1073,12 @@ static void * storage_probe(struct usb_d
> return ss;
> }
>
> +static int max_sectors_init(struct us_data *us)
> +{
> + us->htmplt.max_sectors = 64;
> + return 0;
> +}
> +
> /* Handle a disconnect event from the USB core */
> static void storage_disconnect(struct usb_device *dev, void *ptr)
> {
>
> Please note that this is a patch for kernel 2.4. The bug submitter
> (that is, IBM) claims that our 2.6 based product (RHEL 4) works.
> I have no idea why, and I think it's a case of a miraclous
> coincidence.
>
> We keep hitting these, so I'm wondering if it would be wise
> to create a unified flag with only 32KB limit. I understand that
> this would limit the performance more than the 64KB limit which
> Benjamin used. But perhaps it's something acceptable... Something
> to think about.
>
I have tested my device with max_sectors set to 64 and without IGNORE_RESIDUE,
but it doesn't work. Thus it would profit by the 64 KB limit instead of a
32 KB limit. But it doesn't matter for me. What would be a solution to
allow both values ? Initializers ? Or could this be a problem
for some devices which already needs a special initializer. If yes, it
could still be changed there. But I think it would be less clean.
-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
