Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> writes: > 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. no idea, just calling trace_printk(). Maybe some trace_printk() bug resolving caller symbols... >> 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'll do that >> I wonder if common->thread_wakeup_needed is racing. > > That can't be the cause, because the thread is already running. okay -- balbi
Attachment:
signature.asc
Description: PGP signature
