linux-kernel - Re: [Patch] Increase USBFS Bulk Transfer size

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 14 Oct 2011 05:42:44 +0200
From:	Markus Rechberger <mrechberger@...il.com>
To:	James Courtier-Dutton <james.dutton@...il.com>
Cc:	USB list <linux-usb@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>, Greg KH <gregkh@...e.de>,
	Alan Stern <stern@...land.harvard.edu>
Subject: Re: [Patch] Increase USBFS Bulk Transfer size

On Fri, Oct 14, 2011 at 4:47 AM, Markus Rechberger
<mrechberger@...il.com> wrote:
> On Fri, Oct 14, 2011 at 12:19 AM, James Courtier-Dutton
> <james.dutton@...il.com> wrote:
>> Why don't you try a bulk size of 12032 instead of 24064 and not try 12288 as
>> you appear to be doing in the logs. Post the logs for that.
>
> I tried that earlier already of course it fails. If I could pick a
> smaller transfer size I would be happy since
> the device would work with all 2.6.x kernels out of the box and I
> wouldn't have to waste my time with it.
> Unfortunately it requires the 24064 bytes.
> The more flexible device A which is mentioned here confirms that there
> can be some impact on the
> bulk transfer size.
> However to learn about this it's needed to look at the bottom line of
> USB on the physical layer.
>
> And I disagree with Alan Cox it's not about being a crappy device or
> not, it's more like about something
> that is not well understood here. Most people are familiar with
> Software only here and not with the physical
> USB bottom Layer, otherwise the fact that the devices can have an
> impact on this wouldn't be such a surprise.
>

however to not say that I'm unwilling to do that and that is the
reason for not accepting this patch
http://www.sundtek.de/support/notworking2.log

even if the value is exposed to sysfs, it still requires the static
value in the kernel. The current value
used in the patch is based on what is in the HW specs of device A
which has the flexible bulk transfer setting.
The inflexible device which uses 24064 bytes works with all other
Operating systems by using that value
and gives exactly the same results with other transfer sizes than that.

BR,
Markus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/