https://bugs.freedesktop.org/show_bug.cgi?id=82201
Michel Dänzer changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=82201
--- Comment #51 from Sebastian Parborg ---
Hmm, seems like it detects the correct max clock...
switching from power state:
ui class: performance
internal class: none
caps:
uvdvclk: 0 dclk: 0
power level 0sclk:
https://bugs.freedesktop.org/show_bug.cgi?id=82201
--- Comment #50 from Alex Deucher ---
(In reply to Sebastian Parborg from comment #49)
>
> Where can I check the levels that "high" is supposed to clock to?
It will be reflected in radeon_pm_info in debugfs if it worked. You can see
https://bugs.freedesktop.org/show_bug.cgi?id=82201
--- Comment #49 from Sebastian Parborg ---
Alex, first I got:
bash: echo: write error: Invalid argument
But then after I tried to pass it some more times it worked :S
Anyways with "high" it still only clocks up the mem clock.
# echo high >
https://bugs.freedesktop.org/show_bug.cgi?id=82201
--- Comment #48 from Alex Deucher ---
(In reply to Sebastian Parborg from comment #46)
> It doesn't seem to be completely solved for me sadly.
> I'm using: http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-3.19-wip
>
> It is a lot better
https://bugs.freedesktop.org/show_bug.cgi?id=82201
--- Comment #47 from Kai ---
(In reply to Sebastian Parborg from comment #46)
> Kai, can you see if this is also the case for you?
Nope, works for me, as I reported in comment #45. In Unigine Heaven I get t
2560Ã1440 (Renderer: OpenGL, Mode:
https://bugs.freedesktop.org/show_bug.cgi?id=82201
Sebastian Parborg changed:
What|Removed |Added
Status|RESOLVED|REOPENED
CC|
https://bugs.freedesktop.org/show_bug.cgi?id=82201
Kai changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=82201
--- Comment #44 from Alex Deucher ---
Do my 3.19-wip or 3.19-next kernel branches help?
http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-3.19-wip
http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-3.19
--
You are receiving this
https://bugs.freedesktop.org/show_bug.cgi?id=82201
--- Comment #43 from Alex Deucher ---
(In reply to Sebastian Parborg from comment #42)
> I also get the "Invalid ROM contents" message btw.
This message is harmless and can be ignored. It's due to a change in the pci
subsystem rom fetching
https://bugs.freedesktop.org/show_bug.cgi?id=82201
--- Comment #42 from Sebastian Parborg ---
I also get the "Invalid ROM contents" message btw.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
https://bugs.freedesktop.org/show_bug.cgi?id=82201
--- Comment #41 from Sebastian Parborg ---
For me, it first stated happening when I updated mesa. But now it seems to
happen at random.
BTW I have managed to get the GPU to reclock again by booting with fglrx and
running Unigine Heaven till I
https://bugs.freedesktop.org/show_bug.cgi?id=82201
--- Comment #40 from Kai ---
(In reply to Sebastian Parborg from comment #38)
> However I do not have windows installed at all. So I think we can rule that
> one out.
>
> For me it seem like the card loses the ability to reclock after a while.
https://bugs.freedesktop.org/show_bug.cgi?id=82201
--- Comment #39 from Sebastian Parborg ---
I take the fglrx stuff back. Seems like I were lucky the times that it
worked...
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An
https://bugs.freedesktop.org/show_bug.cgi?id=82201
--- Comment #38 from Sebastian Parborg ---
Kai, I have an 290x and I'm having the same problem as you.
However I do not have windows installed at all. So I think we can rule that one
out.
For me it seem like the card loses the ability to
https://bugs.freedesktop.org/show_bug.cgi?id=82201
--- Comment #37 from Kai ---
(In reply to Christian K?nig from comment #36)
> Ah! Ok that's something different. As long as the system was completely off
> (defined by no power to the GPU) there shouldn't be any influence from the
> previously
https://bugs.freedesktop.org/show_bug.cgi?id=82201
--- Comment #36 from Christian K?nig ---
(In reply to Kai from comment #35)
> (In reply to Christian K?nig from comment #34)
> > (In reply to Kai from comment #33)
> > > And I have non-reclocking GPU again.
> > > Is there any data I can provide,
https://bugs.freedesktop.org/show_bug.cgi?id=82201
--- Comment #35 from Kai ---
(In reply to Christian K?nig from comment #34)
> (In reply to Kai from comment #33)
> > And I have non-reclocking GPU again.
> > Is there any data I can provide, that would help you tracking down, what
> > Windows is
https://bugs.freedesktop.org/show_bug.cgi?id=82201
--- Comment #34 from Christian K?nig ---
(In reply to Kai from comment #33)
> And I have non-reclocking GPU again.
> Is there any data I can provide, that would help you tracking down, what
> Windows is setting, that is preventing proper
https://bugs.freedesktop.org/show_bug.cgi?id=82201
Kai changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|WORKSFORME
https://bugs.freedesktop.org/show_bug.cgi?id=82201
Kai changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=82201
--- Comment #31 from Chernovsky Oleg ---
(In reply to comment #30)
> auto, high, and low are the valid options. You are getting an error because
> the hw rejected your request.
it has such behaviour because of `thermal_active` check in
https://bugs.freedesktop.org/show_bug.cgi?id=82201
--- Comment #30 from Alex Deucher ---
(In reply to comment #29)
> # echo "auto" >
> /sys/class/drm/card0/device/power_dpm_force_performance_level
> bash: echo: write error: Invalid argument
>
> Not sure, what valid options would be for me.
https://bugs.freedesktop.org/show_bug.cgi?id=82201
--- Comment #29 from Kai ---
(In reply to comment #27)
> Not sure if this is useful, but DPM stopped working for me once and was
> stuck at 360MHz. I was doing some testing, Heaven had 60 fps originally and
> after I run it again later, I only
https://bugs.freedesktop.org/show_bug.cgi?id=82201
--- Comment #28 from Chernovsky Oleg ---
Did you try to "echo auto >
/sys/class/drm/card0/device/power_dpm_force_performance_level"?
It may be related to bug #79806 (Performance degradation after resume), that
should be fixed by patch I've sent
https://bugs.freedesktop.org/show_bug.cgi?id=82201
--- Comment #27 from Marek Ol??k ---
Not sure if this is useful, but DPM stopped working for me once and was stuck
at 360MHz. I was doing some testing, Heaven had 60 fps originally and after I
run it again later, I only got 18 fps. Considering
https://bugs.freedesktop.org/show_bug.cgi?id=82201
--- Comment #26 from Kai ---
After observing, that setting radeon.dpm=1 all the time doesn't guarantee a
reclocking GPU all the time, I went back to looking, what I did *exactly* in
the cases, where I got a reclocking GPU. I found, that I either
https://bugs.freedesktop.org/show_bug.cgi?id=82201
--- Comment #25 from Kai ---
(In reply to comment #24)
> (In reply to comment #23)
> > (In reply to comment #22)
> > > do you have radeon.dpm=0 in smoe /etc/modprobe.d or somewhere like that
> > > file?
> >
> > No:
> > # grep -nHr radeon.dpm
https://bugs.freedesktop.org/show_bug.cgi?id=82201
--- Comment #24 from Christian K?nig ---
(In reply to comment #23)
> (In reply to comment #22)
> > do you have radeon.dpm=0 in smoe /etc/modprobe.d or somewhere like that
> > file?
>
> No:
> # grep -nHr radeon.dpm /etc/*
>
https://bugs.freedesktop.org/show_bug.cgi?id=82201
--- Comment #23 from Kai ---
(In reply to comment #22)
> do you have radeon.dpm=0 in smoe /etc/modprobe.d or somewhere like that file?
No:
# grep -nHr radeon.dpm /etc/*
/etc/default/grub:9:GRUB_CMDLINE_LINUX_DEFAULT="quiet radeon.dpm=1"
And,
https://bugs.freedesktop.org/show_bug.cgi?id=82201
--- Comment #22 from Dave Airlie ---
do you have radeon.dpm=0 in smoe /etc/modprobe.d or somewhere like that file?
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML
https://bugs.freedesktop.org/show_bug.cgi?id=82201
--- Comment #21 from Alex Deucher ---
(In reply to comment #20)
> (In reply to comment #19)
> > Maybe we'll get more useful feedback once more people start testing hawaii.
>
> That sounds like I failed to provide something? If you have any
https://bugs.freedesktop.org/show_bug.cgi?id=82201
--- Comment #20 from Kai ---
(In reply to comment #19)
> Maybe we'll get more useful feedback once more people start testing hawaii.
That sounds like I failed to provide something? If you have any request, what I
should check, just let me know.
https://bugs.freedesktop.org/show_bug.cgi?id=82201
--- Comment #19 from Alex Deucher ---
(In reply to comment #18)
> (In reply to comment #16)
> > I don't have any other ideas off hand. That patch represents is the only
> > difference explicitly setting that parameter changes.
>
> Ok, no
https://bugs.freedesktop.org/show_bug.cgi?id=82201
--- Comment #18 from Kai ---
(In reply to comment #16)
> I don't have any other ideas off hand. That patch represents is the only
> difference explicitly setting that parameter changes.
Ok, no problem; I just keep the radeon.dpm=1 around and
https://bugs.freedesktop.org/show_bug.cgi?id=82201
--- Comment #17 from Kai ---
(In reply to comment #15)
> I booted each configuration represent by attachment 104103 and attachment
> 104104 two times.
Just to clarify: the boot and testing order was:
rebooting into configuration 104103 ?
https://bugs.freedesktop.org/show_bug.cgi?id=82201
--- Comment #16 from Alex Deucher ---
I don't have any other ideas off hand. That patch represents is the only
difference explicitly setting that parameter changes.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=82201
--- Comment #15 from Kai ---
(In reply to comment #11)
> Created attachment 104101 [details] [review]
> enable dpm=1 debugging even when dpm is not forced
>
> This patch enables the additional dpm debugging output even when it is not
>
https://bugs.freedesktop.org/show_bug.cgi?id=82201
--- Comment #14 from Alex Deucher ---
Did it help? With the patch applied, the behavior of the driver is identical
whether or not you append radeon.dpm=1 to your kernel command line.
--
You are receiving this mail because:
You are the
https://bugs.freedesktop.org/show_bug.cgi?id=82201
--- Comment #13 from Kai ---
Created attachment 104104
--> https://bugs.freedesktop.org/attachment.cgi?id=104104=edit
dmesg output with attachment 104101 and "radeon.dpm=1" set
--
You are receiving this mail because:
You are the assignee for
https://bugs.freedesktop.org/show_bug.cgi?id=82201
--- Comment #12 from Kai ---
Created attachment 104103
--> https://bugs.freedesktop.org/attachment.cgi?id=104103=edit
dmesg output with attachment 104101 and no "radeon.dpm=1" set
--
You are receiving this mail because:
You are the assignee
https://bugs.freedesktop.org/show_bug.cgi?id=82201
--- Comment #11 from Alex Deucher ---
Created attachment 104101
--> https://bugs.freedesktop.org/attachment.cgi?id=104101=edit
enable dpm=1 debugging even when dpm is not forced
This patch enables the additional dpm debugging output even when
https://bugs.freedesktop.org/show_bug.cgi?id=82201
--- Comment #10 from Kai ---
(In reply to comment #8)
> dpm is enabled by default for hawaii asics. You shouldn't need to force it
> on the command line. forcing it just enabled additional debugging output.
I can only state, that by setting
https://bugs.freedesktop.org/show_bug.cgi?id=82201
--- Comment #9 from Kai ---
(In reply to comment #7)
> Are(In reply to comment #6)
> > Now for your glxgears test: reclocking works (in Portal 2 as well, where I
> > get 58-60 FPS now). The only difference is the radeon.dpm=1 on the kernel
> >
https://bugs.freedesktop.org/show_bug.cgi?id=82201
--- Comment #8 from Alex Deucher ---
dpm is enabled by default for hawaii asics. You shouldn't need to force it on
the command line. forcing it just enabled additional debugging output.
--
You are receiving this mail because:
You are the
https://bugs.freedesktop.org/show_bug.cgi?id=82201
--- Comment #7 from Luzipher ---
Are(In reply to comment #6)
> Now for your glxgears test: reclocking works (in Portal 2 as well, where I
> get 58-60 FPS now). The only difference is the radeon.dpm=1 on the kernel
> command line.
Are you
https://bugs.freedesktop.org/show_bug.cgi?id=82201
--- Comment #6 from Kai ---
(In reply to comment #5)
> Are you checking radeon_pm_info while the app is running? E.g., via ssh or
> via another X terminal? If you switch to another VT or something like that
> there will not be any activity.
https://bugs.freedesktop.org/show_bug.cgi?id=82201
--- Comment #5 from Alex Deucher ---
Are you checking radeon_pm_info while the app is running? E.g., via ssh or via
another X terminal? If you switch to another VT or something like that there
will not be any activity. Can you try is with
https://bugs.freedesktop.org/show_bug.cgi?id=82201
--- Comment #4 from Kai ---
Created attachment 104094
--> https://bugs.freedesktop.org/attachment.cgi?id=104094=edit
dmesg with radeon.dpm=1 set
Here you go. The last power state entry in dmesg is:
> switching from power state:
> ui class:
https://bugs.freedesktop.org/show_bug.cgi?id=82201
Kai changed:
What|Removed |Added
Attachment #104081|VBIOS from |VBIOS from XFX R9-290A-EDBD
description|
https://bugs.freedesktop.org/show_bug.cgi?id=82201
--- Comment #3 from Kai ---
Created attachment 104081
--> https://bugs.freedesktop.org/attachment.cgi?id=104081=edit
VBIOS from
(In reply to comment #2)
> Please attach your dmesg output with radeon.dpm=1 set on the kernel command
> line in
https://bugs.freedesktop.org/show_bug.cgi?id=82201
--- Comment #2 from Alex Deucher ---
Please attach your dmesg output with radeon.dpm=1 set on the kernel command
line in grub. That dumps some additional debugging output. Also please attach
a copy of your vbios.
(as root)
(use lspci to get
https://bugs.freedesktop.org/show_bug.cgi?id=82201
--- Comment #1 from Kai ---
Since the image was a bit too large, I can't attach it here. You can find the
screenshot at at http://imgur.com/vFBfQpQ
--
You are receiving this mail because:
You are the assignee for the bug.
-- next
53 matches
Mail list logo
