Re: [Patch] Increase USBFS Bulk Transfer size

[Markus Rechberger]

On Wed, Oct 12, 2011 at 11:48 PM, Markus Rechberger
<mrechberger@xxxxxxxxx> wrote:
> On Wed, Oct 12, 2011 at 10:33 PM, Greg KH <gregkh@xxxxxxx> wrote:
>> On Wed, Oct 12, 2011 at 06:59:01PM +0200, Markus Rechberger wrote:
>>> On Wed, Oct 12, 2011 at 4:17 PM, Greg KH <gregkh@xxxxxxx> wrote:
>>> > On Wed, Oct 12, 2011 at 02:36:59PM +0200, Markus Rechberger wrote:
>>> >> We have 2 products which can perform better with increased Bulk transfers
>>> >
>>> > I don't believe you :)
>>> >
>>> > As stated before, this patch is not acceptable.  Please work to figure
>>> > out the real reason for your device problems here, this is not the
>>> > correct solution at all.
>>> >
>>>
>>> OK no device support for linux then. Windows and MacOSX are fine.
>>
>> That is your choice, not ours, as you are the one writing the closed
>> source code.  Without usbmon dumps, showing that the problem really is
>> in the kernel code, we can't do anything for you here.
>>
>
>
> here take your usbmon logs:
> http://sundtek.de/support/working.log
> http://sundtek.de/support/notworking.log (this is with your proposed
> split up of 22k).
>
> Isochronous already supports up to 190kb buffers which cause no
> trouble anywhere.
> Bulk is castrated to 15kb buffers and 50kb should be such a big issue
> while applications
> which do not request it are not affected at all.
>
> I'm very angry that you do not really focus on what I write and just
> try to write stories about
> bogus things like my patch might break other applications while I
> pointed out that this is not
> possible with legacy applications which use this interface. It is not
> even possible to read the
> maximum buffer value from the kernelspace.
>
> Your bogus message about 1Gig ram you can put it elsewhere, I checked
> multiple windows drivers
> in the past the buffer size varies between small and something around
> 50k usually.
> I would fully like to avoid to patch this kernel to get those things
> work because I don't want to
> deal with people who just write around the actual issues.
>
> Alsi the fact that bigger buffers are already being used plus the HW
> specifications of our main device also points out to a certain
> buffersize near 50k. But of course you are the smart knowitall without
> the need of explanation why
> those things can be affected by HW and some HW chips have options to
> influence that buffer size.

And for those who are curious about the logfiles:
Not working one as proposed by Alan that the full buffer size should
be split into 2 requests:

ffff8800b38d9f00 1231540351 S Bi:2:013:1 -115 12288 <
ffff8800b38d96c0 1231540404 S Bi:2:013:1 -115 11776 <
ffff8800b38d9cc0 1231540440 S Bi:2:013:1 -115 12288 <
ffff880002ede600 1231540496 S Bi:2:013:1 -115 11776 <
ffff8800b38d9f00 1231545491 C Bi:2:013:1 0 12288 = 7a1a0840 1ca8353c
004b80ec 4de08401 2f0227f8 34005e7e 80181dfd 1a8f700a
ffff88007d51fb40 1231545875 S Bi:2:013:1 -115 12288 <
ffff8800b38d96c0 1231551861 C Bi:2:013:1 0 11776 = 5244e386 a7800000
010642ea 35bfbba5 373e738b cc035a73 c328a1ff 4da728ce
ffff880002ede0c0 1231556173 S Bi:2:013:1 -115 11776 <
ffff8800b38d9cc0 1231558618 C Bi:2:013:1 0 12288 = db91aae9 2d2532f3
2e37448a fb36c213 55dda2ad 243122b2 261edb06 875848ac


12288 = 7a1a0840 every Line with 12288 should start with 47 (MPEG-TS Sync byte)

The working one which allocate 7000 bytes more (oh really big memory
pressure now!)  than this castrated USBFS interface allows.

ffff88003ac37240 992178919 S Bi:2:013:1 -115 24064 <
ffff88003ac37000 992178953 S Bi:2:013:1 -115 24064 <
ffff88003ac37c00 992178980 S Bi:2:013:1 -115 24064 <
ffff88003ac37e40 992179003 S Bi:2:013:1 -115 24064 <
ffff88003ac37240 992190198 C Bi:2:013:1 0 24064 = 471fff10 00000000
00000000 00000000 00000000 00000000 00000000 00000000
ffff88000601f480 992194368 S Bi:2:013:1 -115 24064 <
ffff88003ac37000 992203209 C Bi:2:013:1 0 24064 = 4701b114 43867ee6
40790660 e898681c 9b1c7dca 08980d43 73181369 9be1bc67
ffff880067e38a80 992204642 S Bi:2:013:1 -115 24064 <
ffff88003ac37c00 992216318 C Bi:2:013:1 0 24064 = 4740001c 0000b01d
0305d500 000000e0 104015e1 504016e1 60401be1 b04022e2
ffff880067e383c0 992219978 S Bi:2:013:1 -115 24064 <
ffff88003ac37e40 992229340 C Bi:2:013:1 0 24064 = 471fff10 00000000
00000000 00000000 00000000 00000000 00000000 00000000

everything starts nicely with 0x47

And now everyone again is clueless how this can happen.. surprise surprise..

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