On Wed, 27 Oct 2004, Geoff Oakham wrote:
> if I claim the interface with usb_driver_claim_interface, will usbfs
> respect it? There are only a handful of userspace drivers for this
> device out there.. and I'm pretty sure they're not active during the
> test.
Like Oliver said, you don't need a d
Am Donnerstag, 28. Oktober 2004 00:45 schrieb Geoff Oakham:
> On Thu, Oct 28, 2004 at 12:18:16AM +0200, Oliver Neukum wrote:
> > > if I claim the interface with usb_driver_claim_interface, will usbfs
> > > respect it? ?There are only a handful of userspace drivers for this
> > > device out there..
On Thu, Oct 28, 2004 at 12:18:16AM +0200, Oliver Neukum wrote:
> > if I claim the interface with usb_driver_claim_interface, will usbfs
> > respect it? ?There are only a handful of userspace drivers for this
> > device out there.. and I'm pretty sure they're not active during the
> > test.
>
> Con
Am Mittwoch, 27. Oktober 2004 23:29 schrieb Geoff Oakham:
> if I claim the interface with usb_driver_claim_interface, will usbfs
> respect it? There are only a handful of userspace drivers for this
> device out there.. and I'm pretty sure they're not active during the
> test.
Concerning your cla
On Wed, Oct 27, 2004 at 04:59:17PM -0400, Alan Stern wrote:
> Ah, but other programs may be accessing your device through usbfs without
> your knowledge, without using your driver, and without being stopped by
> your semaphore! For example, any time you do "cat /proc/bus/usb/devices"
> the cat
On Wed, 27 Oct 2004, Geoff Oakham wrote:
> > Have you eliminated the possibility of other programs running in the
> > background also trying to communicate with your device (some Gnome/hotplug
> > programs do that)?
>
> Yes: I have a single semaphore guarding my data structure and access to
> the
On Wed, Oct 27, 2004 at 03:49:43PM -0400, Alan Stern wrote:
> > Since the linux-usb implementation is 100% bug-free, my code is the
> > bug's likely home. Should I be holding any locks when I call
> > usb_control_msg() or usb_bulk_msg()?
>
> You certainly shouldn't hold any spinlocks, since those
On Tue, 26 Oct 2004, Geoff Oakham wrote:
> Hey Alan,
>
> Unfortunately I haven't had any luck fixing this timing issue, so I've
> returned to seek wisdom and guidance. I've tried:
>
> -capping the average transfer speed in my driver
> -looking for similar behaviour in the Windows dr
Hey Alan,
Unfortunately I haven't had any luck fixing this timing issue, so I've
returned to seek wisdom and guidance. I've tried:
-capping the average transfer speed in my driver
-looking for similar behaviour in the Windows driver
Everything I've observed* suggests (to me) a l
On Tue, 5 Oct 2004, Geoff Oakham wrote:
> > Could it be that the timing of your commands isn't suitable for the
> > device? If it gets another "send next data block" command too soon or too
> > late after the last one, it may not be ready so it replies instead with a
> > STALL. And maybe sometim
On Tue, Oct 05, 2004 at 03:46:09PM -0400, Alan Stern wrote:
> > > > 90% of the time, I can
> > > > work around by re-issuing the request (once). But the other 10% of the
> > > > time, *both* requests succeed--even the original one that returned
> > > > -EPIPE.
> > >
> > > How do you know the req
On Tue, 5 Oct 2004, Geoff Oakham wrote:
> > > It's not an endpoint stall (clear_halt() fails).
> >
> > What do you mean by that? I don't think there's any way to get -EPIPE
> > other than by receiving a STALL token. And what do you mean, clear_halt()
> > fails? In what way does it fail? (No
On Tue, Oct 05, 2004 at 11:16:06AM -0400, Alan Stern wrote:
> > One of my control messages is returning 'EPIPE' when my system is under
> > heavy load. I'm stumped; does anyone have any suggestions?
>
> You're working on a kernel driver for this device, right? What does the
> device do?
The dr
On Mon, 4 Oct 2004, Geoff Oakham wrote:
> Hi there,
>
> One of my control messages is returning 'EPIPE' when my system is under
> heavy load. I'm stumped; does anyone have any suggestions?
You're working on a kernel driver for this device, right? What does the
device do?
> It's not an endpoi
14 matches
Mail list logo
