On Tue, 31 May 2016, Felipe Balbi wrote: > I've sprinkled a few trace_printk() around in g_mass_storage and got > some extra info. So here's a good transfer: ... > And here's the bad case (with the last working WRITE_10): > > > irq/17-dwc3-1336 [000] d... 839.825613: fsg_common_set_inquiry_string: ep1out: 31/1024 --> 0 > > We get CBW and wakeup our mass storage kthread... > > > file-storage-1335 [002] .... 839.825621: fsg_common_put: WRITE_10 > > ... which parses it and starts all the transfers below > > > irq/17-dwc3-1336 [000] d... 839.825708: fsg_common_set_inquiry_string: ep1out: 16384/16384 --> 0 > > irq/17-dwc3-1336 [000] d... 839.825783: fsg_common_set_inquiry_string: ep1out: 16384/16384 --> 0 Why do all these lines say "fsg_common_set_inquiry_string"? That routine gets used only when processing INQUIRY commands. ... > total of 1MiB transferred > > > irq/17-dwc3-1336 [000] d... 839.828020: fsg_common_set_inquiry_string: ep1in: 13/13 --> 0 > > Our CSW completes fine > > > irq/17-dwc3-1336 [000] d... 839.828022: fsg_common_set_inquiry_string: ep1out: 31/1024 --> 0 > > 2 us later, we receive another CBW, but the thread doesn't run. Any ideas? > > > irq/17-dwc3-1336 [000] d... 901.049297: fsg_common_set_inquiry_string: ep1out: 31/1024 --> 0 The CBW is received by get_next_command(), which runs in the fsg thread. Therefore the thread is already running; the question is why doesn't it continue? You might want to add some debugging to fsg_main_thread() to see what happens with the return codes from get_next_command(), do_scsi_command(), and finish_reply(). > I wonder if common->thread_wakeup_needed is racing. That can't be the cause, because the thread is already running. 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
