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. I'm certainly angry, Markus > Best of luck, > > greg k-h > -- 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
