Hi, >> Yes, it is silly. The hardware interrupt is not being generated for >> every SCSI command received, so the driver has to poll. I put the >> polling code in a thread, and this dilemma is fixed. > > Are you sure about this? If it is correct, you should _fix_ the > interrupt problem. Don't try to work around it by creating a new > thread. > > Figure out why there isn't an interrupt. Does your driver forget to > set an interrupt-enable bit? > >> I still observe the SCSI_WRITE_10 command time out sometimes. When >> time out happens, the gadget log shows: >> >> g_file_storage gadget: invalid CBW: len 512 sig 0x6f007442 >> g_file_storage gadget: bulk-in set wedge >> >> Is it because the gadget expects 31 byte command, but 512 byte data is >> received instead? > > No. It is because kagen2_ep_queue returned _before_ a new command was > received, probably as a result of your polling thread. Since there was > no new command, the data in the buffer was wrong. > >> The full UDC/gadget log is attached. Hope it is useful. If not, i will >> add in more printk statements. > > You can see the problem in the log: > >> g_file_storage gadget: bulk-in, length 13: >> 00000000: 55 53 42 53 50 00 00 00 00 00 00 00 00 >> [start_transfer] 53425355 50 >> ept1 in queue len 0xd, buffer 0xc0c3c000 >> 0: 0x53425355 >> 4: 0x50 >> 8: 0x0 >> bulk_in_complete --> 0, 13/13 > > That was the end of the previous command. Now the gadget waits for a > new command to arrive. > >> [start_transfer] 6f007442 7000 >> ept1 out queue len 0x200, buffer 0xc1338000 >> before kagen2_ep_queue >> after kagen2_ep_queue >> kagen2_ep_queue 512 512 512 >> [kagen2_ep_queue] 6f007442 7000 > > kagen2_ep_queue returned but there was no interrupt. This means no new > data was received, so the old data is still in the buffer. > >> g_file_storage gadget: bulk_out_complete --> 0, 512/31 >> g_file_storage gadget: invalid CBW: len 512 sig 0x6f007442 >> g_file_storage gadget: bulk-in set wedge > > That 0x6f007442 is the old data from the previous command, as you can > see from the log messages (it is the same data that was present when > kagen2_ep_queue was called). >
Now the UDC driver is working on both Linux and Windows host, meaning the read/write operation is ok. I still use the polling method, because waiting for interrupt is not reliable. Is it possible to contribute the code to Linux community? On the other hand, i run the USB 2.0 command verifier to test the gadget, the gadget crashes at BOS descriptor test. I think the gadget is not able to handle BOS descriptor, is the gadget driver setup function returning negative error code for BOS descriptor? Thanks, victor
g_file_storage gadget: high-speed config #1 Unable to handle kernel NULL pointer dereference at virtual address 00000000 pgd = c0204000 [00000000] *pgd=00000000 Internal error: Oops - BUG: 817 [#1] PREEMPT ARM Modules linked in: g_file_storage kagen2_udc ath6kl_sdio ath6kl_core ka2000_sdio ka2000_sdhc CPU: 0 Not tainted (3.4.4+ #43) PC is at kagen2_irq+0x290/0x3bc [kagen2_udc] LR is at handle_irq_event_percpu+0x30/0x178 pc : [<bf02f704>] lr : [<c02496d0>] psr: 60000093 sp : c132de98 ip : 00000002 fp : c132debc r10: 00000000 r9 : 00000000 r8 : 00000000 r7 : 00000020 r6 : 00000002 r5 : 00000201 r4 : c12a8c00 r3 : 00000000 r2 : 00000001 r1 : c12a8d1c r0 : 00000000 Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel Control: 0005717f Table: 0130c000 DAC: 00000017 Process chkbusy_t (pid: 121, stack limit = 0xc132c270) Stack: (0xc132de98 to 0xc132e000) de80: 00000080 00020000 dea0: c12b9840 c049cf70 00000000 00000020 c132dee4 c132dec0 c02496d0 bf02f484 dec0: c049cf70 c132c000 c12b9840 c132df94 00000000 00000000 c132df04 c132dee8 dee0: c0249878 c02496b0 f5006000 c049cf70 00000000 f5006000 c132df1c c132df08 df00: c024bd38 c0249828 c024bc24 00000020 c132df34 c132df20 c02490e0 c024bc34 df20: 00000040 00000020 c132df4c c132df38 c0209c2c c02490c8 bf02f8c0 00000013 df40: c132df5c c132df50 c0208410 c0209bd4 c132dfbc c132df60 c0208f14 c0208410 df60: 00000000 40000000 0288001f c2886000 c12a8c00 c12a8c00 bf02f894 00000013 df80: 00000000 00000000 00000000 c132dfbc c132c000 c132dfa8 40000001 bf02f8c0 dfa0: 00000013 ffffffff 00000000 c128dd58 c132dff4 c132dfc0 c022f8f4 bf02f8a4 dfc0: c128dd58 00000000 c12a8c00 00000000 c132dfd0 c132dfd0 00000000 c128dd58 dfe0: c022f860 c02191c8 00000000 c132dff8 c02191c8 c022f870 000008f0 00000402 Backtrace: [<bf02f474>] (kagen2_irq+0x0/0x3bc [kagen2_udc]) from [<c02496d0>] (handle_irq_event_percpu+0x30/0x178) r7:00000020 r6:00000000 r5:c049cf70 r4:c12b9840 [<c02496a0>] (handle_irq_event_percpu+0x0/0x178) from [<c0249878>] (handle_irq_event+0x60/0x7c) [<c0249818>] (handle_irq_event+0x0/0x7c) from [<c024bd38>] (handle_edge_irq+0x114/0x16c) r6:f5006000 r5:00000000 r4:c049cf70 r3:f5006000 [<c024bc24>] (handle_edge_irq+0x0/0x16c) from [<c02490e0>] (generic_handle_irq+0x28/0x38) r4:00000020 r3:c024bc24 [<c02490b8>] (generic_handle_irq+0x0/0x38) from [<c0209c2c>] (handle_IRQ+0x68/0x8c) r4:00000020 r3:00000040 [<c0209bc4>] (handle_IRQ+0x0/0x8c) from [<c0208410>] (asm_do_IRQ+0x10/0x14) r5:00000013 r4:bf02f8c0 [<c0208400>] (asm_do_IRQ+0x0/0x14) from [<c0208f14>] (__irq_svc+0x34/0xbc) Exception stack(0xc132df60 to 0xc132dfa8) df60: 00000000 40000000 0288001f c2886000 c12a8c00 c12a8c00 bf02f894 00000013 df80: 00000000 00000000 00000000 c132dfbc c132c000 c132dfa8 40000001 bf02f8c0 dfa0: 00000013 ffffffff [<bf02f894>] (chkbusy_thread+0x0/0x60 [kagen2_udc]) from [<c022f8f4>] (kthread+0x94/0xa0) r4:c128dd58 r3:00000000 [<c022f860>] (kthread+0x0/0xa0) from [<c02191c8>] (do_exit+0x0/0x6f0) r6:c02191c8 r5:c022f860 r4:c128dd58 Code: e594311c e3a02001 e3a0c002 e584c120 (e5c32000) ka2000_disable_irq(32) ---[ end trace c87e6f70ddbdf46f ]--- Kernel panic - not syncing: Fatal exception in interrupt
