[Bug 201763] amdgpu: [powerplay] VBIOS did not find boot engine clock value in dependency table. Using Memory DPM level 0!
bugzilla-daemon at bugzilla.kernel.org
bugzilla-daemon at bugzilla.kernel.org
Thu Feb 28 22:31:19 UTC 2019
https://bugzilla.kernel.org/show_bug.cgi?id=201763
--- Comment #5 from Rogério Brito (rbrito at ime.usp.br) ---
Dear Michel,
First of all, sorry for the late reply. I had really a really bad start of the
year (death in family, complications caused by that, health problems, fire at
home and also recovering from that hard hit etc.)
So, I'm really sorry for the late reply.
(In reply to Michel Dänzer from comment #2)
> From the dmesg output, it looks like the AMD GPU is powered off most of the
> time. Do the freezes happen when you explicitly use it for something, e.g.
> for a game via DRI_PRIME=1?
I never play games (really, the only game that I played in the last few years
was 2048 on a browser), but I guess that other applications may use the
discrete AMD GPU that this notebook has.
I just set the DRI_PRIME variable now in my .bash_profile file and I will
observe if I still get the lock ups. OTOH, while opening terminal sessions (I
live by them), I just observed the following in my dmesg logs:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
[ 4335.591693] [drm] PCIE GART of 256M enabled (table at 0x000000F400000000).
[ 4335.594671] amdgpu: [powerplay] can't get the mac of 5
[ 4335.595690] amdgpu: [powerplay] VBIOS did not find boot engine clock value
in dependency table. Using Memory DPM level 0!
[ 4341.181479] amdgpu: [powerplay] VI should always have 2 performance levels
[ 4341.231068] amdgpu 0000:04:00.0: GPU pci config reset
[ 4433.700699] [drm] PCIE GART of 256M enabled (table at 0x000000F400000000).
[ 4433.705976] amdgpu: [powerplay] can't get the mac of 5
[ 4433.707025] amdgpu: [powerplay] VBIOS did not find boot engine clock value
in dependency table. Using Memory DPM level 0!
[ 4439.230380] amdgpu: [powerplay] VI should always have 2 performance levels
[ 4439.276205] amdgpu 0000:04:00.0: GPU pci config reset
[ 4843.838487] [drm] PCIE GART of 256M enabled (table at 0x000000F400000000).
[ 4843.842649] amdgpu: [powerplay] can't get the mac of 5
[ 4843.844046] amdgpu: [powerplay] VBIOS did not find boot engine clock value
in dependency table. Using Memory DPM level 0!
[ 4849.072890] amdgpu: [powerplay] VI should always have 2 performance levels
[ 4849.121352] amdgpu 0000:04:00.0: GPU pci config reset
[ 4954.354975] [drm] PCIE GART of 256M enabled (table at 0x000000F400000000).
[ 4954.358935] amdgpu: [powerplay] can't get the mac of 5
[ 4954.360287] amdgpu: [powerplay] VBIOS did not find boot engine clock value
in dependency table. Using Memory DPM level 0!
[ 4960.173664] amdgpu: [powerplay] VI should always have 2 performance levels
[ 4960.219082] amdgpu 0000:04:00.0: GPU pci config reset
[ 4982.871619] [drm] PCIE GART of 256M enabled (table at 0x000000F400000000).
[ 4982.874760] amdgpu: [powerplay] can't get the mac of 5
[ 4982.875794] amdgpu: [powerplay] VBIOS did not find boot engine clock value
in dependency table. Using Memory DPM level 0!
[ 4988.077968] amdgpu: [powerplay] VI should always have 2 performance levels
[ 4988.126289] amdgpu 0000:04:00.0: GPU pci config reset
[ 5023.317917] [drm] PCIE GART of 256M enabled (table at 0x000000F400000000).
[ 5023.321614] amdgpu: [powerplay] can't get the mac of 5
[ 5023.322918] amdgpu: [powerplay] VBIOS did not find boot engine clock value
in dependency table. Using Memory DPM level 0!
[ 5029.036045] amdgpu: [powerplay] VI should always have 2 performance levels
[ 5029.081469] amdgpu 0000:04:00.0: GPU pci config reset
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
I'm using, as you may expect, Debian's testing distribution (I can give you the
precise details), upgraded almost daily (when I am not up-to-date, I am 1 or 2
days late due to weekends, when I have to take care of my son).
I observed a few details more with respect to the bug:
1 - The problem of freezes has always occurred when I am using the GUI and
clicking or typing something. It is my (wild) guess that the problem occurs
when many interrupts happen, but I have no way to prove it.
I have not yet seen the freezes when I leave the computer running scripts to
perform some long job (say, reencoding some lecture videos that I get from
youtube to make them smaller) with ffmpeg, even if it takes many days on
uninterrupted computation (and heat being generated).
OTOH, if I am interacting with it with a mouse intensely (say, with a
program like scantailor or some other programs), switching windows or editing
some texts in Emacs, then I get freezes in just a few hours (say, 3 or 4
hours).
In fact, I hope that it doesn't occur during me typing this report (crossing
fingers and copying the contents to Emacs to save it and paste the contents in
case it freezes).
2 - The problem isn't detected by Dell's builtin UEFI application of system
diagnostic (as I said, it seems to happen when I interact with the computer and
the screen is being constantly updated).
3 - I discovered that whatever bug this is, it actually doesn't *completely*
freeze the computer, since at least the sound card keeps playing sound in a
loop (not that I intend to, but probably the samples that are already in the
sound card memory).
I recorded a few (short) videos of the problem that I see and I uploaded them
to YouTube:
* https://www.youtube.com/watch?v=6o7Fl8kqtwg
* https://www.youtube.com/watch?v=6o7Fl8kqtwg
* https://www.youtube.com/watch?v=9zPluvySdIM
If you have any idea, please let me know.
Even if the freezes have nothing to do with the video card, I would like to
have the messages (which, as you mention, may be indicative of something) of
the GPU being fixed (in the hopes that it fixes things for other users that may
not have the initiative of filing something to able developers).
As a last resort, I may end up selling this computer (even though the money
will not be sufficient to buy one with similar specs). :-(
Thanks,
Rogério Brito.
--
You are receiving this mail because:
You are watching the assignee of the bug.
More information about the dri-devel
mailing list