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:	Thu, 13 Oct 2011 20:27:01 +0200
From:	Markus Rechberger <mrechberger@...il.com>
To:	Chris Friesen <chris.friesen@...band.com>
Cc:	Alan Stern <stern@...land.harvard.edu>, 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 6:25 PM, Chris Friesen
<chris.friesen@...band.com> wrote:
> On 10/13/2011 10:12 AM, Markus Rechberger wrote:
>>
>> On Thu, Oct 13, 2011 at 6:01 PM, Chris Friesen
>
>> Why on earth should things be done differently than with all other
>> operating systems?
>
> Linux does a lot of things differently than other operating systems.  In
> many cases it's because the other OS's do things wrong.  One could just as
> easily turn the question around and ask why on earth would your hardware be
> different than all the other USB hardware?
>
>>> If there is a bug in the kernel, why would we want a bandaid patch that
>>> just
>>> happens to make it work rather than a true fix?
>>
>> In silicon? Are you going to tape out another one for it?
>
> If there's a bug in the kernel, the true fix would be in the kernel.
>
>> And about the particular device the boundaries are just around 7000
>> bytes off and people are screaming about that? Sorry this is just like
>> in kindergarden here.
>
> Actually I think that you're the one throwing a tantrum and yelling that it
> needs to be done your way or else.  We generally don't change global
> constants because one hardware device doesn't work.
>

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.


Why do you think is this documented in the hardware specs of one of our devices?
The chip which has those problems unfortunately doesn't have such registers.

AGAIN:
According to the hardware spec of on of our product
Available Bulk Transfer Size are:
- 188 * n bytes, where n = 1 ~ 256.


Markus

> Chris
>
> --
> Chris Friesen
> Software Developer
> GENBAND
> chris.friesen@...band.com
> www.genband.com
>
--
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