Messages in this thread |  | | | Date | Fri, 12 Aug 2011 01:40:35 +0200 | | From | Daniel Mack <> | | 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |