Am Dienstag, 3. Januar 2006 17:08 schrieb Sam Bishop:
> Oliver Neukum wrote:
> > Does this fix your trouble?
> >
> > Regards
> > Oliver
> >
> > --- linux-2.6.15-rc5-vanilla/drivers/usb/usb-skeleton.c 2005-12-04
> > 06:10:42.0 +0100
> > +++ linux-2.6.15-rc5/drivers/usb/u
Oliver Neukum wrote:
Does this fix your trouble?
Regards
Oliver
--- linux-2.6.15-rc5-vanilla/drivers/usb/usb-skeleton.c 2005-12-04
06:10:42.0 +0100
+++ linux-2.6.15-rc5/drivers/usb/usb-skeleton.c 2005-12-17 09:41:39.0
+0100
@@ -39,10 +39,15 @@
/* Get a
Am Donnerstag, 15. Dezember 2005 22:13 schrieb Sam Bishop:
> Oliver Neukum wrote:
> > On second thought, the skeleton driver doesn't even limit the buffersize
> > to something sane. Triggering 128K allocations in unlimited numbers is
> > not nice at all.
> >
> > Regards
> > Oliver
On Thu, Dec 15, 2005 at 08:58:39AM -0700, Sam Bishop wrote:
> Hello,
>
> I maintain a 2.4 USB driver based off an old version of usb-skeleton.c.
> (It's for an in-house tester used where I work, and the choice of kernel
> version is out of my hands.) I've just taken a look at the latest (2.6)
Oliver Neukum wrote:
On second thought, the skeleton driver doesn't even limit the buffersize
to something sane. Triggering 128K allocations in unlimited numbers is
not nice at all.
Regards
Oliver
That's right; I forgot that I'd seen that too.
I suppose this is the di
Am Donnerstag, 15. Dezember 2005 16:58 schrieb Sam Bishop:
> It's the writes I'm wondering about. It appears that the code allocates
> a new URB and buffer for each write. Once the write is completed, the
> associated URB and buffer are freed. But one of the ways I benchmark
> our download sp
Am Donnerstag, 15. Dezember 2005 16:58 schrieb Sam Bishop:
> It's the writes I'm wondering about. It appears that the code allocates
> a new URB and buffer for each write. Once the write is completed, the
> associated URB and buffer are freed. But one of the ways I benchmark
> our download sp
