Hi Hans, Alan, Greg,
commit 3d97ff63f8997761f12c8fbe8082996c6eeaba1a
Author: Hans de Goede
Date: Wed Jul 4 09:18:03 2012 +0200
usbdevfs: Use scatter-gather lists for large bulk transfers
breaks an usb programming cable over here. The problem is reported as
"bulk tranfer failed" [sic]
Hej Henrik,
Henrik Rydberg wrote:
> commit 3d97ff63f8997761f12c8fbe8082996c6eeaba1a
> Author: Hans de Goede
> Date: Wed Jul 4 09:18:03 2012 +0200
>
> usbdevfs: Use scatter-gather lists for large bulk transfers
>
> breaks an usb programming cable over here. The problem is reported as
>
On Wed, Oct 10, 2012 at 10:34:59PM +0200, Peter Stuge wrote:
> Hej Henrik,
>
> Henrik Rydberg wrote:
> > commit 3d97ff63f8997761f12c8fbe8082996c6eeaba1a
> > Author: Hans de Goede
> > Date: Wed Jul 4 09:18:03 2012 +0200
> >
> > usbdevfs: Use scatter-gather lists for large bulk transfers
> >
Henrik Rydberg wrote:
> > What is the programming cable and software that uses it?
>
> The programmer is impact, using libusbx-1.0.14-1.
Do you know for a fact that your version calls libusb-1.0? Did you
establish this with e.g. strace? ISE 11.1 impact uses only libusb.so,
ie. libusb-0.1.
Depend
Xiaofan Chen wrote:
> On Thu, Oct 11, 2012 at 2:50 PM, Peter Stuge wrote:
> > But it isn't certain that is is involved at all. If your impact
> > version uses libusb.so like in ISE 11.1 then it will not be. One way
> > to test is by trying to generate a libusb debug log. See
> > https://libusb.org
Hi,
On 10/10/2012 10:31 PM, Henrik Rydberg wrote:
Hi Hans, Alan, Greg,
commit 3d97ff63f8997761f12c8fbe8082996c6eeaba1a
Author: Hans de Goede
Date: Wed Jul 4 09:18:03 2012 +0200
usbdevfs: Use scatter-gather lists for large bulk transfers
breaks an usb programming cable over here. The p
Hi Hans,
> Oh what fun (not). The best way to figure out what really is going
> on is to get some usb level traces. Note my first hunch is that what
> you're seeing is a device firmware bug, as this patch together with
> a new libusb (which you seem to also have) will make bulk transfers
> run sli
Henrik Rydberg wrote:
> Hi Hans,
>
> > Oh what fun (not). The best way to figure out what really is going
> > on is to get some usb level traces. Note my first hunch is that what
> > you're seeing is a device firmware bug, as this patch together with
> > a new libusb (which you seem to also have)
On Thu, Oct 11, 2012 at 08:50:33AM +0200, Peter Stuge wrote:
> Henrik Rydberg wrote:
> > > What is the programming cable and software that uses it?
> >
> > The programmer is impact, using libusbx-1.0.14-1.
>
> Do you know for a fact that your version calls libusb-1.0? Did you
> establish this wit
On Thu, Oct 11, 2012 at 11:37:07PM +0200, Henrik Rydberg wrote:
> Hi Hans,
>
> > Oh what fun (not). The best way to figure out what really is going
> > on is to get some usb level traces. Note my first hunch is that what
> > you're seeing is a device firmware bug, as this patch together with
> > a
Hi,
On 10/11/2012 11:53 PM, Greg Kroah-Hartman wrote:
On Thu, Oct 11, 2012 at 11:37:07PM +0200, Henrik Rydberg wrote:
Hi Hans,
Oh what fun (not). The best way to figure out what really is going
on is to get some usb level traces. Note my first hunch is that whath
you're seeing is a device fir
On Thu, 11 Oct 2012, Henrik Rydberg wrote:
> From 40b70394747eea51fdd07cc8213dd6afd24b1b30 Mon Sep 17 00:00:00 2001
> From: Henrik Rydberg
> Date: Thu, 11 Oct 2012 23:27:04 +0200
> Subject: [PATCH] usbdevfs: Fix broken scatter-gather transfer
>
> The recently introduced handling of large bulk tr
Hi Alan,
> Instead of introducing a new local variable, why not simply update
> uurb->buffer? That's what we do elsewhere in the code.
It seemed fragile, due to these scary lines:
if (is_in && uurb->buffer_length > 0)
as->userbuffer = uurb->buffer;
else
> >>Or, the large bulk transfer actually never worked in the first place.
>
> Large input transfers certainly do, as they were part of my tests, but
> I must admit my test cases seem to not include large output transfers
> (my bad).
Oh right, I should change the wording to reflect that this is fo
On Fri, 12 Oct 2012, Henrik Rydberg wrote:
> Hi Alan,
>
> > Instead of introducing a new local variable, why not simply update
> > uurb->buffer? That's what we do elsewhere in the code.
>
> It seemed fragile, due to these scary lines:
>
> if (is_in && uurb->buffer_length > 0)
>
Hi,
On 10/12/2012 05:08 PM, Henrik Rydberg wrote:
Hi Alan,
Instead of introducing a new local variable, why not simply update
uurb->buffer? That's what we do elsewhere in the code.
It seemed fragile, due to these scary lines:
if (is_in && uurb->buffer_length > 0)
a
16 matches
Mail list logo
