> Specificly, if you have a thread doing bulk reads on a USB device in a
> loop, and the device stops talking to you (for instance, waiting for you
> to reply), it becomes impossible to take any action on the device,
> including aborting the read or issuing a write to the device to tell it
> to kee
On Fri, Jul 02, 2004 at 05:11:52PM -0400, Alan Stern wrote:
> On Fri, 2 Jul 2004, Zephaniah E. Hull wrote:
>
> > On Tue, Jun 08, 2004 at 10:19:40PM +0200, Duncan Sands wrote:
> > > > Great, could you send me the patch? (So I have something usable until it
> > > > gets into mainline and a kernel is
On Fri, 2 Jul 2004, Zephaniah E. Hull wrote:
> On Tue, Jun 08, 2004 at 10:19:40PM +0200, Duncan Sands wrote:
> > > Great, could you send me the patch? (So I have something usable until it
> > > gets into mainline and a kernel is released with it.)
> >
> > Sure - I just have to write it first! It
On Tue, Jun 08, 2004 at 10:19:40PM +0200, Duncan Sands wrote:
> > Great, could you send me the patch? (So I have something usable until it
> > gets into mainline and a kernel is released with it.)
>
> Sure - I just have to write it first! It's a bit tricky to do right...
Has there been any progr
> I don't know for sure that the problem I'm having is related, but it sure
> sound like it:
Hi Ian, I was talking about the problem in usbfs where only one bulk or
control message can be in flight at any one time. Your problem seems
quite different to this, sorry!
All the best,
Duncan.
-
On Tue, 8 Jun 2004, Duncan Sands wrote:
Great, could you send me the patch? (So I have something usable until it
gets into mainline and a kernel is released with it.)
Sure - I just have to write it first! It's a bit tricky to do right...
Any further status on this?
I don't know for sure that the p
> Great, could you send me the patch? (So I have something usable until it
> gets into mainline and a kernel is released with it.)
Sure - I just have to write it first! It's a bit tricky to do right...
Duncan.
---
This SF.Net email is sponsor
On Mon, Jun 07, 2004 at 09:11:32PM +0200, Duncan Sands wrote:
> > With the device not sending us any more data until it receives the
> > write, and the write not getting to send until the bulk read finishes or
> > the device goes away.
> >
> > With the predictable annoyance this causes, of course.
> To give some background, the libusb backend of pilot-link is a slightly
> odd design, we do the init work, reset the device, and then setup a read
> thread, which basicly does a continuous loop of bulk no-timeout reads
> from USB.
>
> In the primary thread we do most of the work, including doing
On Mon, Jun 07, 2004 at 09:05:41AM +0200, Duncan Sands wrote:
> > > Are you sure? That seems impossible to me! Can you
> > > get a new call trace please.
> >
> > Hrm, I could have sworn that the kernel I tested with was rebuilt with
> > the patch, but now that I am trying it on rc2-mm1 with the
> > Are you sure? That seems impossible to me! Can you
> > get a new call trace please.
>
> Hrm, I could have sworn that the kernel I tested with was rebuilt with
> the patch, but now that I am trying it on rc2-mm1 with the patch, it
> does in fact seem to be working, mostly.
>
> Thanks a lot,
On Sat, Jun 05, 2004 at 09:55:01AM +0200, Duncan Sands wrote:
> On Friday 04 June 2004 23:30, Zephaniah E. Hull wrote:
> > On Fri, Jun 04, 2004 at 10:40:43PM +0200, Duncan Sands wrote:
> > > > c4bae310 Call Trace:
> > > > [] __down+0x85/0x120
> > > > [] __down_failed+0xb/0x14
> > > > [] .text.lo
On Friday 04 June 2004 23:30, Zephaniah E. Hull wrote:
> On Fri, Jun 04, 2004 at 10:40:43PM +0200, Duncan Sands wrote:
> > > c4bae310 Call Trace:
> > > [] __down+0x85/0x120
> > > [] __down_failed+0xb/0x14
> > > [] .text.lock.hub+0x69/0x82
> > > [] usbdev_ioctl+0x19f/0x710
> > > [] file_ioctl+0
On Fri, Jun 04, 2004 at 10:40:43PM +0200, Duncan Sands wrote:
> > c4bae310 Call Trace:
> > [] __down+0x85/0x120
> > [] __down_failed+0xb/0x14
> > [] .text.lock.hub+0x69/0x82
> > [] usbdev_ioctl+0x19f/0x710
> > [] file_ioctl+0x5d/0x170
> > [] sys_ioctl+0x116/0x250
> > [] syscall_call+0x7/0xb
On Fri, Jun 04, 2004 at 01:07:48PM -0700, Greg KH wrote:
> On Fri, Jun 04, 2004 at 04:02:11PM -0400, Zephaniah E. Hull wrote:
> >
> > lt-pilot-xfer D 0 11415 2709 (NOTLB)
> > d2ad3eb0 0086 c022391a 3231203a 000a2e35 0001 d2ad3ea7
> >d4edd
> c4bae310 Call Trace:
> [] __down+0x85/0x120
> [] __down_failed+0xb/0x14
> [] .text.lock.hub+0x69/0x82
> [] usbdev_ioctl+0x19f/0x710
> [] file_ioctl+0x5d/0x170
> [] sys_ioctl+0x116/0x250
> [] syscall_call+0x7/0xb
Does this help?
Ciao,
Duncan.
--- linux-2.5/drivers/usb/core/devio.c.orig
> Ah, can you not try the -mm1 kernel? This problem should not be in the
> mainline kernel. There was a locking issue in the last bk-usb patch that
> made it into the -mm1 kernel that was fixed yesterday.
I can confirm that the last kernel this worked with was 2.6.6. We
can't get libusb
On Fri, 4 Jun 2004, Greg KH wrote:
> On Fri, Jun 04, 2004 at 03:39:11PM -0400, Zephaniah E. Hull wrote:
> > Starting at 2.6.7-rc1 or so (that is when we first noticed it) the new
> > pilot-link libusb back end started deadlocking the entire USB bus that
> > the palm device was on.
> >
> > I have
On Fri, Jun 04, 2004 at 04:02:11PM -0400, Zephaniah E. Hull wrote:
>
> lt-pilot-xfer D 0 11415 2709 (NOTLB)
> d2ad3eb0 0086 c022391a 3231203a 000a2e35 0001 d2ad3ea7
>d4edd000 d7fc8a00 c8449790 abb31900 000f447a c4bae4b8 c977d824
On Fri, Jun 04, 2004 at 04:02:11PM -0400, Zephaniah E. Hull wrote:
> On Fri, Jun 04, 2004 at 12:52:47PM -0700, Greg KH wrote:
> > On Fri, Jun 04, 2004 at 03:39:11PM -0400, Zephaniah E. Hull wrote:
> > > Starting at 2.6.7-rc1 or so (that is when we first noticed it) the new
> > > pilot-link libusb b
On Fri, Jun 04, 2004 at 12:52:47PM -0700, Greg KH wrote:
> On Fri, Jun 04, 2004 at 03:39:11PM -0400, Zephaniah E. Hull wrote:
> > Starting at 2.6.7-rc1 or so (that is when we first noticed it) the new
> > pilot-link libusb back end started deadlocking the entire USB bus that
> > the palm device was
On Fri, Jun 04, 2004 at 03:39:11PM -0400, Zephaniah E. Hull wrote:
> Starting at 2.6.7-rc1 or so (that is when we first noticed it) the new
> pilot-link libusb back end started deadlocking the entire USB bus that
> the palm device was on.
>
> I have finally tracked it down to happening when we mak
22 matches
Mail list logo
