On Sun, Feb 09, 2003 at 01:24:55PM -0500, John Homppi wrote:
>
> An aside for Jeff:
> Please indicate whether the following analysis matches your research
> regarding the Evolution Robots platform.
>
Your analysis follows mine exactly.
> It is important to differentiate the endpoints
On Mon, 10 Feb 2003, Duncan Sands wrote:
> Yes, one advantage of a sync unlink is that you get an error code in case
> of failure which you may not get with an async unlink (for example because
> the urb never completes).
I think you've got that backward. If the urb never completes then the
syn
On Monday 10 February 2003 16:05, Alan Stern wrote:
> On Mon, 10 Feb 2003, Duncan Sands wrote:
> > > Depending on the usage model the driver follows, this might not be
> > > true. For instance, one commonly recommended theme is for the driver to
> > > increment its module-use-count each time it sub
Hi Alan, here are my immediate thoughts, which means I didn't check
whether what I say is true.
> To satisfy my curiousity, can you think of _any_ situation at all in which
> you would be better off doing a synchronous unlink instead of an async
> one, knowing that the synchronous call might retur
Alan Stern wrote:
On Sun, 9 Feb 2003, Duncan Sands wrote:
In that other driver structure, synchronizing on urb completions
after an (async) unlink failure would either (a) have succeeded,
because the "failure" was like the EBUSY case, "warp crystals
would explode if we unlinked any faster", or (
--- Rpik <[EMAIL PROTECTED]> wrote:
> Thank you ... I have one more question ..
> I made file this way mknod /dev/usb/file c 180 90
> I loaded driver into kernel space this way insmod
> file.o - this is my
> driver with major 180 and minor 90
> After that I plug into USB my device which was
> Not necessarily, it depends on the structure of the driver. Increasing
> the use count in this way would prevent unloading while any urbs are in
> use, thus making it unnecessary to cancel anything in disconnect().
> (Unfortunately, that doesn't work out quite so nicely on SMP systems.)
No, th
On Sun, 9 Feb 2003, Duncan Sands wrote:
> > In that other driver structure, synchronizing on urb completions
> > after an (async) unlink failure would either (a) have succeeded,
> > because the "failure" was like the EBUSY case, "warp crystals
> > would explode if we unlinked any faster", or (b) f
On Mon, 10 Feb 2003, Duncan Sands wrote:
> > Depending on the usage model the driver follows, this might not be
> > true. For instance, one commonly recommended theme is for the driver to
> > increment its module-use-count each time it submits an urb and
> > decrement the count in the completion r
Hi.
I have problems with my Debian testing laptop running a 2.4.20 kernel
when trying to synchronize my T625C with jpilot.
It used to work with the previous 2.4.19 kernel, so I consider this to
be some kind of regression.
Now, I cannot make it work, and I get page errors, which soon end up
in k
> Depending on the usage model the driver follows, this might not be
> true. For instance, one commonly recommended theme is for the driver to
> increment its module-use-count each time it submits an urb and
> decrement the count in the completion routine. When this approach is
> used, the kernel
11 matches
Mail list logo
