On Tue, 7 May 2013, victor yeo wrote: > > It is likely that this bug occurs because you don't use a spinlock in > > kagen2_ep_queue. Does the interrupt handler routine use a spinlock? > > Spinlock is Not used in interrupt handler routine. Then that's the reason for this bug. > >[start_transfer] 53425355 10d > >ept1 out queue len 0x200, buffer 0xc1304000 > >g_file_storage gadget: bulk-out, length 31: > > Is the kagen2_ep_queue function gotten interrupted here? So the > kagen2_ep_queue and interrupt routine need spinlock for > synchronisation? That's right. Interrupts can occur at almost any time (on multiprocessor systems they can occur even when interrupts are disabled on some of the CPUs). > > Maybe you haven't noticed this, but the REQUEST SENSE and TEST UNIT > > READY commands weren't received correctly either. The last three bytes > > in each command should be 0, but they aren't. They are: c3 63 4a. > > Where did those values come from? > > Yes, i haven't noticed the c3 63 4a. Clearly the last three bytes > should be zero. Maybe the UDC driver has a bug (Do the last 3 bytes > matter for file gadget? ). Well, it certainly matters if some of the bytes in the data blocks for a WRITE command get messed up! Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
