https://bugzilla.kernel.org/show_bug.cgi?id=60523
--- Comment #77 from Steven Haigh ---
Bueller? Bueller? Bueller?
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=60523
--- Comment #76 from Steven Haigh ---
Hmmm - yet when I hit submit on this page, it pushed the GPU up a power level,
and now its stuck there again:
$ cat /sys/kernel/debug/dri/64/radeon_pm_info
uvdvclk: 0 dclk: 0
power level 2sclk: 9
https://bugzilla.kernel.org/show_bug.cgi?id=60523
--- Comment #75 from Steven Haigh ---
To get more info on this, I rebooted the system with a single screen attached:
$ cat /sys/kernel/debug/dri/64/radeon_pm_info
uvdvclk: 0 dclk: 0
power level 0sclk: 3 mclk: 3 vddc: 950 vddci:
https://bugzilla.kernel.org/show_bug.cgi?id=60523
Steven Haigh changed:
What|Removed |Added
CC||netwiz at crc.id.au
--- Comment #74 from
https://bugzilla.kernel.org/show_bug.cgi?id=60523
Mathias Anselmann changed:
What|Removed |Added
CC||mathias.anselmann at gmail.com
---
https://bugzilla.kernel.org/show_bug.cgi?id=60523
Martin Steghöfer changed:
What|Removed |Added
CC||martin at steghoefer.eu
--- Comment
https://bugzilla.kernel.org/show_bug.cgi?id=60523
--- Comment #71 from Tobias Droste ---
No changes regarding this issue in 4.1-rc4
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=60523
John K. changed:
What|Removed |Added
CC||empire at adslgr.com
--- Comment #70 from John
https://bugzilla.kernel.org/show_bug.cgi?id=60523
--- Comment #69 from Digingbil ---
Any new insights on this issue guys? Maybe fixed on some latest kernel etc?
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=60523
--- Comment #68 from Alex Deucher ---
(In reply to Mathias Tillman from comment #60)
> I've done some further tests with overriding the power state level values as
> detailed above, here are my results:
>
> The stock values are
> level 0: sclk:
https://bugzilla.kernel.org/show_bug.cgi?id=60523
--- Comment #67 from queryv+fd at gmail.com ---
Created attachment 166641
--> https://bugzilla.kernel.org/attachment.cgi?id=166641=edit
[AMD/ATI] Barts XT [Radeon HD 6870]
Reattached a second monitor recently and I'm still experiencing this as
https://bugzilla.kernel.org/show_bug.cgi?id=60523
--- Comment #66 from Mathias Tillman ---
Created attachment 159731
--> https://bugzilla.kernel.org/attachment.cgi?id=159731=edit
Advanced Micro Devices, Inc. [AMD/ATI] Barts XT [Radeon HD 6870]
Thank you for looking into this again, Alex.
--
https://bugzilla.kernel.org/show_bug.cgi?id=60523
--- Comment #65 from Tobias Droste ---
Created attachment 159721
--> https://bugzilla.kernel.org/attachment.cgi?id=159721=edit
vbios.rom [AMD/ATI] Juniper XT [Radeon HD 5770]
--
You are receiving this mail because:
You are watching the
https://bugzilla.kernel.org/show_bug.cgi?id=60523
--- Comment #64 from Alex Deucher ---
Please attach a copy of the vbios from your systems.
(as root)
(use lspci to get the bus id)
cd /sys/bus/pci/devices/
echo 1 > rom
cat rom > /tmp/vbios.rom
echo 0 > rom
--
You are receiving this mail
https://bugzilla.kernel.org/show_bug.cgi?id=60523
--- Comment #63 from Tobias Droste ---
The bug may have an ancient file date, but this is not an old bug. I'm still
seeing this with 3.18 (latest drm-fixes) and I'm glad I'm not the only one.
I also tried to add some debug outputs to see what
https://bugzilla.kernel.org/show_bug.cgi?id=60523
--- Comment #62 from Mathias Tillman ---
Sorry for bringing up an old bug, but I'm still having this problem in 3.18, so
I decided to do some further tests which made me discover some new things that
may or may not be related.
I started off by
https://bugzilla.kernel.org/show_bug.cgi?id=60523
--- Comment #61 from Tobias Droste ---
I'm currently running drm-next from that day+your patch.
It does not seem to be the same problem for me, because mlck is 12 for
every level as soon as there's a second screen and only level 2 stays
https://bugzilla.kernel.org/show_bug.cgi?id=60523
--- Comment #60 from Mathias Tillman ---
I've done some further tests with overriding the power state level values as
detailed above, here are my results:
The stock values are
level 0: sclk: 1, mclk: 3, vddc: 950, vddci: 950
level 1:
https://bugzilla.kernel.org/show_bug.cgi?id=60523
--- Comment #59 from Mathias Tillman ---
I was using the 3.15 kernel (with your patch applied manually) on my last
reply, but I just updated to the drm-fixes-3.16 branch and unfortunately there
is no difference; it still gets stuck in the highest
https://bugzilla.kernel.org/show_bug.cgi?id=60523
--- Comment #58 from Alex Deucher ---
What kernel did you try? I haven't been able to reproduce this for a while. I
just tested a bunch of boards yesterday with 3.16 and multi-head dpm worked
properly on all of them.
--
You are receiving this
https://bugzilla.kernel.org/show_bug.cgi?id=60523
--- Comment #57 from Mathias Tillman ---
No difference here either, unfortunately.
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=60523
--- Comment #56 from Tobias Droste ---
No change here
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=60523
--- Comment #55 from Alex Deucher ---
Make sure you ddx has this patch:
http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=c4ae0e2cbcc0e2ebf9f13ee92d59b5120254a1dc
Also try this kernel patch for eg/btc:
https://bugzilla.kernel.org/show_bug.cgi?id=60523
Mathias Tillman changed:
What|Removed |Added
CC||master.homer at gmail.com
--- Comment
https://bugzilla.kernel.org/show_bug.cgi?id=60523
Digingbil changed:
What|Removed |Added
CC||digingbil at gmail.com
--- Comment #53 from
https://bugzilla.kernel.org/show_bug.cgi?id=60523
Vasco Gervasi changed:
What|Removed |Added
CC||yellowhat46 at gmail.com
--- Comment #52
https://bugzilla.kernel.org/show_bug.cgi?id=60523
--- Comment #51 from Alex Belykh ---
And not here. Applying this patch on top of latest drm-next
(786a7828bc74b9b1466e83abb200b75f80f94121) resulted in the same kind of lockups
ending with reboot.
--
You are receiving this mail because:
You are
https://bugzilla.kernel.org/show_bug.cgi?id=60523
--- Comment #50 from Tobias Droste ---
Unfortunately not here.
It's still:
# echo auto > power_dpm_force_performance_level
bash: echo: write error: Invalid argument
# echo low > power_dpm_force_performance_level
bash: echo: write error: Invalid
https://bugzilla.kernel.org/show_bug.cgi?id=60523
--- Comment #49 from Alex Deucher ---
Created attachment 128311
--> https://bugzilla.kernel.org/attachment.cgi?id=128311=edit
fix
This patch fixes the issue here.
--
You are receiving this mail because:
You are watching the assignee of the
https://bugzilla.kernel.org/show_bug.cgi?id=60523
--- Comment #48 from Alex Belykh ---
Created attachment 124121
--> https://bugzilla.kernel.org/attachment.cgi?id=124121=edit
dmesg when booting up with a single monitor
attaching a second monitor at 241.8 sec.
--
You are receiving this mail
https://bugzilla.kernel.org/show_bug.cgi?id=60523
--- Comment #47 from Alex Belykh ---
Created attachment 124111
--> https://bugzilla.kernel.org/attachment.cgi?id=124111=edit
dmesg when booting with two monitors
The lockups at 3.8 sec and 19.3 sec are observable. Also I wonder why it
https://bugzilla.kernel.org/show_bug.cgi?id=60523
Alex Belykh changed:
What|Removed |Added
CC||albel727 at ngs.ru
--- Comment #46 from
https://bugzilla.kernel.org/show_bug.cgi?id=60523
--- Comment #45 from Alex Deucher ---
(In reply to Tobias Droste from comment #44)
> I see you want to enable DPM by default. Are there any news on this one?
> Should I (we) try the drm-next branch to see if it is fixed? It's still an
> issue on
https://bugzilla.kernel.org/show_bug.cgi?id=60523
--- Comment #44 from Tobias Droste ---
I see you want to enable DPM by default. Are there any news on this one? Should
I (we) try the drm-next branch to see if it is fixed? It's still an issue on
the drm-fixes branch from airlied.
--
You are
https://bugzilla.kernel.org/show_bug.cgi?id=60523
--- Comment #43 from Nathan Jones crshbn...@gmail.com ---
I can reproduce it in Gentoo with 3.11.0, GCC 4.6.3. GPU Temperature is 25C (as
reported by lm-sensors) with any UVD accelerated media playing, and cat
https://bugzilla.kernel.org/show_bug.cgi?id=60523
--- Comment #42 from Alex Deucher ---
I can reproduce it in Fedora 17 as well (gcc 4.7). So it seems to be something
about Fedora 16 (gcc 4.6).
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=60523
--- Comment #41 from Alex Deucher ---
Well, it helps a little, but I'm still able to reproduce it eventually even
with the patch. The same kernel source is working fine on a fedora 16 system
and now exhibits this problem on Fedora 19. So maybe
https://bugzilla.kernel.org/show_bug.cgi?id=60523
--- Comment #40 from queryv+fd at gmail.com ---
(In reply to Alex Deucher from comment #39)
> Created attachment 107254 [details]
> fix for 3.11
>
> The attached patch seems to fix it for me.
That doesn't seem to fix it for me (6870). I first
https://bugzilla.kernel.org/show_bug.cgi?id=60523
--- Comment #39 from Alex Deucher ---
Created attachment 107254
--> https://bugzilla.kernel.org/attachment.cgi?id=107254=edit
fix for 3.11
The attached patch seems to fix it for me.
--
You are receiving this mail because:
You are watching
https://bugzilla.kernel.org/show_bug.cgi?id=60523
--- Comment #38 from Tobias Droste ---
I don't want to say that it's not a gcc bug, but I'm using gcc 4.7:
gcc version 4.7.2 20130108 [gcc-4_7-branch revision 195012] (SUSE Linux)
--
You are receiving this mail because:
You are watching the
https://bugzilla.kernel.org/show_bug.cgi?id=60523
--- Comment #37 from Alex Deucher ---
I was finally able to reproduce this, but only with gcc 4.8. Older versions of
gcc work fine. Looks like the gcc bug has struck again. See:
https://bugs.freedesktop.org/show_bug.cgi?id=66932
Now to find
https://bugzilla.kernel.org/show_bug.cgi?id=60523
--- Comment #37 from Alex Deucher alexdeuc...@gmail.com ---
I was finally able to reproduce this, but only with gcc 4.8. Older versions of
gcc work fine. Looks like the gcc bug has struck again. See:
https://bugzilla.kernel.org/show_bug.cgi?id=60523
--- Comment #38 from Tobias Droste tdro...@gmx.de ---
I don't want to say that it's not a gcc bug, but I'm using gcc 4.7:
gcc version 4.7.2 20130108 [gcc-4_7-branch revision 195012] (SUSE Linux)
--
You are receiving this mail because:
You are
https://bugzilla.kernel.org/show_bug.cgi?id=60523
--- Comment #39 from Alex Deucher alexdeuc...@gmail.com ---
Created attachment 107254
-- https://bugzilla.kernel.org/attachment.cgi?id=107254action=edit
fix for 3.11
The attached patch seems to fix it for me.
--
You are receiving this mail
https://bugzilla.kernel.org/show_bug.cgi?id=60523
--- Comment #40 from queryv...@gmail.com ---
(In reply to Alex Deucher from comment #39)
Created attachment 107254 [details]
fix for 3.11
The attached patch seems to fix it for me.
That doesn't seem to fix it for me (6870). I first tried
https://bugzilla.kernel.org/show_bug.cgi?id=60523
--- Comment #41 from Alex Deucher alexdeuc...@gmail.com ---
Well, it helps a little, but I'm still able to reproduce it eventually even
with the patch. The same kernel source is working fine on a fedora 16 system
and now exhibits this problem on
https://bugzilla.kernel.org/show_bug.cgi?id=60523
--- Comment #42 from Alex Deucher alexdeuc...@gmail.com ---
I can reproduce it in Fedora 17 as well (gcc 4.7). So it seems to be something
about Fedora 16 (gcc 4.6).
--
You are receiving this mail because:
You are watching the assignee of the
https://bugzilla.kernel.org/show_bug.cgi?id=60523
--- Comment #36 from Tobias Droste ---
Hm I'm pretty sure the "stuck" power level is the same problem as the "write
error: Invalid argument" problem.
Are you sure you're in the correct directory before executing the command?
If you're not in
https://bugzilla.kernel.org/show_bug.cgi?id=60523
--- Comment #35 from pitamm at gmail.com ---
I have the same problem with HD5700. Since the others have attached dmesg
reports already, I am not including mine.
Unlike droste, when I do:
# echo high > power_dpm_force_performance_level
OR
# echo
https://bugzilla.kernel.org/show_bug.cgi?id=60523
--- Comment #34 from queryv+fd at gmail.com ---
Created attachment 107241
--> https://bugzilla.kernel.org/attachment.cgi?id=107241=edit
full dmesg (HD6870)
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=60523
queryv+fd at gmail.com changed:
What|Removed |Added
CC||queryv+fd at gmail.com
---
https://bugzilla.kernel.org/show_bug.cgi?id=60523
--- Comment #35 from pit...@gmail.com ---
I have the same problem with HD5700. Since the others have attached dmesg
reports already, I am not including mine.
Unlike droste, when I do:
# echo high power_dpm_force_performance_level
OR
# echo low
https://bugzilla.kernel.org/show_bug.cgi?id=60523
--- Comment #36 from Tobias Droste tdro...@gmx.de ---
Hm I'm pretty sure the stuck power level is the same problem as the write
error: Invalid argument problem.
Are you sure you're in the correct directory before executing the command?
If you're
https://bugzilla.kernel.org/show_bug.cgi?id=60523
queryv...@gmail.com changed:
What|Removed |Added
CC||queryv...@gmail.com
--- Comment #33
https://bugzilla.kernel.org/show_bug.cgi?id=60523
--- Comment #34 from queryv...@gmail.com ---
Created attachment 107241
-- https://bugzilla.kernel.org/attachment.cgi?id=107241action=edit
full dmesg (HD6870)
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=60523
--- Comment #32 from Christian Birchinger ---
Yes, i did this:
xrandr --newmode "1600x1200_test" 229.5 1600 1664 1856 2160 1200 1201 1204
1250 +hsync +vsync
Puts my state to this:
uvdvclk: 0 dclk: 0
power level 0sclk: 15700 mclk:
https://bugzilla.kernel.org/show_bug.cgi?id=60523
--- Comment #31 from Alex Deucher ---
(In reply to Christian Birchinger from comment #30)
> Maybe the same reason why Tobias is stuck at level 2.
>
Right you both seem to be afflicted but the same issue.
> Since i'm no longer able to use tools
https://bugzilla.kernel.org/show_bug.cgi?id=60523
--- Comment #30 from Christian Birchinger ---
Maybe the same reason why Tobias is stuck at level 2.
Since i'm no longer able to use tools like xvidtune and the online modeline
calculator tells me 1600x1200 85hz requires >300Mhz pixel clock, so
https://bugzilla.kernel.org/show_bug.cgi?id=60523
--- Comment #29 from Alex Deucher ---
Correct. I'm not sure why that state sees to get stuck in the highest
performance level on your cards though.
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=60523
--- Comment #28 from Christian Birchinger ---
Ok thanks.
I was just in the middle of posting this:
With 1280x1024 it switched to power level 0 but without "single_disp".
With the really low 640x400 mode it did also use "single_disp".
But i now
https://bugzilla.kernel.org/show_bug.cgi?id=60523
--- Comment #27 from Tobias Droste ---
Isn't this the reason why there is a multi-monitor power state? same mclk but
different sclk for each power level? So switching between them should be no
problem because there's no memory reclocking
https://bugzilla.kernel.org/show_bug.cgi?id=60523
--- Comment #26 from Alex Deucher ---
In order to switch the mclk, the hw needs at least 450us. The vblank period of
the 1600x1200 mode is 396us, so it's not long enough to switch. The switch has
to happen during vblank to avoid seeing a
https://bugzilla.kernel.org/show_bug.cgi?id=60523
--- Comment #25 from Christian Birchinger ---
So with the problem being the vblank i switched the resolutions using xrandr.
Using lower resolution modes makes it start switching.
~ $ xrandr
Screen 0: minimum 320 x 200, current 1600 x 1200,
https://bugzilla.kernel.org/show_bug.cgi?id=60523
--- Comment #24 from Christian Birchinger ---
Created attachment 107212
--> https://bugzilla.kernel.org/attachment.cgi?id=107212=edit
debug drm output
Yes, i get lots of output. Log is attached
--
You are receiving this mail because:
You are
https://bugzilla.kernel.org/show_bug.cgi?id=60523
--- Comment #23 from Alex Deucher ---
Ah, you have a system with gddr5 memory. The blanking period is probably too
short on your monitor to support mclk switching. Something like this will tell
you for sure:
diff --git
https://bugzilla.kernel.org/show_bug.cgi?id=60523
--- Comment #22 from Christian Birchinger ---
Created attachment 107211
--> https://bugzilla.kernel.org/attachment.cgi?id=107211=edit
drm/radeon boot output
The relevant radeon and drm boot message output
--
You are receiving this mail
https://bugzilla.kernel.org/show_bug.cgi?id=60523
--- Comment #21 from Christian Birchinger ---
No change here at all with those 2 patches. I'm attaching my boot dmesg just in
case my maybe weird setup (CRT monitor) does not cause anything special.
--
You are receiving this mail because:
You
https://bugzilla.kernel.org/show_bug.cgi?id=60523
--- Comment #20 from Alex Deucher ---
Christian, Can you try this patch:
http://lists.freedesktop.org/archives/dri-devel/2013-August/043464.html
I the vblank period on your monitor is short enough that it's causing the
driver to select the
https://bugzilla.kernel.org/show_bug.cgi?id=60523
--- Comment #19 from Christian Birchinger ---
Just to be totaly clear. In my case i only have one monitor in use. I don't use
any multi-head setup at the moment.
The rest is identical. dpms standby puts it to level 0, when it wakes up it's
also
https://bugzilla.kernel.org/show_bug.cgi?id=60523
--- Comment #18 from Tobias Droste ---
Doesn't help here.
But I can confirm that it works as soon as dpms is active and dpm switches to
power level 0. It stays at power level 0 after the monitors are active again
and I can echo things to
https://bugzilla.kernel.org/show_bug.cgi?id=60523
--- Comment #17 from Alex Deucher ---
Does this patch help?
diff --git a/drivers/gpu/drm/radeon/cypress_dpm.c
b/drivers/gpu/drm/radeon/cypress_dpm.c
index 95a66db..a1d2503 100644
--- a/drivers/gpu/drm/radeon/cypress_dpm.c
+++
https://bugzilla.kernel.org/show_bug.cgi?id=60523
Tobias Droste changed:
What|Removed |Added
Kernel Version|drm-fixes-3.11 |drm-next-3.12-wip
https://bugzilla.kernel.org/show_bug.cgi?id=60523
--- Comment #17 from Alex Deucher alexdeuc...@gmail.com ---
Does this patch help?
diff --git a/drivers/gpu/drm/radeon/cypress_dpm.c
b/drivers/gpu/drm/radeon/cypress_dpm.c
index 95a66db..a1d2503 100644
--- a/drivers/gpu/drm/radeon/cypress_dpm.c
https://bugzilla.kernel.org/show_bug.cgi?id=60523
--- Comment #18 from Tobias Droste tdro...@gmx.de ---
Doesn't help here.
But I can confirm that it works as soon as dpms is active and dpm switches to
power level 0. It stays at power level 0 after the monitors are active again
and I can echo
https://bugzilla.kernel.org/show_bug.cgi?id=60523
--- Comment #19 from Christian Birchinger jo...@netswarm.net ---
Just to be totaly clear. In my case i only have one monitor in use. I don't use
any multi-head setup at the moment.
The rest is identical. dpms standby puts it to level 0, when it
https://bugzilla.kernel.org/show_bug.cgi?id=60523
--- Comment #20 from Alex Deucher alexdeuc...@gmail.com ---
Christian, Can you try this patch:
http://lists.freedesktop.org/archives/dri-devel/2013-August/043464.html
I the vblank period on your monitor is short enough that it's causing the
https://bugzilla.kernel.org/show_bug.cgi?id=60523
--- Comment #21 from Christian Birchinger jo...@netswarm.net ---
No change here at all with those 2 patches. I'm attaching my boot dmesg just in
case my maybe weird setup (CRT monitor) does not cause anything special.
--
You are receiving this
https://bugzilla.kernel.org/show_bug.cgi?id=60523
--- Comment #22 from Christian Birchinger jo...@netswarm.net ---
Created attachment 107211
-- https://bugzilla.kernel.org/attachment.cgi?id=107211action=edit
drm/radeon boot output
The relevant radeon and drm boot message output
--
You are
https://bugzilla.kernel.org/show_bug.cgi?id=60523
--- Comment #23 from Alex Deucher alexdeuc...@gmail.com ---
Ah, you have a system with gddr5 memory. The blanking period is probably too
short on your monitor to support mclk switching. Something like this will tell
you for sure:
diff --git
https://bugzilla.kernel.org/show_bug.cgi?id=60523
--- Comment #24 from Christian Birchinger jo...@netswarm.net ---
Created attachment 107212
-- https://bugzilla.kernel.org/attachment.cgi?id=107212action=edit
debug drm output
Yes, i get lots of output. Log is attached
--
You are receiving
https://bugzilla.kernel.org/show_bug.cgi?id=60523
--- Comment #25 from Christian Birchinger jo...@netswarm.net ---
So with the problem being the vblank i switched the resolutions using xrandr.
Using lower resolution modes makes it start switching.
~ $ xrandr
Screen 0: minimum 320 x 200, current
https://bugzilla.kernel.org/show_bug.cgi?id=60523
--- Comment #26 from Alex Deucher alexdeuc...@gmail.com ---
In order to switch the mclk, the hw needs at least 450us. The vblank period of
the 1600x1200 mode is 396us, so it's not long enough to switch. The switch has
to happen during vblank to
https://bugzilla.kernel.org/show_bug.cgi?id=60523
--- Comment #27 from Tobias Droste tdro...@gmx.de ---
Isn't this the reason why there is a multi-monitor power state? same mclk but
different sclk for each power level? So switching between them should be no
problem because there's no memory
https://bugzilla.kernel.org/show_bug.cgi?id=60523
--- Comment #28 from Christian Birchinger jo...@netswarm.net ---
Ok thanks.
I was just in the middle of posting this:
With 1280x1024 it switched to power level 0 but without single_disp.
With the really low 640x400 mode it did also use
https://bugzilla.kernel.org/show_bug.cgi?id=60523
--- Comment #29 from Alex Deucher alexdeuc...@gmail.com ---
Correct. I'm not sure why that state sees to get stuck in the highest
performance level on your cards though.
--
You are receiving this mail because:
You are watching the assignee of
https://bugzilla.kernel.org/show_bug.cgi?id=60523
--- Comment #30 from Christian Birchinger jo...@netswarm.net ---
Maybe the same reason why Tobias is stuck at level 2.
Since i'm no longer able to use tools like xvidtune and the online modeline
calculator tells me 1600x1200 85hz requires 300Mhz
https://bugzilla.kernel.org/show_bug.cgi?id=60523
--- Comment #31 from Alex Deucher alexdeuc...@gmail.com ---
(In reply to Christian Birchinger from comment #30)
Maybe the same reason why Tobias is stuck at level 2.
Right you both seem to be afflicted but the same issue.
Since i'm no longer
https://bugzilla.kernel.org/show_bug.cgi?id=60523
--- Comment #32 from Christian Birchinger jo...@netswarm.net ---
Yes, i did this:
xrandr --newmode 1600x1200_test 229.5 1600 1664 1856 2160 1200 1201 1204
1250 +hsync +vsync
Puts my state to this:
uvdvclk: 0 dclk: 0
power level 0sclk:
https://bugzilla.kernel.org/show_bug.cgi?id=60523
Tobias Droste tdro...@gmx.de changed:
What|Removed |Added
Kernel Version|drm-fixes-3.11 |drm-next-3.12-wip
89 matches
Mail list logo
