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]
Message-ID: <CA+O4pC+AnDjZ3x2BRA83b6Wf7rWo0g2Xa7+WfPtRJr9aJCZvuw@mail.gmail.com>
Date:	Thu, 13 Oct 2011 22:17:28 +0200
From:	Markus Rechberger <mrechberger@...il.com>
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	Chris Friesen <chris.friesen@...band.com>,
	Greg KH <gregkh@...e.de>, USB list <linux-usb@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [Patch] Increase USBFS Bulk Transfer size

On Thu, Oct 13, 2011 at 10:07 PM, Alan Stern <stern@...land.harvard.edu> wrote:
> On Thu, 13 Oct 2011, Markus Rechberger wrote:
>
>> fair enough I have 2 devices which don't work properly with bulk.
>> Device A works by adjusting a hardware register
>> Device B is documented in this thread.
>>
>> Device A causes corruptions when the hardwareregister is set to a
>> buffersize > 16k.
>> There is certainly something on the physical usb layer which is unknown to the
>> (software) USB experts here.
>> The logfiles in the previous email shows up enough and is clear enough.
>
> When you ran the test using the 12288/11776 sizes, did you change the
> hardware register buffersize value?

sorry for confusing you here, this device does not have such a register.

Device A has the hardware register, the buffer is currently set to
~16kb for it and it is okay, it does not
require the patch. By increasing the hw register to >16kb the transfer
is also damaged.

Device B unfortunately not and only accepts 24064 bytes, before
getting that constant I tried
several other smaller buffer sizes and it did not succeed (result is
just as indicated by the video and logfiles in the earlier
post). CPU usage is also okay 0.9% for the entire streaming application.

Markus

> Or did you leave it set to the same 24064 as in the other test?
>
> Alan Stern
>
>
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ