On Tue, Mar 22, 2016 at 01:31:40AM +0000, Lipengcheng wrote: > Hi, > we have a problem like that we can start kernel successfully without > processing any other operations, but failed after pressing ctrl + c. After > our analsys, it is because of that, ctrl + c will produce an interruput,it > will be dealed with in xhci_resume->xhci_init->xhci_mem_init so that > dma_alloc_coherent fail, finally it will be calm down in the FUNCITON > LIST_DEL(&tt->tt_list). > As the modification , set flag to GFP_ATOMIC, disabling interrupt requests > will not be core dump, could you please tell me can I modify like this? > > Thanks very much > > Best Regards, > > Pengcheng Li > > > Modify 1: > xhci->dcbaa = dma_alloc_coherent(dev, sizeof(*xhci->dcbaa), &dma, > - GFP_KERNEL); > + GFP_ATOMIC); > Modify 2: > xhci->erst.entries = dma_alloc_coherent(dev, > sizeof(struct xhci_erst_entry) * ERST_NUM_SEGS, &dma, > - GFP_KERNEL); > + GFP_ATOMIC); > Modify 3: > - retval = xhci_mem_init(xhci, GFP_KERNEL); > + retval = xhci_mem_init(xhci, GFP_ATOMIC); > xhci_dbg_trace(xhci, trace_xhci_dbg_init, "Finished xhci_init");
Why isn't the 'flags' variable being use here instead of hard-coding GFP_KERNEL? Hm, it looks like that variable doesn't really make much sense as it's only ever called with GFP_KERNEL... Anyway, this is during init, there should not be any locks happening, so you can sleep, so using GFP_KERNEL is correct, I don't understand why GFP_ATOMIC is needed here. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
