amdgpu driver floods system log

[Fernseher]

I have now upgraded to a 4.13. kernel and run the open source amdgpu driver (NOT pro).

However, when running dmesg my system log gets flooded with this messages:

status: c
[   93.614393] switching to power state:
[   93.614394]  ui class: performance
[   93.614394]  internal class: none
[   93.614395]  caps:
[   93.614396]  uvd    vclk: 0 dclk: 0
[   93.614397]          power level 0    sclk: 30000 mclk: 15000 pcie gen: 2 pcie lanes: 16
[   93.614398]          power level 1    sclk: 107000 mclk: 162500 pcie gen: 2 pcie lanes: 16
[   93.614398]  status: r
[   93.614445] switching from power state:
[   93.614445]  ui class: performance
[   93.614446]  internal class: none
[   93.614448]  caps:
[   93.614449]  uvd    vclk: 0 dclk: 0
[   93.614450]          power level 0    sclk: 30000 mclk: 15000 pcie gen: 2 pcie lanes: 16
[   93.614451]          power level 1    sclk: 107000 mclk: 162500 pcie gen: 2 pcie lanes: 16
[   93.614452]  status: c
[   93.614454] switching to power state:
[   93.614455]  ui class: performance
[   93.614455]  internal class: none
[   93.614456]  caps:
[   93.614458]  uvd    vclk: 0 dclk: 0
[   93.614458]          power level 0    sclk: 30000 mclk: 15000 pcie gen: 2 pcie lanes: 16
[   93.614459]          power level 1    sclk: 107000 mclk: 162500 pcie gen: 2 pcie lanes: 16

Is there a way to stop these messages?
Thanks!

[Fernseher]

Do not use mainline kernels, the have partially implemented amdgpu and radeon drivers(...)

If there are people who do continuesly heavy work on the graphics stack, they may be more up to date, but does that really mean, the mainline stack is "incomplete"?

Amd, where is my salary?

Why not kindly ask them, maybe they give you a RX580 or something they have around in the shelf ;-) If your forum activities really promotes the use of AMD GPUs I could imagine they might really do this. Who knows.

Back to my question.
I have used the amdgpu.dpm=1 parameter when I had these tons of messages. Now after having that parameter removed, these messages are gone!
It seems power management still does work without that parameter. I dunno why I used that all the time......

[bridgman]

When you compare logs of kernel.org kernels and Alex wip kernels, you see that Amd posts very few and random patches to the mainline kernel. I tested kernel 4.12 that is the default kernel in Debian testing, I had tons of error messages from the amdgpu driver in dmesg at boot. Then I made my custom kernel package from Alex 4.15 wip kernel and everything is fine.

debianxfce, please stop saying this or show me why you believe it is true.

Essentially all of the patches going into staging branches (other than the display/DAL/DC code which has not yet been accepted upstream) also go into the mainline kernel. The difference is that patches arrive continuously in the staging branches, while for upstream we follow the kernel development cycle where big changes go in during the merge window via Dave's drm-next while bug fixes go up more-or-less continuously via drm-fixes.

[bridgman]

Read the logs and compare. it takes months to get bug fixes via mainline kernels. Amd could put all Alex wip patches to mainline rc versions. Amd could hire me to improve amdgpu development cycles and documentation. Feel free to contact.

Ahh, I understand what you're thinking.... but no, the changes which do not go into mainline RC versions (and instead are saved up for the next merge window) do not go in because they would not be accepted. The kernel development cycle is a 2 week merge window for new stuff plus (typically) 7 weeks when only bug fixes are accepted.

If you look in agd5f's repo you will see drm-next-* and drm-fixes-* branches, which correspond to airlied's drm-next and drm-fixes trees. Bug fixes go into drm-fixes, everything else saved (for up to 2 months) in drm-next for the next merge window.

Other than things like display/DC/DAL everything in amd-staging* normally ends up in either drm-next* or drm-fixes*, although pushing to drm-next generally happens in large pull requests later in the kernel cycle. If you do check the logs though I think you will find that everything in staging ends up in -next or -fixes before the window for each one closes.

As each subsequent rc passes the bar for submitting even bug fixes goes up, with only the most urgent bug fixes expected in later RC's.

[agd5f]

Back to my question.
I have used the amdgpu.dpm=1 parameter when I had these tons of messages. Now after having that parameter removed, these messages are gone!
It seems power management still does work without that parameter. I dunno why I used that all the time......

Adding dpm=1 just adds additional debugging output. dpm is enabled by default (and doesn't spam the logs). dpm=1 adds debugging output because we used that for option for new asic bring up before dpm was stable in which case we want additional debugging output.