Re: [PATCH] drm/amd/powerplay/smu7_hwmgr: replace blocking delay with non-blocking
On Thu, Jul 4, 2019 at 4:15 PM Yrjan Skrimstad wrote: > > On Sun, Jun 16, 2019 at 04:43:10PM +0200, Yrjan Skrimstad wrote: > > That is an interesting observation to me. I am actually running > > lm-sensors, although only every 15 seconds. I suppose that this might > > be the reason this happens to me. > > Though I don't think this should reasonably cause problems with the > system, even if it does here. Is there an update on the status of this > patch? Applied. sorry for the delay. Alex
Re: [PATCH] drm/amd/powerplay/smu7_hwmgr: replace blocking delay with non-blocking
On Sun, Jun 16, 2019 at 04:43:10PM +0200, Yrjan Skrimstad wrote: > That is an interesting observation to me. I am actually running > lm-sensors, although only every 15 seconds. I suppose that this might > be the reason this happens to me. Though I don't think this should reasonably cause problems with the system, even if it does here. Is there an update on the status of this patch? - Yrjan
Re: [PATCH] drm/amd/powerplay/smu7_hwmgr: replace blocking delay with non-blocking
On Thu, Jun 13, 2019 at 09:57:24AM -0400, Alex Deucher wrote: > The patch is fine and I can apply it (I don't think there are any > restrictions on sleeping in sysfs), but this code only gets executed > when you actually read the power status from the card (e.g., via sysfs > or debugfs). Presumably you have something in userspace polling one > of those files on a regular basis? > > Alex That is an interesting observation to me. I am actually running lm-sensors, although only every 15 seconds. I suppose that this might be the reason this happens to me. - Yrjan
Re: [PATCH] drm/amd/powerplay/smu7_hwmgr: replace blocking delay with non-blocking
On Tue, Jun 4, 2019 at 4:22 PM Yrjan Skrimstad wrote: > > On Thu, May 30, 2019 at 02:08:21AM +0200, Yrjan Skrimstad wrote: > > This driver currently contains a repeated 500ms blocking delay call > > which causes frequent major buffer underruns in PulseAudio. This patch > > fixes this issue by replacing the blocking delay with a non-blocking > > sleep call. > > I see that I have not explained this bug well enough, and I hope that is > the reason for the lack of replies on this patch. I will here attempt to > explain the situation better. > > To start with some hardware description I am here using an AMD R9 380 > GPU, an AMD Ryzen 7 1700 Eight-Core Processor and an AMD X370 chipset. > If any more hardware or software specifications are necessary, please > ask. > > The bug is as follows: When playing audio I will regularly have major > audio issues, similar to that of a skipping CD. This is reported by > PulseAudio as scheduling delays and buffer underruns when running > PulseAudio verbosely and these scheduling delays are always just under > 500ms, typically around 490ms. This makes listening to any music quite > the horrible experience as PulseAudio constantly will attempt to rewind > and catch up. It is not a great situation, and seems to me to quite > clearly be a case where regular user space behaviour has been broken. > > I want to note that this audio problem was not something I experienced > until recently, it is therefore a new bug. > > I have bisected the kernel to find out where the problem originated and > found the following commit: > > # first bad commit: [f5742ec36422a39b57f0256e4847f61b3c432f8c] > drm/amd/powerplay: correct power reading on fiji > > This commit introduces a blocking delay (mdelay) of 500ms, whereas the > old behaviour was a smaller blocking delay of only 1ms. This seems to me > to be very curious as the scheduling delays of PulseAudio are always > almost 500ms. I have therefore with the previous patch replaced the > scheduling delay with a non-blocking sleep (msleep). > > The results of the patch seems promising as I have yet to encounter any > of the old <500ms scheduling delays when using it and I have also not > encountered any kernel log messages regarding sleeping in an atomic > context. The patch is fine and I can apply it (I don't think there are any restrictions on sleeping in sysfs), but this code only gets executed when you actually read the power status from the card (e.g., via sysfs or debugfs). Presumably you have something in userspace polling one of those files on a regular basis? Alex ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amd/powerplay/smu7_hwmgr: replace blocking delay with non-blocking
CC trimmed Hello Alex and Harry, any comments on this? I'm running my Xeon X3470 (4c/8t) with this under amd-staging-drm-next (as always ;-) ) and see no issues so far. Thanks! Dieter Am 04.06.2019 22:21, schrieb Yrjan Skrimstad: On Thu, May 30, 2019 at 02:08:21AM +0200, Yrjan Skrimstad wrote: This driver currently contains a repeated 500ms blocking delay call which causes frequent major buffer underruns in PulseAudio. This patch fixes this issue by replacing the blocking delay with a non-blocking sleep call. I see that I have not explained this bug well enough, and I hope that is the reason for the lack of replies on this patch. I will here attempt to explain the situation better. To start with some hardware description I am here using an AMD R9 380 GPU, an AMD Ryzen 7 1700 Eight-Core Processor and an AMD X370 chipset. If any more hardware or software specifications are necessary, please ask. The bug is as follows: When playing audio I will regularly have major audio issues, similar to that of a skipping CD. This is reported by PulseAudio as scheduling delays and buffer underruns when running PulseAudio verbosely and these scheduling delays are always just under 500ms, typically around 490ms. This makes listening to any music quite the horrible experience as PulseAudio constantly will attempt to rewind and catch up. It is not a great situation, and seems to me to quite clearly be a case where regular user space behaviour has been broken. I want to note that this audio problem was not something I experienced until recently, it is therefore a new bug. I have bisected the kernel to find out where the problem originated and found the following commit: # first bad commit: [f5742ec36422a39b57f0256e4847f61b3c432f8c] drm/amd/powerplay: correct power reading on fiji This commit introduces a blocking delay (mdelay) of 500ms, whereas the old behaviour was a smaller blocking delay of only 1ms. This seems to me to be very curious as the scheduling delays of PulseAudio are always almost 500ms. I have therefore with the previous patch replaced the scheduling delay with a non-blocking sleep (msleep). The results of the patch seems promising as I have yet to encounter any of the old <500ms scheduling delays when using it and I have also not encountered any kernel log messages regarding sleeping in an atomic context. ___ dri-devel mailing list dri-de...@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amd/powerplay/smu7_hwmgr: replace blocking delay with non-blocking
On Thu, May 30, 2019 at 02:08:21AM +0200, Yrjan Skrimstad wrote: > This driver currently contains a repeated 500ms blocking delay call > which causes frequent major buffer underruns in PulseAudio. This patch > fixes this issue by replacing the blocking delay with a non-blocking > sleep call. I see that I have not explained this bug well enough, and I hope that is the reason for the lack of replies on this patch. I will here attempt to explain the situation better. To start with some hardware description I am here using an AMD R9 380 GPU, an AMD Ryzen 7 1700 Eight-Core Processor and an AMD X370 chipset. If any more hardware or software specifications are necessary, please ask. The bug is as follows: When playing audio I will regularly have major audio issues, similar to that of a skipping CD. This is reported by PulseAudio as scheduling delays and buffer underruns when running PulseAudio verbosely and these scheduling delays are always just under 500ms, typically around 490ms. This makes listening to any music quite the horrible experience as PulseAudio constantly will attempt to rewind and catch up. It is not a great situation, and seems to me to quite clearly be a case where regular user space behaviour has been broken. I want to note that this audio problem was not something I experienced until recently, it is therefore a new bug. I have bisected the kernel to find out where the problem originated and found the following commit: # first bad commit: [f5742ec36422a39b57f0256e4847f61b3c432f8c] drm/amd/powerplay: correct power reading on fiji This commit introduces a blocking delay (mdelay) of 500ms, whereas the old behaviour was a smaller blocking delay of only 1ms. This seems to me to be very curious as the scheduling delays of PulseAudio are always almost 500ms. I have therefore with the previous patch replaced the scheduling delay with a non-blocking sleep (msleep). The results of the patch seems promising as I have yet to encounter any of the old <500ms scheduling delays when using it and I have also not encountered any kernel log messages regarding sleeping in an atomic context. ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH] drm/amd/powerplay/smu7_hwmgr: replace blocking delay with non-blocking
This driver currently contains a repeated 500ms blocking delay call
which causes frequent major buffer underruns in PulseAudio. This patch
fixes this issue by replacing the blocking delay with a non-blocking
sleep call.
Signed-off-by: Yrjan Skrimstad
---
drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
index 048757e8f494..340afdbddc72 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
@@ -3494,7 +3494,7 @@ static int smu7_get_gpu_power(struct pp_hwmgr *hwmgr, u32
*query)
ixSMU_PM_STATUS_95, 0);
for (i = 0; i < 10; i++) {
- mdelay(500);
+ msleep(500);
smum_send_msg_to_smc(hwmgr, PPSMC_MSG_PmStatusLogSample);
tmp = cgs_read_ind_register(hwmgr->device,
CGS_IND_REG__SMC,
--
2.20.1
