Re: [PATCH] [musb_hdrc]: fix bug - EOVERFLOW failure when do usb gadget zero test t14

On Mon, Jun 30, 2008 at 08:03:31PM +0800, ext Bryan Wu wrote:
> On Wed, Jun 25, 2008 at 7:35 PM, Felipe Balbi <[email protected]> wrote:
> > On Wed, Jun 25, 2008 at 02:33:25PM +0800, ext Bryan Wu wrote:
> >> >From f77853398c3c5f88ea7833ecb15546bf39023b00 Mon Sep 17 00:00:00 2001
> >> From: Bryan Wu <[email protected]>
> >> Date: Wed, 25 Jun 2008 14:29:33 +0800
> >> Subject: [PATCH] [musb_hdrc]: fix bug - EOVERFLOW failure when do usb
> >> gadget zero test t14
> >>
> >> https://blackfin.uclinux.org/gf/project/uclinux-dist/tracker/?action=TrackerItemEdit&tracker_id=141&tracker_item_id=4141
> >>
> >> Sometimes the last IN request will got error response which will
> >> trigger EOVERFLOW error on USB host side.
> >> We need to flush fifo after a whole trasfer.
> >
> > It looks fine.
> >
> > I'll test it a bit more and meld it on the patch going to mailine on
> > next merge window ;-)
> >
> 
> Please hold for a while, our tester reported that the bug still could
> be found on Blackfin. Even with this patch, the test will fail
> randomly.
> For example, run testcase t14 10 times, 1 or 2 tests failed.
> 
> >From the data captured in Lecory USB analyzer, I think there are some
> bug in the OTG module:
> 1. PC Host send SETUP transfer to ep0 to tell gadget that Host will
> write 151 bytes to gadget (for example)
> 2. PC host send a series of OUT trasnfers for gadget, so gadget got
> the 151 bytes from host
> 3. PC host send IN pakcet for STATUS transfer, but gadget will report
> a garbage data 1byte or 2bytes instead of ZERO byte.
> 
> It seems that the bad response is automatically done by hardware. Do
> you find similar things in Davinci/OMAP platform?

I'm out of analyser here... Will get one still this week, I'll check it.

Basically reproducable with t14 right ?

this anyways, sounds quite weird.

-- 
	- Balbi
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html