On Sat, Sep 28, 2013 at 8:28 PM, Markus Rechberger <mrechberger@xxxxxxxxx> wrote: > On Sat, Sep 28, 2013 at 7:43 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: >> On Sat, 28 Sep 2013, Markus Rechberger wrote: >> >>> >> My next step would be to eliminate the kmallocs/kfrees for the single >>> >> urbs (just by allocating the urbs with the same mechanism and passing >>> >> the returned pointer to SUBMIT_URB). >>> > >>> > The time spent allocating and freeing URBs is probably pretty small. >>> > >>> >>> pre-allocating should at least solve those issues: >>> http://support.sundtek.com/index.php/topic,1097.msg7780.html#msg7780 >> >> As far as I can tell, that bug report isn't related to URB allocation. >> It looks like the failure occurred when allocating memory for the >> transfer buffer, not when allocating memory for the URB. > > That's what I mean, URB pre-allocation would just be for having it > complete (the same is available on MacOSX), if it's not wanted I don't > mind either. > At the time the bugreport was made in our forum we were allocating > around 15k buffers, it happened during runtime so it worked for some > time and then stopped with those allocation problems. > > I hope the SG transfer does not introduce any latency issues we have > some usb chipsets which are very picky about latency issues on > embedded systems. > We got it work by tuning the transfer size, if the timings are not met > the device will just disable the transfer. > Unfortunately it will take a second to detect that by the driver and > re-enabling the transfer which means that it will corrupt the data. > I do not have a good feeling about pushing SG transfers into the > kernel by modifying the legacy mode without having any experience with > it. While the idea behind SG transfers is definitely ok but who knows > how it will perform with such devices. > I put together a few reports: http://support.sundtek.com/index.php/topic,350.0.html http://support.sundtek.com/index.php/topic,1097.msg7780.html#msg7780 http://support.sundtek.com/index.php/topic,411.msg2153.html#msg2153 http://support.sundtek.com/index.php/topic,531.msg2956.html#msg2956 http://support.sundtek.com/index.php/topic,364.msg1829.html#msg1829 they are all about page allocation failure when submitting the URB packet (I agree that it's probably mostly about the 15-16k allocation problem here). They only came up a few times between 2010 - (late) 2012 (we were also able to reproduce this on our Sheevaplug occasionally since we do stronger testing with it I guess). Not sure if that problem still happens, at least it didn't pop up in our forum this year. Markus >>> but now when looking closer SG support can disable the support for >>> shared memory support for bulk transfers. >> >> I don't know what you're talking about. What has shared memory got to >> do with SG or anything else we are discussing? >> > > sorry I probably picked the wrong words for that. > >>> It should be possible to turn off SG Support in favor of >>> pre-allocating the buffers (or preallocate the buffers for SG). >> >> Only if the buffer can be allocated as a single contiguous region of >> memory, in which case SG wouldn't be needed anyway. >> >>> This problem happened several times on Sheevaplug ARM systems from Marvell. >> >> I don't see what difference the platform or architecture would make. >> >> Alan Stern >> -- 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
