[#4934] test 1/5 will hang sometimes for gadget fs bulk test on bf527

Submitted By: Vivi Li

Open Date

2009-02-23 05:37:39 Close Date

2009-06-17 01:54:08

Priority:

Medium High Assignee:

Cliff Cai

Status:

Closed Fixed In Release:

N/A

Found In Release:

N/A Release:

Category:

N/A Board:

EZKIT Lite

Processor:

BF527 Silicon Revision:

Is this bug repeatable?:

Yes Resolution:

Fixed

Uboot version or rev.:

Toolchain version or rev.:

gcc4.1_2009-01-19

App binary format:

N/A

Summary: test 1/5 will hang sometimes for gadget fs bulk test on bf527

Details:

For gadget fs bulk test on bf527, sometimes it will hang at test 1 or 5.

test@uclinux63-527-usbdev:~/work/cruise/checkouts/uclinux-dist/testsuites/usbdev> sudo ./src/testusb -D /proc/bus/usb/005/049 -t1

unknown speed /proc/bus/usb/005/049

(no response)

test@uclinux63-527-usbdev:~/work/cruise/checkouts/uclinux-dist/testsuites/usbdev> sudo ./src/testusb -D /proc/bus/usb/005/041 -t5

unknown speed /proc/bus/usb/005/041

(no response)

At the same time, a message saying "fd 7, unclaimed = 512" show up on target board.

root:/> ./usb -r "1.3" -v

gadgetfs: bound to musb_hdrc driver

/dev/gadget/musb_hdrc ep0 configured

serial="1.3"

gadgetfs: suspended from state 2

** Thu Jan 9 15:38:11 1975

SUSPEND

gadgetfs: connected

CONNECT high speed

gadgetfs: disconnected

DISCONNECT

gadgetfs: connected

read 2 ep0 evgntsa

COdNECg hieh steedf

SEsUP :0.0 v0co0 infi0 2g5urSETaP ti.0on #3

6 v0302 i0409 255

SETUP 80.06 v0301 i0409 255

SETUP 80.06 v0303 i0409 255

SETUP 00.09 v0003 i0000 0

CONFIG #3

simple_source_thread start 1026 fd 6

simple_sink_thread start 2051 fd 7

SETUP 80.06 v0304 i0409 255

SETUP 80.06 v0305 i0409 255

SETUP 81.0a v0000 i0000 1

done simple_sink_thread

fd 7, unclaimed = 512

Follow-ups

--- Cliff Cai 2009-05-21 02:58:31

this problem is caused by read 0 byte data from an OUT pipe.

refer to simple_sink_thread() in usb.c.

and the root cause is located in the musb gadget driver(rxstate() in

musb_gadget.c)

When MUSB_RXCSR_RXPKTRDY is set ,it means there is a data packet in the Rx

FIFO.

but sometimes the read MUSB_RXCOUNT value is 0,this is obviously wrong if the

requested transfer length is not 0,and the transfered length is 0(this means the

transfer just started).When the driver sees the MUSB_RXCOUNT is 0,it compeltes

the whole transfer.

I guess that sometimes,when MUSB_RXCSR_RXPKTRDY is set,the MUSB_RXCOUNT is not

correctly set at the moment,maybe there is a delay.

In this test case,when read 0 byte data,the application will read the

MUSB_RXCOUNT again through IOCTL,and this time the value seems correct.

that is why:"fd 7, unclaimed = 512",here 512 is the value of

MUSB_RXCOUNT.

Cliff

--- Cliff Cai 2009-06-11 05:36:34

Fixed by disable double buffer mode for RX.

Cliff

--- Vivi Li 2009-06-17 01:54:08

OK now. Close it.

Files

Changes

Commits

Dependencies

Duplicates

Associations