linux-kernel - Re: REGRESSION: usbdevfs: Use-scatter-gather-lists-for-large-bulk-transfers

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <5076819C.9010504@redhat.com>
Date:	Thu, 11 Oct 2012 10:21:48 +0200
From:	Hans de Goede <hdegoede@...hat.com>
To:	Henrik Rydberg <rydberg@...omail.se>
CC:	Alan Stern <stern@...land.harvard.edu>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: REGRESSION: usbdevfs: Use-scatter-gather-lists-for-large-bulk-transfers

Hi,

On 10/10/2012 10:31 PM, Henrik Rydberg wrote:
> Hi Hans, Alan, Greg,
>
> commit 3d97ff63f8997761f12c8fbe8082996c6eeaba1a
> Author: Hans de Goede <hdegoede@...hat.com>
> 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] by the tool, and bisection leads to this
> commit. Reverting on top of 3.6 solves it for me.

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 slightly faster, which might be just enough to overwhelm your
device ...

Can you please do the following:
1) unplug as many usb devices as possible
2) plug in the programmer
3) run lsusb, note the programmer bus number
4) if the programmer is one the same bus as another device (other then
    a hub), try a different port
5) ideally rinse repeat until it is on a bus of its own, or atleast
    a bus with a device which generate little trafic
6) Writedown the bus number, and keep using the same port for
    all further tests

Then:
1) start wireshark as root, tell it to start capturing on the USB bus
you've ended up using
2) Do what you always do with the programmer
3) When finished, or when things have failed stop wireshark capture and
save the capture to a file

Repeat 2 times once with a kernel with the problematic commit, once without.

Then send me the 2 wireshark captures. Note:

1) Privacy warning: In theory I might be able to reconstruct what you're sending
over the captured USB bus when you send me these captures
2) Less is more, so if you can find some mini mini program to send to the
device you're programming that makes live easier (and should make 1 less of
an issue too).

Regards,

Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/