registry team mailing list archive

[MarkusRechberger <mrechberger@xxxxxxxxx>]

On Tue, Jul 13, 2010 at 5:14 PM, David Kühling
<544527@xxxxxxxxxxxxxxxxxx> wrote:
> This bugfix is incomplete.  Isochronous transfers are still broken, when
> running 32-bit software on a 64-bit kernel.  Function
> processcompl_compat() in devio.c needs a similar fix to the fix that was
> applied to processcompl().  Looking at processcompl_compat() I see:
>
>        if (as->userbuffer && urb->actual_length)
>                if (copy_to_user(as->userbuffer, urb->transfer_buffer,
>                                 urb->actual_length))
>                        return -EFAULT;
>
> correct code would be something like
>
>        if (as->userbuffer && urb->actual_length) {
>                if (urb->number_of_packets > 0)         /* Isochronous */
>                        i = urb->transfer_buffer_length;
>                else                                    /* Non-Isoc */
>                        i = urb->actual_length;
>                if (copy_to_user(as->userbuffer, urb->transfer_buffer, i))
>                        goto err_out;
>        }
>
> (note the difference between urb->actual_length and
> urb->transfer_buffer_length).
>
> With kernel 2.6.32-23-generic x86_64 on Ubuntu 10.04, using proprietary
> USB-hardware hooked up to the USB bus (with software compiled for
> 32-bit), I can directly observe how isochronous transfers retrieved via
> ioctl(.. USBDEVFS_REAPURB ..) are too short, i.e. the kernel does not
> write the end of the data packet to the supplied buffer.  Booting on the
> 2.6.31 kernel still present from before I upgraded from Ubuntu 9.10, the
> same software runs flawlessly.
>
> As a workaround I'll use the older kernel for now (also I could compile
> for 64-bit, actually...).
>

yes you're right, since we distribute 64 and 32bit drivers it doesn't
really affect us.
before applying any change you can submit some patches to us and we
can test them if needed.

Things should definitely not go upstream untested anymore as it used
to happen in the past with various kernel releases. (isochronous is
bugged with 2.6.26/27/28 (memory leak) and 32/33 (copying wrong memory
area). Luckily our hardware supports switching from ISO to BULK in
order to work around those issues - but bulk transfers have a bad
performance in userspace

Markus
> cheers,
>
> David
>
> --
> usbfs is bugged with >2.6.32.9 and <=2.6.33 (breaks VMWare, Qemu, sane scanners, ...)
> https://bugs.launchpad.net/bugs/544527
> You received this bug notification because you are a direct subscriber
> of the bug.
>

-- 
usbfs is bugged with >2.6.32.9 and <=2.6.33 (breaks VMWare, Qemu, sane scanners, ...)
https://bugs.launchpad.net/bugs/544527
You received this bug notification because you are a member of Registry
Administrators, which is the registrant for sane-backends.