From: Greg KH <gregkh@linuxfoundation.org> To: Abhinav Kumar <quic_abhinavk@quicinc.com> Cc: johannes@sipsolutions.net, linux-kernel@vger.kernel.org, rafael@kernel.org, robdclark@gmail.com, dri-devel@lists.freedesktop.org, linux-arm-msm@vger.kernel.org, freedreno@lists.freedesktop.org, seanpaul@chromium.org, swboyd@chromium.org, nganji@codeaurora.org, aravindh@codeaurora.org, khsieh@codeaurora.org, daniel@ffwll.ch, dmitry.baryshkov@linaro.org Subject: Re: [PATCH] devcoredump: increase the device delete timeout to 10 mins Date: Fri, 11 Feb 2022 12:09:38 +0100 [thread overview] Message-ID: <YgZD8vPqB7ISpRpZ@kroah.com> (raw) In-Reply-To: <1644349472-31077-1-git-send-email-quic_abhinavk@quicinc.com> On Tue, Feb 08, 2022 at 11:44:32AM -0800, Abhinav Kumar wrote: > There are cases where depending on the size of the devcoredump and the speed > at which the usermode reads the dump, it can take longer than the current 5 mins > timeout. > > This can lead to incomplete dumps as the device is deleted once the timeout expires. > > One example is below where it took 6 mins for the devcoredump to be completely read. > > 04:22:24.668 23916 23994 I HWDeviceDRM::DumpDebugData: Opening /sys/class/devcoredump/devcd6/data > 04:28:35.377 23916 23994 W HWDeviceDRM::DumpDebugData: Freeing devcoredump node What makes this so slow? Reading from the kernel shouldn't be the limit, is it where the data is being sent to? > Increase the timeout to 10 mins to accommodate system delays and large coredump > sizes. Nit, please wrap your changelog texts at 72 columns. And what is "large"? thanks, greg k-h
WARNING: multiple messages have this Message-ID (diff)
From: Greg KH <gregkh@linuxfoundation.org> To: Abhinav Kumar <quic_abhinavk@quicinc.com> Cc: rafael@kernel.org, linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, swboyd@chromium.org, khsieh@codeaurora.org, nganji@codeaurora.org, seanpaul@chromium.org, dmitry.baryshkov@linaro.org, johannes@sipsolutions.net, aravindh@codeaurora.org, freedreno@lists.freedesktop.org Subject: Re: [PATCH] devcoredump: increase the device delete timeout to 10 mins Date: Fri, 11 Feb 2022 12:09:38 +0100 [thread overview] Message-ID: <YgZD8vPqB7ISpRpZ@kroah.com> (raw) In-Reply-To: <1644349472-31077-1-git-send-email-quic_abhinavk@quicinc.com> On Tue, Feb 08, 2022 at 11:44:32AM -0800, Abhinav Kumar wrote: > There are cases where depending on the size of the devcoredump and the speed > at which the usermode reads the dump, it can take longer than the current 5 mins > timeout. > > This can lead to incomplete dumps as the device is deleted once the timeout expires. > > One example is below where it took 6 mins for the devcoredump to be completely read. > > 04:22:24.668 23916 23994 I HWDeviceDRM::DumpDebugData: Opening /sys/class/devcoredump/devcd6/data > 04:28:35.377 23916 23994 W HWDeviceDRM::DumpDebugData: Freeing devcoredump node What makes this so slow? Reading from the kernel shouldn't be the limit, is it where the data is being sent to? > Increase the timeout to 10 mins to accommodate system delays and large coredump > sizes. Nit, please wrap your changelog texts at 72 columns. And what is "large"? thanks, greg k-h
next prev parent reply other threads:[~2022-02-11 11:09 UTC|newest] Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-02-08 19:44 [PATCH] devcoredump: increase the device delete timeout to 10 mins Abhinav Kumar 2022-02-08 19:44 ` Abhinav Kumar 2022-02-08 20:35 ` Johannes Berg 2022-02-08 20:35 ` Johannes Berg 2022-02-08 21:04 ` Abhinav Kumar 2022-02-08 21:04 ` Abhinav Kumar 2022-02-08 21:12 ` Johannes Berg 2022-02-08 21:12 ` Johannes Berg 2022-02-08 21:40 ` Abhinav Kumar 2022-02-08 21:40 ` Abhinav Kumar 2022-02-08 21:54 ` Johannes Berg 2022-02-09 1:55 ` Abhinav Kumar 2022-02-09 1:55 ` Abhinav Kumar 2022-02-09 7:50 ` Johannes Berg 2022-02-09 16:29 ` Abhinav Kumar 2022-02-09 16:29 ` Abhinav Kumar 2022-02-11 11:09 ` Greg KH 2022-02-11 11:09 ` Greg KH 2022-02-11 11:09 ` Greg KH [this message] 2022-02-11 11:09 ` Greg KH 2022-02-11 18:59 ` Abhinav Kumar 2022-02-11 18:59 ` Abhinav Kumar 2022-02-12 7:04 ` Greg KH 2022-02-12 7:04 ` Greg KH 2022-02-12 7:52 ` Abhinav Kumar 2022-02-12 7:52 ` Abhinav Kumar 2022-02-12 8:24 ` Johannes Berg 2022-02-12 8:24 ` Johannes Berg 2022-02-12 8:35 ` Abhinav Kumar 2022-02-12 8:35 ` Abhinav Kumar 2022-02-28 21:38 ` Abhinav Kumar 2022-02-28 21:38 ` Abhinav Kumar 2022-03-01 6:48 ` David Laight 2022-03-01 17:45 ` Rob Clark 2022-03-01 17:45 ` Rob Clark 2022-03-11 11:53 ` Johannes Berg 2022-03-11 11:53 ` Johannes Berg 2022-02-12 8:29 ` Greg KH 2022-02-12 8:29 ` Greg KH 2022-02-12 8:33 ` Abhinav Kumar 2022-02-12 8:33 ` Abhinav Kumar
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=YgZD8vPqB7ISpRpZ@kroah.com \ --to=gregkh@linuxfoundation.org \ --cc=aravindh@codeaurora.org \ --cc=daniel@ffwll.ch \ --cc=dmitry.baryshkov@linaro.org \ --cc=dri-devel@lists.freedesktop.org \ --cc=freedreno@lists.freedesktop.org \ --cc=johannes@sipsolutions.net \ --cc=khsieh@codeaurora.org \ --cc=linux-arm-msm@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=nganji@codeaurora.org \ --cc=quic_abhinavk@quicinc.com \ --cc=rafael@kernel.org \ --cc=robdclark@gmail.com \ --cc=seanpaul@chromium.org \ --cc=swboyd@chromium.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.