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]
Date:	Fri, 12 Aug 2011 01:40:35 +0200
From:	Daniel Mack <zonque@...il.com>
To:	Matěj Laitl <matej@...tl.cz>
CC:	Sarah Sharp <sarah.a.sharp@...ux.intel.com>,
	Alan Stern <stern@...land.harvard.edu>,
	Florian Mickler <florian@...kler.org>,
	Oliver Neukum <oliver@...kum.org>, linux-usb@...r.kernel.org,
	alsa-devel@...a-project.org, Takashi Iwai <tiwai@...e.de>,
	Clemens Ladisch <clemens@...isch.de>, pedrib@...il.com,
	William Light <wrl@...est.net>, Greg KH <greg@...ah.com>,
	linux-kernel@...r.kernel.org, Robert Hancock <hancockrwd@...il.com>
Subject: Re: Allocating buffers for USB transfers (again)

On 08/12/2011 01:29 AM, Matěj Laitl wrote:
> On 11. 8. 2011 Daniel Mack wrote:
>> On Thu, Aug 11, 2011 at 8:05 PM, Sarah Sharp
>>> Because according to Matej, he applied that patch, plus my patch to
>>> reject zero-length buffers[1], and he saw debugging that indicated he
>>> *did* see zero-length buffers.  Is there any chance your driver might
>>> submit a zero-length buffer in the middle of the isochronous URB
>>> transfer array?
>>
>> Hmm, judging from the code, this can only ever happen if we receive an
>> inbound iso frame which has a valid status and an actual_length of
>> zero. Also, it was not neccessary to catch this case for EHCI.
>>
>> Maetj, does this patch make any difference?
>
> This patch actually makes the sound playback _worse_. Now I get strange
> squawks where previously at least first seconds of a song sounded normally.
>
> However, I no longer get "zero length buffer submitted" or that "... Weird."
> debug messages, only several megabytes of: (should I post these somewhere?)
>
> xhci_hcd 0000:05:00.0: Giveback URB ffff880114cec000, len = 880, expected =
> 1000, status = -115
> xhci_hcd 0000:05:00.0: Giveback URB ffff880114740000, len = 352, expected =
> 1000, status = -115
> xhci_hcd 0000:05:00.0: underrun event on endpoint

Might be the hardware doesn't like this. As I said, the patch is blindly 
written and I couldn't test it. Did you test this on a EHCI port as well?

Daniel

--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ