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-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
