Re: 答复: 答复: 答复: 答复: 【xhci】suspend and resume core dump problem
Hi, On 03/29/2016 05:17 PM, Lipengcheng wrote: > Hi >Thanks Baolu very much! >Because of the reason usb3 module can not be used, it will affect the > strong of usb3 module; > 1, the xhci control is suspend and resume, why to re-allocate memory? Some controllers need to set XHCI_RESET_ON_RESUME quirk. With this quirk bit set, host will be reset and reinitialized during resuming. > 2, whether we can allocate memory for more times, so we can avoid the > problem; Sorry. I didn't get your point. Best regards, Baolu > > Best Regards, > Pengcheng Li > > >> -Original Message- >> From: Lu Baolu [mailto:baolu...@linux.intel.com] >> Sent: Friday, March 25, 2016 10:19 PM >> To: Lipengcheng; Mathias Nyman; gre...@linuxfoundation.org >> Cc: st...@rowland.harvard.edu; ba...@ti.com; chasemetzge...@gmail.com; >> mj...@coreos.com; kbo...@gmail.com; jun...@freescale.com; >> robert.schlabb...@gmx.net; linux-usb@vger.kernel.org >> Subject: Re: 答复: 答复: 答复: 答复: 【xhci】suspend and resume core dump problem >> >> Hi, >> >> On 03/25/2016 03:39 PM, Lipengcheng wrote: >>> Hi, >>>Thanks Baolu very much! >>>The kernel is 3.10.Before the problem is inevitable emergence. But we >>> fix patch number:b630d4b9d05ba2e66878ca4614946d0f950d4111 >> and your suggest. >>> Then we resume and suspend the seventh and it is ok only if the usb3 can >>> not work. So the changes are effective. >> Thanks for testing. >> >>>In the wrong state which the usb3 can not work, we continue to suspend >>> and resume. It will be core dump. Should it be a normal >> phenomenon? >> >> dpm_run_callback(): platform_pm_resume+0x0/0x5c returns -12 >> PM: Device hiusb-xhci.0 failed to resume: error -12 >> >> >> Your xHCI host controller failed to resume. As the result, your usb3 devices >> should not work. You couldn't suspend it once more either. >> >> Best Regards, >> Baolu -- 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
RE: 答复: 答复: 答复: 答复: 【xhci】suspend and resume core dump problem
Hi Thanks Baolu very much! Because of the reason usb3 module can not be used, it will affect the strong of usb3 module; 1, the xhci control is suspend and resume, why to re-allocate memory? 2, whether we can allocate memory for more times, so we can avoid the problem; Best Regards, Pengcheng Li > -Original Message- > From: Lu Baolu [mailto:baolu...@linux.intel.com] > Sent: Friday, March 25, 2016 10:19 PM > To: Lipengcheng; Mathias Nyman; gre...@linuxfoundation.org > Cc: st...@rowland.harvard.edu; ba...@ti.com; chasemetzge...@gmail.com; > mj...@coreos.com; kbo...@gmail.com; jun...@freescale.com; > robert.schlabb...@gmx.net; linux-usb@vger.kernel.org > Subject: Re: 答复: 答复: 答复: 答复: 【xhci】suspend and resume core dump problem > > Hi, > > On 03/25/2016 03:39 PM, Lipengcheng wrote: > > Hi, > >Thanks Baolu very much! > >The kernel is 3.10.Before the problem is inevitable emergence. But we > > fix patch number:b630d4b9d05ba2e66878ca4614946d0f950d4111 > and your suggest. > > Then we resume and suspend the seventh and it is ok only if the usb3 can > > not work. So the changes are effective. > > Thanks for testing. > > >In the wrong state which the usb3 can not work, we continue to suspend > > and resume. It will be core dump. Should it be a normal > phenomenon? > > dpm_run_callback(): platform_pm_resume+0x0/0x5c returns -12 > PM: Device hiusb-xhci.0 failed to resume: error -12 > > > Your xHCI host controller failed to resume. As the result, your usb3 devices > should not work. You couldn't suspend it once more either. > > Best Regards, > Baolu
Re: 答复: 答复: 答复: 答复: 【xhci】suspend and resume core dump problem
Hi, On 03/25/2016 03:39 PM, Lipengcheng wrote: > Hi, >Thanks Baolu very much! >The kernel is 3.10.Before the problem is inevitable emergence. But we fix > patch number:b630d4b9d05ba2e66878ca4614946d0f950d4111 and your suggest. > Then we resume and suspend the seventh and it is ok only if the usb3 can not > work. So the changes are effective. Thanks for testing. >In the wrong state which the usb3 can not work, we continue to suspend and > resume. It will be core dump. Should it be a normal phenomenon? dpm_run_callback(): platform_pm_resume+0x0/0x5c returns -12 PM: Device hiusb-xhci.0 failed to resume: error -12 Your xHCI host controller failed to resume. As the result, your usb3 devices should not work. You couldn't suspend it once more either. Best Regards, Baolu -- 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
RE: 答复: 答复: 答复: 答复: 【xhci】suspend and resume core dump problem
a681dea8 8006c028 0002 80606560 dea0: 0007 8070b9bc a78f0a40 806476a4 a681ded4 a681dec0 8006c858 8006c290 dec0: a72b 0007 a681defc a681ded8 8006b498 8006c688 0007 a6298a00 dee0: a6298a18 a681df70 a78f0b40 802fbc0c a681df0c a681df00 802fbc2c 8006b400 df00: a681df3c a681df10 8016ebe4 802fbc18 a681df70 a724d0c0 0007 76f49000 df20: a681df70 0007 a681df6c a681df40 80104994 8016eae4 df40: a681df4c a724d0c0 a681df70 76f49000 0007 df60: a681dfa4 a681df70 80104b4c 801048cc 0022 0007 df80: 00f07008 0007 0004 80015348 a681c000 a681dfa8 dfa0: 80015100 80104b04 0007 00f07008 0005 76f49000 0007 dfc0: 0007 00f07008 0007 0004 76f49000 00f07008 7ef4bd2c dfe0: 7ef4ba40 76d9b2bc 76df9ccc 6010 0005 f5dfdfad df3d1857 [<7f8ff624>] (xhci_suspend+0x168/0x410 [xhci_hcd]) from [<7f8ff8f0>] (hiusb_xhci_hcd_drv_suspend+0x24/0x38 [xhci_hcd]) [<7f8ff8f0>] (hiusb_xhci_hcd_drv_suspend+0x24/0x38 [xhci_hcd]) from [<80352ff8>] (platform_pm_suspend+0x3c/0x64) [<80352ff8>] (platform_pm_suspend+0x3c/0x64) from [<80358538>] (dpm_run_callback+0x28/0x58) [<80358538>] (dpm_run_callback+0x28/0x58) from [<80358c98>] (__device_suspend+0x140/0x30c) [<80358c98>] (__device_suspend+0x140/0x30c) from [<80359244>] (dpm_suspend+0x70/0x21c) [<80359244>] (dpm_suspend+0x70/0x21c) from [<8035945c>] (dpm_suspend_start+0x6c/0x70) [<8035945c>] (dpm_suspend_start+0x6c/0x70) from [<8006c304>] (suspend_devices_and_enter+0x80/0x3f8) [<8006c304>] (suspend_devices_and_enter+0x80/0x3f8) from [<8006c858>] (pm_suspend+0x1dc/0x23c) [<8006c858>] (pm_suspend+0x1dc/0x23c) from [<8006b498>] (state_store+0xa4/0x134) [<8006b498>] (state_store+0xa4/0x134) from [<802fbc2c>] (kobj_attr_store+0x20/0x24) [<802fbc2c>] (kobj_attr_store+0x20/0x24) from [<8016ebe4>] (sysfs_write_file+0x10c/0x18c) [<8016ebe4>] (sysfs_write_file+0x10c/0x18c) from [<80104994>] (vfs_write+0xd4/0x1a0) [<80104994>] (vfs_write+0xd4/0x1a0) from [<80104b4c>] (SyS_write+0x54/0x80) [<80104b4c>] (SyS_write+0x54/0x80) from [<80015100>] (ret_fast_syscall+0x0/0x30) Code: e30c0fb0 e59f12a8 e3470f90 e300234e (e5965018) ---[ end trace 719c467f2461e924 ]--- > -Original Message- > From: Lu Baolu [mailto:baolu...@linux.intel.com] > Sent: Thursday, March 24, 2016 10:37 AM > To: Lipengcheng; Mathias Nyman; gre...@linuxfoundation.org > Cc: st...@rowland.harvard.edu; ba...@ti.com; chasemetzge...@gmail.com; > mj...@coreos.com; kbo...@gmail.com; jun...@freescale.com; > robert.schlabb...@gmx.net; linux-usb@vger.kernel.org > Subject: Re: 答复: 答复: 答复: 答复: 【xhci】suspend and resume core dump problem > > Hi, > > On 03/23/2016 11:38 AM, Lipengcheng wrote: > >> It looks like a wild pointer exists after xhci_mem_cleanup() is called. > >> >Let me try to reproduce it and seek for a fix. > > > > Hi, > >Thanks very much. > >The kernel is 3.10 and is inevitable emergence. The kernel 3.18 is > > accidental, but I don't know the reason. > > > > Operation steps: > > > > usb usb1: root hub lost power or was reset usb usb2: root hub lost > > power or was reset usb usb3: root hub lost power or was reset usb > > usb4: root hub lost power or was reset usb 1-2: reset high-speed USB > > device number 2 using hiusb-ehci > > ^Cusb usb5: root hub lost power or was reset <-press ctrl > > +c and the problem will happen > > usb usb6: root hub lost power or was reset > > Can you please test below change? It doesn't fix your dma_alloc_coherent() > failure issue. It is supposed to fix the core dump issue when > dma_alloc_coherent() fails in xhci_mem_init(). > > diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c index > 80c1de2..53fe4ad 100644 > --- a/drivers/usb/host/xhci-mem.c > +++ b/drivers/usb/host/xhci-mem.c > @@ -1860,6 +1860,11 @@ no_bw: > kfree(xhci->port_array); > kfree(xhci->rh_bw); > kfree(xhci->ext_caps); > + xhci->usb2_ports = NULL; > + xhci->usb3_ports = NULL; > + xhci->port_array = NULL; > + xhci->rh_bw = NULL; > + xhci->ext_caps = NULL; > > xhci->page_size = 0; > xhci->page_shift = 0; > > Best regards, > Baolu > > > Thanks, > > Pengcheng Li
Re: 答复: 答复: 答复: 答复: 【xhci】suspend and resume core dump problem
Hi, On 03/23/2016 11:38 AM, Lipengcheng wrote: >> It looks like a wild pointer exists after xhci_mem_cleanup() is called. >> >Let me try to reproduce it and seek for a fix. > > Hi, >Thanks very much. >The kernel is 3.10 and is inevitable emergence. The kernel 3.18 is > accidental, but I don't know the reason. > > Operation steps: > > usb usb1: root hub lost power or was reset > usb usb2: root hub lost power or was reset > usb usb3: root hub lost power or was reset > usb usb4: root hub lost power or was reset > usb 1-2: reset high-speed USB device number 2 using hiusb-ehci > ^Cusb usb5: root hub lost power or was reset <-press ctrl > +c and the problem will happen > usb usb6: root hub lost power or was reset Can you please test below change? It doesn't fix your dma_alloc_coherent() failure issue. It is supposed to fix the core dump issue when dma_alloc_coherent() fails in xhci_mem_init(). diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c index 80c1de2..53fe4ad 100644 --- a/drivers/usb/host/xhci-mem.c +++ b/drivers/usb/host/xhci-mem.c @@ -1860,6 +1860,11 @@ no_bw: kfree(xhci->port_array); kfree(xhci->rh_bw); kfree(xhci->ext_caps); + xhci->usb2_ports = NULL; + xhci->usb3_ports = NULL; + xhci->port_array = NULL; + xhci->rh_bw = NULL; + xhci->ext_caps = NULL; xhci->page_size = 0; xhci->page_shift = 0; Best regards, Baolu > Thanks, > Pengcheng Li -- 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
Re: 答复: 答复: 答复: 【xhci】suspend and resume core dump problem
On 03/22/2016 08:09 PM, Lipengcheng wrote: >> >diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c >> >index fbf75e5..406c872 100644 >> >--- a/drivers/usb/host/xhci-mem.c >> >+++ b/drivers/usb/host/xhci-mem.c >> >@@ -1856,6 +1856,7 @@ no_bw: >> > kfree(xhci->usb3_ports); >> > kfree(xhci->port_array); >> > kfree(xhci->rh_bw); >> >+ xhci->rh_bw = NULL; >> > >> > xhci->page_size = 0; >> > xhci->page_shift = 0; > We used to try to do it before, but it still has the same problem. > Hi Mathias, It looks like a wild pointer exists after xhci_mem_cleanup() is called. Let me try to reproduce it and seek for a fix. Best regards, Baolu -- 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
Re: 答复: 答复: 【xhci】suspend and resume core dump problem
On 22.03.2016 08:05, Lipengcheng wrote: Hi, Why is that function failing? That seems suspicious. According to the analysis, in list_for_each_entry_safe(tt, n, >rh_bw[i].tts, tt_list) function, (tt->tt_list).prev=0x0. When list_del(>tt_list) causing to core dump. Looks like you end up calling xhci_mem_cleanup() twice, once after a failed resume (or resume from hibernate), and a second time when allocating dma memory in xhci_mem_init() fails. This change should help for the xhci part of thee oops: diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c index fbf75e5..406c872 100644 --- a/drivers/usb/host/xhci-mem.c +++ b/drivers/usb/host/xhci-mem.c @@ -1856,6 +1856,7 @@ no_bw: kfree(xhci->usb3_ports); kfree(xhci->port_array); kfree(xhci->rh_bw); + xhci->rh_bw = NULL; xhci->page_size = 0; xhci->page_shift = 0; 3.10 also had some other similar issues when xhci_mem_init() called xhci_mem_cleanup() failed mid initialization. make sure you have the following patches included: commit 5dc2808c4729bf080487e61b80ee04e0fdb12a37 xhci: delete endpoints from bandwidth list before freeing whole device commit c207e7c50f31113c24a9f536fcab1e8a256985d7 xhci: Fix null pointer dereference if xhci initialization fails commit 0eda06c7c17ae48d7db69beef57f6e2b20bc3c72 usb: xhci: Fix OOPS in xhci error handling code As Oliver said, the other thing that needs to be fixed is the interruptible sleep somewhere in dma_alloc_coherent(). -Mathias -- 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
Re: 答复: 【xhci】suspend and resume core dump problem
On Mon, 2016-03-21 at 23:41 -0400, gre...@linuxfoundation.org wrote: > On Tue, Mar 22, 2016 at 03:17:08AM +, Lipengcheng wrote: > > Hi, > > Thanks for your reply. > > When the suspend and resume process , the operation of press ctrl + c > > will produce an interruput and cause to allocate memory failed. It causes > > the usb3 module can not be used and core dump after resume process. > > what are you pressing ctrl+c on? Why would that do anything on a USB > keyboard to interrupt the host? It causes a signal to be delivered. Obviously signals are ignored if memory allocation doesn't sleep. Your fix is wrong, but you found the cause. Somebody is using interruptible sleep at a place where uninterruptible sleep must be used. You need a stack trace to find out where the bug is. Can you replicate this on the current upstream? If not, please contact your vendor. Regards Oliver -- 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
Re: 答复: 答复: 【xhci】suspend and resume core dump problem
On Tue, Mar 22, 2016 at 03:51:27AM +, Lipengcheng wrote: > Hi, >Thanks Lu Baolu, > >The core dump says "PC is at xhci_mem_cleanup+0x4e4/0x574 [xhci_hcd] ". > >But this call flow shows error happens in dma allocation. Which is correct? > >Or, anything I misunderstood? > Sorry . I am not description clear . > Because the interrupt makes the memory allocation fails, then enter the > error handling procedures(xhci_mem_cleanup).In the function,it is core dump. What is generating that interrupt? -- 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
Re: 答复: 【xhci】suspend and resume core dump problem
On Tue, Mar 22, 2016 at 11:36:47AM +0800, Lu Baolu wrote: > Hi, > > On 03/22/2016 11:17 AM, Lipengcheng wrote: > > Hi, > > Thanks for your reply. > > When the suspend and resume process , the operation of press ctrl + c > > will produce an interruput and cause to allocate memory failed. It causes > > the usb3 module can not be used and core dump after resume process. > > Software call flow: > > |xhci_resume > > ||xhci_init > > |||xhci_mem_init > > dma_alloc_coherent > > |dma_alloc_from_contiguous > > In dma_alloc_from_contiguous return -4 (Interrupted system call). > > The core dump says "PC is at xhci_mem_cleanup+0x4e4/0x574 [xhci_hcd] ". > But this call flow shows error happens in dma allocation. Which is correct? > Or, anything I misunderstood? Why is that function failing? That seems suspicious. 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
Re: 答复: 【xhci】suspend and resume core dump problem
On Tue, Mar 22, 2016 at 03:17:08AM +, Lipengcheng wrote: > Hi, > Thanks for your reply. > When the suspend and resume process , the operation of press ctrl + c will > produce an interruput and cause to allocate memory failed. It causes the usb3 > module can not be used and core dump after resume process. what are you pressing ctrl+c on? Why would that do anything on a USB keyboard to interrupt the host? > Software call flow: > |xhci_resume > ||xhci_init > |||xhci_mem_init > dma_alloc_coherent > |dma_alloc_from_contiguous > In dma_alloc_from_contiguous return -4 (Interrupted system call). Is this in some type of emulator? > > Core dump information： > > Vi Resume OK > PM resume OK > usb usb1: root hub lost power or was reset > usb usb2: root hub lost power or was reset > ^Cusb usb3: root hub lost power or was reset > usb usb4: root hub lost power or was reset > usb usb5: root hub lost power or was reset > usb usb6: root hub lost power or was reset > hiusb-xhci hiusb-xhci.0: Couldn't initialize memory > Unable to handle kernel NULL pointer dereference at virtual address > pgd = a7324000 > [] *pgd=27265831, *pte=, *ppte= > Internal error: Oops: 817 [#1] SMP ARM > Modules linked in: tntfs(PO) xhci_hcd ohci_hcd ehci_hcd hi_pmoc(O) hi_vi(O) > hi_keyled(O) hi_aenc(O) hi_venc(O) hi_png(O) hi_jpge(O) hi_jpeg(O) hi_ir(O) > hi_fb(O) hi_pwm(O) hi_mce(O) hi_avplay(O) hi_pvr(O) hi_sync(O) hi_vou(O) > hi_aiao(O) hi_adsp(O) hi_hdmi(O) hi_cipher(O) hi_vdec(O) hi_vpss(O) hi_pq(O) > hi_pdm(O) hi_svdec(O) hi_vfmw(O) hi_adec(O) hi_demux(O) hi_otp(O) hi_tde(O) > mali(O) hi_i2c(O) hi_gpio_i2c(O) hi_gpio(O) hi_common(O) hi_mmz(O) hi_media(O) > CPU: 0 PID: 1113 Comm: sample_pmoc Tainted: P O 3.10.0_s40 #1 Can you remove all of your "custom" and closed source kernel drivers? Also 3.10 is very old and obsolete, please work with the company that is forcing you to use such a kernel version, as you are paying for support from them. Does this happen on 4.5? 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
Re: 答复: 【xhci】suspend and resume core dump problem
72e3e94 8087c684 80052514 80743a28 a72e3e9c > 3e80: a72e3e9c a72e3ebc a72e3ea8 8006bfe8 0002 80606560 > 3ea0: 0007 8070b998 a78f0a40 806476a4 a72e3ed4 a72e3ec0 8006c818 8006c250 > 3ec0: a7993000 0007 a72e3efc a72e3ed8 8006b458 8006c648 0007 a79f2c80 > 3ee0: a79f2c98 a72e3f70 a78f0b40 802fbbcc a72e3f0c a72e3f00 802fbbec 8006b3c0 > 3f00: a72e3f3c a72e3f10 8016eba4 802fbbd8 a72e3f70 a797c840 0007 76fad000 > 3f20: a72e3f70 0007 a72e3f6c a72e3f40 80104954 8016eaa4 > 3f40: a72e3f4c a797c840 a72e3f70 76fad000 0007 > 3f60: a72e3fa4 a72e3f70 80104b0c 8010488c 0022 0007 > 3f80: 00092008 0007 0004 80015348 a72e2000 a72e3fa8 > 3fa0: 80015100 80104ac4 0007 00092008 0005 76fad000 0007 > 3fc0: 0007 00092008 0007 0004 76fad000 00092008 7e88dd2c > 3fe0: 7e88da40 76dff2bc 76e5dccc 6010 0005 0410 11004001 > [<7f840468>] (xhci_mem_cleanup+0x4e4/0x574 [xhci_hcd]) from [<7f841d54>] > (xhci_mem_init+0xecc/0x1110 [xhci_hcd]) > [<7f841d54>] (xhci_mem_init+0xecc/0x1110 [xhci_hcd]) from [<7f83da28>] > (xhci_init+0x50/0x54 [xhci_hcd]) > [<7f83da28>] (xhci_init+0x50/0x54 [xhci_hcd]) from [<7f83df78>] > (xhci_resume+0x284/0x424 [xhci_hcd]) > [<7f83df78>] (xhci_resume+0x284/0x424 [xhci_hcd]) from [<7f83e14c>] > (hiusb_xhci_hcd_drv_resume+0x34/0x38 [xhci_hcd]) > [<7f83e14c>] (hiusb_xhci_hcd_drv_resume+0x34/0x38 [xhci_hcd]) from > [<8035301c>] (platform_pm_resume+0x3c/0x5c) > [<8035301c>] (platform_pm_resume+0x3c/0x5c) from [<803584f8>] > (dpm_run_callback+0x28/0x58) > [<803584f8>] (dpm_run_callback+0x28/0x58) from [<80358f38>] > (device_resume+0x114/0x280) > [<80358f38>] (device_resume+0x114/0x280) from [<80359530>] > (dpm_resume+0x110/0x224) > [<80359530>] (dpm_resume+0x110/0x224) from [<8035a5a0>] > (dpm_resume_end+0x1c/0x28) > [<8035a5a0>] (dpm_resume_end+0x1c/0x28) from [<8006c42c>] > (suspend_devices_and_enter+0x1e8/0x3f8) > [<8006c42c>] (suspend_devices_and_enter+0x1e8/0x3f8) from [<8006c818>] > (pm_suspend+0x1dc/0x23c) > [<8006c818>] (pm_suspend+0x1dc/0x23c) from [<8006b458>] > (state_store+0xa4/0x134) > [<8006b458>] (state_store+0xa4/0x134) from [<802fbbec>] > (kobj_attr_store+0x20/0x24) > [<802fbbec>] (kobj_attr_store+0x20/0x24) from [<8016eba4>] > (sysfs_write_file+0x10c/0x18c) > [<8016eba4>] (sysfs_write_file+0x10c/0x18c) from [<80104954>] > (vfs_write+0xd4/0x1a0) > [<80104954>] (vfs_write+0xd4/0x1a0) from [<80104b0c>] (SyS_write+0x54/0x80) > [<80104b0c>] (SyS_write+0x54/0x80) from [<80015100>] > (ret_fast_syscall+0x0/0x30) > Code: 0a0e e1a02005 e593e004 e1a3 (e58e2000) > ---[ end trace 3c4123f3f7d5e19e ]--- > > thanks, > Pengcheng Li > > -邮件原件- > 发件人: gre...@linuxfoundation.org [mailto:gre...@linuxfoundation.org] > 发送时间: 2016年3月22日 10:28 > 收件人: Lipengcheng > 抄送: mathias.ny...@intel.com; st...@rowland.harvard.edu; ba...@ti.com; > chasemetzge...@gmail.com; baolu...@linux.intel.com; mj...@coreos.com; > kbo...@gmail.com; jun...@freescale.com; robert.schlabb...@gmx.net; > linux-usb@vger.kernel.org > 主题: Re: 【xhci】suspend and resume core dump problem > > On Tue, Mar 22, 2016 at 01:31:40AM +, 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_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), , >> -GFP_KERNEL); >> +GFP_ATOMIC); >> Modify 2: >> xhci->erst.entries = dma_alloc_coherent(dev, >> sizeof(struct xhci_erst_entry) * ERST_NUM_SEGS, , >> -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
Re: 【xhci】suspend and resume core dump problem
On Tue, Mar 22, 2016 at 01:31:40AM +, 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_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), , > - GFP_KERNEL); > + GFP_ATOMIC); > Modify 2: > xhci->erst.entries = dma_alloc_coherent(dev, > sizeof(struct xhci_erst_entry) * ERST_NUM_SEGS, , > - 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
