On Fri, Sep 18, 2015 at 11:03:26AM +0100, Felipe Tonello wrote: > After some debugging, here is where I am: > > The crash trace is like this: > > (f_midi.c) > -> ALSA calls f_midi_in_trigger() > ->tasklet_hi_schedule(&midi->tasklet) > -> f_midi_transmit(midi, NULL) the NULL here causes the f_midi to > request a usb_request allocation, also it sets req->complete (which is > not been called? I am investigating this) ->complete() is called by the UDC when the request actually completes. > -> usb_ep_queue(ep, req, GFP_ATOMIC) > (chipidea/udc.c) > -> ep_queue(ep, req, gfp_flags) > -> _ep_queue(ep, req, gfp_flags) > -> _hardware_enqueue(hwep, hwreq) here is where it is crashing > -> add_td_to_list(hwep, hwreq, count) this guy returns > an error from dma_pool_alloc(), out of mem, which is not been checked > (I have a patch for this) oh, this probably part of the error. Care to send it ? > -> lastnode = list_entry(hwreq->tds.prev, struct > td_node, td) get last node (which is NULL) > -> lastnode->ptr->next = cpu_to_le32(TD_TERMINATE) > CRASH!!! lastnode->ptr is NULL if lastnode was initialized with list_entry(), it can't be NULL. You're missing something > My idea is that some how the f_midi is not calling free_ep_req(ep, > req) properly. I am still investigating this. > > One thing to bear in mind is that I used ether gadget and mass_storage > gadget as well and they both work just fine. Also that the device I am > running generates a *lot* of MIDI output, much more than the normal > usage, which might be triggering this bug that no one previously had. > > Any comments? yeah, continue debugging, what other information can you gather ? Does the problem go away if you add a ton of printks() around the code ? -- balbi
Attachment:
signature.asc
Description: Digital signature
