Hi guys,
so I'm booting 15-rc1 + tip/master and around the time modesetting gets initialized, the screen blanks and on it appears a message from the monitors:
"The current input timing is not supported by the monitor display. Please change your input timing to 1920x1200@60Hz or any other monitor listed timing as per the monitor specifications."
The box is still responsive, I can reboot it with Ctrl-Alt-Del but screens are blank.
If I boot with radeon.modeset=0, I see the normal nomodeset big letters on the console and not very optimal screen resolution.
Diffing drm init chatter from dmesg shows only this:
--- /tmp/working 2014-04-15 08:40:21.979985352 +0200 +++ /tmp/b0rked 2014-04-15 08:40:11.983985364 +0200 @@ -44,4 +44,5 @@ [drm] pitch is 7680 fbcon: radeondrmfb (fb0) is primary device radeon 0000:01:00.0: fb0: radeondrmfb frame buffer device -[drm] Initialized radeon 2.37.0 20080528 for 0000:01:00.0 on minor 0 +[drm] Initialized radeon 2.38.0 20080528 for 0000:01:00.0 on minor 0 +
Below is the whole thing, btw.
Anyway, if you guys have any ideas, I'm all ears. Otherwise, would a quick bisect on the 59 patches touching drivers/gpu/drm/radeon/ make sense?
git log --oneline v3.14.. drivers/gpu/drm/radeon/ | wc -l 59
Thanks.
[drm] Initialized drm 1.1.0 20060810 [drm] radeon kernel modesetting enabled. [drm] initializing kernel modesetting (RV635 0x1002:0x9598 0x1043:0x01DA). [drm] register mmio base: 0xFEA20000 [drm] register mmio size: 65536 [drm] Detected VRAM RAM=512M, BAR=256M [drm] RAM width 128bits DDR [drm] radeon: 512M of VRAM memory ready [drm] radeon: 512M of GTT memory ready. [drm] Loading RV635 Microcode [drm] Internal thermal controller without fan control [drm] radeon: power management initialized [drm] GART: num cpu pages 131072, num gpu pages 131072 [drm] enabling PCIE gen 2 link speeds, disable with radeon.pcie_gen2=0 [drm] PCIE GART of 512M enabled (table at 0x0000000000040000). [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [drm] Driver supports precise vblank timestamp query. [drm] radeon: irq initialized. [drm] ring test on 0 succeeded in 0 usecs [drm] ib test on ring 0 succeeded in 0 usecs [drm] Radeon Display Connectors [drm] Connector 0: [drm] DVI-I-1 [drm] HPD1 [drm] DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 0x7e58 0x7e5c 0x7e5c [drm] Encoders: [drm] DFP1: INTERNAL_UNIPHY [drm] CRT2: INTERNAL_KLDSCP_DAC2 [drm] Connector 1: [drm] DIN-1 [drm] Encoders: [drm] TV1: INTERNAL_KLDSCP_DAC2 [drm] Connector 2: [drm] DVI-I-2 [drm] HPD2 [drm] DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c [drm] Encoders: [drm] CRT1: INTERNAL_KLDSCP_DAC1 [drm] DFP2: INTERNAL_KLDSCP_LVTMA [drm] fb mappable at 0xC0141000 [drm] vram apper at 0xC0000000 [drm] size 9216000 [drm] fb depth is 24 [drm] pitch is 7680 fbcon: radeondrmfb (fb0) is primary device radeon 0000:01:00.0: fb0: radeondrmfb frame buffer device [drm] Initialized radeon 2.38.0 20080528 for 0000:01:00.0 on minor 0
Hi Borislav,
that's a known issue and should be fixed in the next rc, see this bugreport: https://bugs.freedesktop.org/show_bug.cgi?id=77009
You might also want to try my branch with 3.15 fixes which includes the necessary patch for this: http://cgit.freedesktop.org/~deathsimple/linux/log/?h=drm-fixes-3.15-wip
Let me know if that branch works for you or not.
Regards, Christian.
Am 15.04.2014 09:02, schrieb Borislav Petkov:
Hi guys,
so I'm booting 15-rc1 + tip/master and around the time modesetting gets initialized, the screen blanks and on it appears a message from the monitors:
"The current input timing is not supported by the monitor display. Please change your input timing to 1920x1200@60Hz or any other monitor listed timing as per the monitor specifications."
The box is still responsive, I can reboot it with Ctrl-Alt-Del but screens are blank.
If I boot with radeon.modeset=0, I see the normal nomodeset big letters on the console and not very optimal screen resolution.
Diffing drm init chatter from dmesg shows only this:
--- /tmp/working 2014-04-15 08:40:21.979985352 +0200 +++ /tmp/b0rked 2014-04-15 08:40:11.983985364 +0200 @@ -44,4 +44,5 @@ [drm] pitch is 7680 fbcon: radeondrmfb (fb0) is primary device radeon 0000:01:00.0: fb0: radeondrmfb frame buffer device -[drm] Initialized radeon 2.37.0 20080528 for 0000:01:00.0 on minor 0 +[drm] Initialized radeon 2.38.0 20080528 for 0000:01:00.0 on minor 0
Below is the whole thing, btw.
Anyway, if you guys have any ideas, I'm all ears. Otherwise, would a quick bisect on the 59 patches touching drivers/gpu/drm/radeon/ make sense?
git log --oneline v3.14.. drivers/gpu/drm/radeon/ | wc -l 59
Thanks.
[drm] Initialized drm 1.1.0 20060810 [drm] radeon kernel modesetting enabled. [drm] initializing kernel modesetting (RV635 0x1002:0x9598 0x1043:0x01DA). [drm] register mmio base: 0xFEA20000 [drm] register mmio size: 65536 [drm] Detected VRAM RAM=512M, BAR=256M [drm] RAM width 128bits DDR [drm] radeon: 512M of VRAM memory ready [drm] radeon: 512M of GTT memory ready. [drm] Loading RV635 Microcode [drm] Internal thermal controller without fan control [drm] radeon: power management initialized [drm] GART: num cpu pages 131072, num gpu pages 131072 [drm] enabling PCIE gen 2 link speeds, disable with radeon.pcie_gen2=0 [drm] PCIE GART of 512M enabled (table at 0x0000000000040000). [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [drm] Driver supports precise vblank timestamp query. [drm] radeon: irq initialized. [drm] ring test on 0 succeeded in 0 usecs [drm] ib test on ring 0 succeeded in 0 usecs [drm] Radeon Display Connectors [drm] Connector 0: [drm] DVI-I-1 [drm] HPD1 [drm] DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 0x7e58 0x7e5c 0x7e5c [drm] Encoders: [drm] DFP1: INTERNAL_UNIPHY [drm] CRT2: INTERNAL_KLDSCP_DAC2 [drm] Connector 1: [drm] DIN-1 [drm] Encoders: [drm] TV1: INTERNAL_KLDSCP_DAC2 [drm] Connector 2: [drm] DVI-I-2 [drm] HPD2 [drm] DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c [drm] Encoders: [drm] CRT1: INTERNAL_KLDSCP_DAC1 [drm] DFP2: INTERNAL_KLDSCP_LVTMA [drm] fb mappable at 0xC0141000 [drm] vram apper at 0xC0000000 [drm] size 9216000 [drm] fb depth is 24 [drm] pitch is 7680 fbcon: radeondrmfb (fb0) is primary device radeon 0000:01:00.0: fb0: radeondrmfb frame buffer device [drm] Initialized radeon 2.38.0 20080528 for 0000:01:00.0 on minor 0
Hi Christian,
On Tue, Apr 15, 2014 at 11:28:55AM +0200, Christian König wrote:
Hi Borislav,
that's a known issue and should be fixed in the next rc, see this bugreport: https://bugs.freedesktop.org/show_bug.cgi?id=77009
You might also want to try my branch with 3.15 fixes which includes the necessary patch for this: http://cgit.freedesktop.org/~deathsimple/linux/log/?h=drm-fixes-3.15-wip
Let me know if that branch works for you or not.
so I went and merged your branch as you suggested. Btw, on its tip it has:
commit ec02666dd0791312b5820e1a9a023681d99d07ec Author: Quentin Casasnovas quentin.casasnovas@oracle.com Date: Tue Mar 18 17:16:52 2014 +0100
drm/radeon: memory leak on bo reservation failure. v2
(just checking whether I got the right one)
and, unfortunately, no change - same problem. Let me know if I should bisect the subset of 59 radeon patches which went in during the merge window...
Btw, just in case, I went and updated radeon firmware in /lib/firmware/radeon/ from upstream but it didn't change anything.
Thanks.
On Tue, Apr 15, 2014 at 8:07 AM, Borislav Petkov bp@alien8.de wrote:
Hi Christian,
On Tue, Apr 15, 2014 at 11:28:55AM +0200, Christian König wrote:
Hi Borislav,
that's a known issue and should be fixed in the next rc, see this bugreport: https://bugs.freedesktop.org/show_bug.cgi?id=77009
You might also want to try my branch with 3.15 fixes which includes the necessary patch for this: http://cgit.freedesktop.org/~deathsimple/linux/log/?h=drm-fixes-3.15-wip
Let me know if that branch works for you or not.
so I went and merged your branch as you suggested. Btw, on its tip it has:
commit ec02666dd0791312b5820e1a9a023681d99d07ec Author: Quentin Casasnovas quentin.casasnovas@oracle.com Date: Tue Mar 18 17:16:52 2014 +0100
drm/radeon: memory leak on bo reservation failure. v2
(just checking whether I got the right one)
and, unfortunately, no change - same problem. Let me know if I should bisect the subset of 59 radeon patches which went in during the merge window...
Btw, just in case, I went and updated radeon firmware in /lib/firmware/radeon/ from upstream but it didn't change anything.
Does reverting: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=32... fix the issue? We may need to tweak the pll parameters for older asics.
Alex
Thanks. _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Does reverting: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=32... fix the issue? We may need to tweak the pll parameters for older asics.
Yeah, indeed the most likely cause. Please provide dmesg outputs created with drm.ebug=0xe for the old and the new kernel.
Christian.
Am 15.04.2014 15:06, schrieb Alex Deucher:
On Tue, Apr 15, 2014 at 8:07 AM, Borislav Petkov bp@alien8.de wrote:
Hi Christian,
On Tue, Apr 15, 2014 at 11:28:55AM +0200, Christian König wrote:
Hi Borislav,
that's a known issue and should be fixed in the next rc, see this bugreport: https://bugs.freedesktop.org/show_bug.cgi?id=77009
You might also want to try my branch with 3.15 fixes which includes the necessary patch for this: http://cgit.freedesktop.org/~deathsimple/linux/log/?h=drm-fixes-3.15-wip
Let me know if that branch works for you or not.
so I went and merged your branch as you suggested. Btw, on its tip it has:
commit ec02666dd0791312b5820e1a9a023681d99d07ec Author: Quentin Casasnovas quentin.casasnovas@oracle.com Date: Tue Mar 18 17:16:52 2014 +0100
drm/radeon: memory leak on bo reservation failure. v2
(just checking whether I got the right one)
and, unfortunately, no change - same problem. Let me know if I should bisect the subset of 59 radeon patches which went in during the merge window...
Btw, just in case, I went and updated radeon firmware in /lib/firmware/radeon/ from upstream but it didn't change anything.
Does reverting: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=32... fix the issue? We may need to tweak the pll parameters for older asics.
Alex
Thanks. _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
On Tue, Apr 15, 2014 at 03:09:02PM +0200, Christian König wrote:
Does reverting: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=32... fix the issue? We may need to tweak the pll parameters for older asics.
Yeah, indeed the most likely cause. Please provide dmesg outputs created with drm.ebug=0xe for the old and the new kernel.
Hey, I finally haz 15-rc1+ running here. And I can even see something!
:-)
Ok, so I reverted 32167016076f ontop of Christian's drm-fixes-3.15-wip branch which didn't apply cleanly. So I ended up fixing the conflicts and got the revert below.
With it, the machine booted fine, so it looks like the revert worked.
Christian, I'm sending dmesg outputs in another private mail to you guys.
Thanks.
--- From: Borislav Petkov bp@suse.de Date: Tue, 15 Apr 2014 16:00:58 +0200 Subject: [PATCH] Revert "drm/radeon: rework finding display PLL numbers v2"
This reverts commit 32167016076f714f0e35e287fbead7de0f1fb179.
Conflicts: drivers/gpu/drm/radeon/radeon_display.c --- drivers/gpu/drm/radeon/radeon_display.c | 246 ++++++++++++-------------------- 1 file changed, 90 insertions(+), 156 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_display.c b/drivers/gpu/drm/radeon/radeon_display.c index 2f42912031ac..83891923ac2d 100644 --- a/drivers/gpu/drm/radeon/radeon_display.c +++ b/drivers/gpu/drm/radeon/radeon_display.c @@ -34,8 +34,6 @@ #include <drm/drm_crtc_helper.h> #include <drm/drm_edid.h>
-#include <linux/gcd.h> - static void avivo_crtc_load_lut(struct drm_crtc *crtc) { struct radeon_crtc *radeon_crtc = to_radeon_crtc(crtc); @@ -802,57 +800,66 @@ int radeon_ddc_get_modes(struct radeon_connector *radeon_connector) }
/* avivo */ +static void avivo_get_fb_div(struct radeon_pll *pll, + u32 target_clock, + u32 post_div, + u32 ref_div, + u32 *fb_div, + u32 *frac_fb_div) +{ + u32 tmp = post_div * ref_div;
-/** - * avivo_reduce_ratio - fractional number reduction - * - * @nom: nominator - * @den: denominator - * @nom_min: minimum value for nominator - * @den_min: minimum value for denominator - * - * Find the greatest common divisor and apply it on both nominator and - * denominator, but make nominator and denominator are at least as large - * as their minimum values. - */ -static void avivo_reduce_ratio(unsigned *nom, unsigned *den, - unsigned nom_min, unsigned den_min) + tmp *= target_clock; + *fb_div = tmp / pll->reference_freq; + *frac_fb_div = tmp % pll->reference_freq; + + if (*fb_div > pll->max_feedback_div) + *fb_div = pll->max_feedback_div; + else if (*fb_div < pll->min_feedback_div) + *fb_div = pll->min_feedback_div; +} + +static u32 avivo_get_post_div(struct radeon_pll *pll, + u32 target_clock) { - unsigned tmp; - - /* reduce the numbers to a simpler ratio */ - tmp = gcd(*nom, *den); - *nom /= tmp; - *den /= tmp; - - /* make sure nominator is large enough */ - if (*nom < nom_min) { - tmp = (nom_min + *nom - 1) / *nom; - *nom *= tmp; - *den *= tmp; + u32 vco, post_div, tmp; + + if (pll->flags & RADEON_PLL_USE_POST_DIV) + return pll->post_div; + + if (pll->flags & RADEON_PLL_PREFER_MINM_OVER_MAXP) { + if (pll->flags & RADEON_PLL_IS_LCD) + vco = pll->lcd_pll_out_min; + else + vco = pll->pll_out_min; + } else { + if (pll->flags & RADEON_PLL_IS_LCD) + vco = pll->lcd_pll_out_max; + else + vco = pll->pll_out_max; }
- /* make sure the denominator is large enough */ - if (*den < den_min) { - tmp = (den_min + *den - 1) / *den; - *nom *= tmp; - *den *= tmp; + post_div = vco / target_clock; + tmp = vco % target_clock; + + if (pll->flags & RADEON_PLL_PREFER_MINM_OVER_MAXP) { + if (tmp) + post_div++; + } else { + if (!tmp) + post_div--; } + + if (post_div > pll->max_post_div) + post_div = pll->max_post_div; + else if (post_div < pll->min_post_div) + post_div = pll->min_post_div; + + return post_div; }
-/** - * radeon_compute_pll_avivo - compute PLL paramaters - * - * @pll: information about the PLL - * @dot_clock_p: resulting pixel clock - * fb_div_p: resulting feedback divider - * frac_fb_div_p: fractional part of the feedback divider - * ref_div_p: resulting reference divider - * post_div_p: resulting reference divider - * - * Try to calculate the PLL parameters to generate the given frequency: - * dot_clock = (ref_freq * feedback_div) / (ref_div * post_div) - */ +#define MAX_TOLERANCE 10 + void radeon_compute_pll_avivo(struct radeon_pll *pll, u32 freq, u32 *dot_clock_p, @@ -861,126 +868,53 @@ void radeon_compute_pll_avivo(struct radeon_pll *pll, u32 *ref_div_p, u32 *post_div_p) { - unsigned fb_div_min, fb_div_max, fb_div; - unsigned post_div_min, post_div_max, post_div; - unsigned ref_div_min, ref_div_max, ref_div; - unsigned post_div_best, diff_best; - unsigned nom, den, tmp; - - /* determine allowed feedback divider range */ - fb_div_min = pll->min_feedback_div; - fb_div_max = pll->max_feedback_div; + u32 target_clock = freq / 10; + u32 post_div = avivo_get_post_div(pll, target_clock); + u32 ref_div = pll->min_ref_div; + u32 fb_div = 0, frac_fb_div = 0, tmp;
- if (pll->flags & RADEON_PLL_USE_FRAC_FB_DIV) { - fb_div_min *= 10; - fb_div_max *= 10; - } - - /* determine allowed ref divider range */ if (pll->flags & RADEON_PLL_USE_REF_DIV) - ref_div_min = pll->reference_div; - else - ref_div_min = pll->min_ref_div; - ref_div_max = pll->max_ref_div; + ref_div = pll->reference_div;
- /* determine allowed post divider range */ - if (pll->flags & RADEON_PLL_USE_POST_DIV) { - post_div_min = pll->post_div; - post_div_max = pll->post_div; - } else { - unsigned target_clock = freq / 10; - unsigned vco_min, vco_max; - - if (pll->flags & RADEON_PLL_IS_LCD) { - vco_min = pll->lcd_pll_out_min; - vco_max = pll->lcd_pll_out_max; - } else { - vco_min = pll->pll_out_min; - vco_max = pll->pll_out_max; + if (pll->flags & RADEON_PLL_USE_FRAC_FB_DIV) { + avivo_get_fb_div(pll, target_clock, post_div, ref_div, &fb_div, &frac_fb_div); + frac_fb_div = (100 * frac_fb_div) / pll->reference_freq; + if (frac_fb_div >= 5) { + frac_fb_div -= 5; + frac_fb_div = frac_fb_div / 10; + frac_fb_div++; } - - post_div_min = vco_min / target_clock; - if ((target_clock * post_div_min) < vco_min) - ++post_div_min; - if (post_div_min < pll->min_post_div) - post_div_min = pll->min_post_div; - - post_div_max = vco_max / target_clock; - if ((target_clock * post_div_max) > vco_max) - --post_div_max; - if (post_div_max > pll->max_post_div) - post_div_max = pll->max_post_div; - } - - /* represent the searched ratio as fractional number */ - nom = pll->flags & RADEON_PLL_USE_FRAC_FB_DIV ? freq : freq / 10; - den = pll->reference_freq; - - /* reduce the numbers to a simpler ratio */ - avivo_reduce_ratio(&nom, &den, fb_div_min, post_div_min); - - /* now search for a post divider */ - if (pll->flags & RADEON_PLL_PREFER_MINM_OVER_MAXP) - post_div_best = post_div_min; - else - post_div_best = post_div_max; - diff_best = ~0; - - for (post_div = post_div_min; post_div <= post_div_max; ++post_div) { - unsigned diff = abs(den - den / post_div * post_div); - if (diff < diff_best || (diff == diff_best && - !(pll->flags & RADEON_PLL_PREFER_MINM_OVER_MAXP))) { - - post_div_best = post_div; - diff_best = diff; + if (frac_fb_div >= 10) { + fb_div++; + frac_fb_div = 0; } - } - post_div = post_div_best; - - /* limit reference * post divider to a maximum */ - ref_div_max = min(210 / post_div, ref_div_max); - - /* get matching reference and feedback divider */ - ref_div = max(den / post_div, 1u); - fb_div = nom; - - /* we're almost done, but reference and feedback - divider might be to large now */ - - tmp = ref_div; - - if (fb_div > fb_div_max) { - ref_div = ref_div * fb_div_max / fb_div; - fb_div = fb_div_max; - } - - if (ref_div > ref_div_max) { - ref_div = ref_div_max; - fb_div = nom * ref_div_max / tmp; - } - - /* reduce the numbers to a simpler ratio once more */ - /* this also makes sure that the reference divider is large enough */ - avivo_reduce_ratio(&fb_div, &ref_div, fb_div_min, ref_div_min); - - /* and finally save the result */ - if (pll->flags & RADEON_PLL_USE_FRAC_FB_DIV) { - *fb_div_p = fb_div / 10; - *frac_fb_div_p = fb_div % 10; } else { - *fb_div_p = fb_div; - *frac_fb_div_p = 0; + while (ref_div <= pll->max_ref_div) { + avivo_get_fb_div(pll, target_clock, post_div, ref_div, + &fb_div, &frac_fb_div); + if (frac_fb_div >= (pll->reference_freq / 2)) + fb_div++; + frac_fb_div = 0; + tmp = (pll->reference_freq * fb_div) / (post_div * ref_div); + tmp = (tmp * 10000) / target_clock; + + if (tmp > (10000 + MAX_TOLERANCE)) + ref_div++; + else if (tmp >= (10000 - MAX_TOLERANCE)) + break; + else + ref_div++; + } }
- *dot_clock_p = ((pll->reference_freq * *fb_div_p * 10) + - (pll->reference_freq * *frac_fb_div_p)) / - (ref_div * post_div * 10); + *dot_clock_p = ((pll->reference_freq * fb_div * 10) + (pll->reference_freq * frac_fb_div)) / + (ref_div * post_div * 10); + *fb_div_p = fb_div; + *frac_fb_div_p = frac_fb_div; *ref_div_p = ref_div; *post_div_p = post_div; - - DRM_DEBUG_KMS("%d - %d, pll dividers - fb: %d.%d ref: %d, post %d\n", - freq, *dot_clock_p, *fb_div_p, *frac_fb_div_p, - ref_div, post_div); + DRM_DEBUG_KMS("%d, pll dividers - fb: %d.%d ref: %d, post %d\n", + *dot_clock_p, fb_div, frac_fb_div, ref_div, post_div); }
/* pre-avivo */
Hi Borislav,
thanks for the logs, those were indeed quite helpful.
Attached are two patches, the first one tries to solve the problem by increasing the accuracy of the parameters if we don't match exactly and the second improves the logging of the calculation process by dumping a bunch of intermediate values used.
Please apply both on top of my drm-fixes-3.15-wip branch you are already using, if the first one doesn't solve the problem then please provide new dmesg logs with drm.debug=0xE.
Thanks in advance, Christian.
Am 15.04.2014 16:24, schrieb Borislav Petkov:
On Tue, Apr 15, 2014 at 03:09:02PM +0200, Christian König wrote:
Does reverting: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=32... fix the issue? We may need to tweak the pll parameters for older asics.
Yeah, indeed the most likely cause. Please provide dmesg outputs created with drm.ebug=0xe for the old and the new kernel.
Hey, I finally haz 15-rc1+ running here. And I can even see something!
:-)
Ok, so I reverted 32167016076f ontop of Christian's drm-fixes-3.15-wip branch which didn't apply cleanly. So I ended up fixing the conflicts and got the revert below.
With it, the machine booted fine, so it looks like the revert worked.
Christian, I'm sending dmesg outputs in another private mail to you guys.
Thanks.
On Wed, Apr 16, 2014 at 12:07:20PM +0200, Christian König wrote:
Hi Borislav,
thanks for the logs, those were indeed quite helpful.
Attached are two patches, the first one tries to solve the problem by increasing the accuracy of the parameters if we don't match exactly and the second improves the logging of the calculation process by dumping a bunch of intermediate values used.
Please apply both on top of my drm-fixes-3.15-wip branch you are already using, if the first one doesn't solve the problem then please provide new dmesg logs with drm.debug=0xE.
Yes, it works fine!
Tested-by: Borislav Petkov bp@suse.de
Thanks for fixing it.
[ 3.634510] [drm] Initialized drm 1.1.0 20060810 [ 6.146795] [drm] radeon kernel modesetting enabled. [ 6.157513] [drm] initializing kernel modesetting (RV635 0x1002:0x9598 0x1043:0x01DA). [ 6.165881] [drm] register mmio base: 0xFEA20000 [ 6.170632] [drm] register mmio size: 65536 [ 6.195783] [drm] Detected VRAM RAM=512M, BAR=256M [ 6.200632] [drm] RAM width 128bits DDR [ 6.245839] [drm] radeon: 512M of VRAM memory ready [ 6.250935] [drm] radeon: 512M of GTT memory ready. [ 6.255995] [drm] Loading RV635 Microcode [ 6.285403] [drm] Internal thermal controller without fan control [ 7.256600] [drm] radeon: power management initialized [ 7.261872] [drm] GART: num cpu pages 131072, num gpu pages 131072 [ 7.268795] [drm] enabling PCIE gen 2 link speeds, disable with radeon.pcie_gen2=0 [ 7.312314] [drm] PCIE GART of 512M enabled (table at 0x0000000000040000). [ 7.334860] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [ 7.341562] [drm] Driver supports precise vblank timestamp query. [ 7.358166] [drm] radeon: irq initialized. [ 7.394139] [drm] ring test on 0 succeeded in 0 usecs [ 7.400078] [drm] ib test on ring 0 succeeded in 0 usecs [ 7.406302] [drm] Radeon Display Connectors [ 7.410553] [drm] Connector 0: [ 7.413654] [drm] DVI-I-1 [ 7.416528] [drm] HPD1 [ 7.419120] [drm] DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 0x7e58 0x7e5c 0x7e5c [ 7.426580] [drm] Encoders: [ 7.429621] [drm] DFP1: INTERNAL_UNIPHY [ 7.433862] [drm] CRT2: INTERNAL_KLDSCP_DAC2 [ 7.438526] [drm] Connector 1: [ 7.441622] [drm] DIN-1 [ 7.444333] [drm] Encoders: [ 7.447346] [drm] TV1: INTERNAL_KLDSCP_DAC2 [ 7.451919] [drm] Connector 2: [ 7.455031] [drm] DVI-I-2 [ 7.457890] [drm] HPD2 [ 7.460469] [drm] DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c [ 7.467926] [drm] Encoders: [ 7.470940] [drm] CRT1: INTERNAL_KLDSCP_DAC1 [ 7.475602] [drm] DFP2: INTERNAL_KLDSCP_LVTMA [ 7.557323] [drm] fb mappable at 0xC0141000 [ 7.561555] [drm] vram apper at 0xC0000000 [ 7.565716] [drm] size 9216000 [ 7.568825] [drm] fb depth is 24 [ 7.572103] [drm] pitch is 7680 [ 7.576458] fbcon: radeondrmfb (fb0) is primary device [ 7.842341] radeon 0000:01:00.0: fb0: radeondrmfb frame buffer device [ 7.854344] [drm] Initialized radeon 2.38.0 20080528 for 0000:01:00.0 on minor 0
Alex Deucher wrote:
On Tue, Apr 15, 2014 at 8:07 AM, Borislav Petkov bp@alien8.de wrote:
Hi Christian,
On Tue, Apr 15, 2014 at 11:28:55AM +0200, Christian König wrote:
Hi Borislav,
that's a known issue and should be fixed in the next rc, see this bugreport: https://bugs.freedesktop.org/show_bug.cgi?id=77009
You might also want to try my branch with 3.15 fixes which includes the necessary patch for this: http://cgit.freedesktop.org/~deathsimple/linux/log/?h=drm-fixes-3.15-wip
Let me know if that branch works for you or not.
so I went and merged your branch as you suggested. Btw, on its tip it has:
commit ec02666dd0791312b5820e1a9a023681d99d07ec Author: Quentin Casasnovas quentin.casasnovas@oracle.com Date: Tue Mar 18 17:16:52 2014 +0100
drm/radeon: memory leak on bo reservation failure. v2
(just checking whether I got the right one)
and, unfortunately, no change - same problem. Let me know if I should bisect the subset of 59 radeon patches which went in during the merge window...
Btw, just in case, I went and updated radeon firmware in /lib/firmware/radeon/ from upstream but it didn't change anything.
Does reverting: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=32... fix the issue? We may need to tweak the pll parameters for older asics.
Alex
Same issue here (integrated Radeon HD 8570D), 64 bit Debian, kernel, drm, mesa built from git today. I see nothing and receive no message on the monitors (i have 2 identical ones, one on the DVI andother on HDMI), but the system is running fine otherwise it seems, i could switch to the console, log in and reboot blindly. Cristian's branch didnt help.
Reverting 32167016076f714f0e35e287fbead7de0f1fb179 did work.
Attached dmesg (booted the unmodified rc1 kernel, switched to tty1 and rebooted blindly).
On Tue, Apr 15, 2014 at 08:08:12PM +0300, Kertesz Laszlo wrote:
Same issue here (integrated Radeon HD 8570D), 64 bit Debian, kernel, drm, mesa built from git today. I see nothing and receive no message on the monitors (i have 2 identical ones, one on the DVI andother on HDMI), but the system is running fine otherwise it seems, i could switch to the console, log in and reboot blindly. Cristian's branch didnt help.
Reverting 32167016076f714f0e35e287fbead7de0f1fb179 did work.
Does booting with "radeon.modeset=0" help?
Borislav Petkov wrote:
On Tue, Apr 15, 2014 at 08:08:12PM +0300, Kertesz Laszlo wrote:
Same issue here (integrated Radeon HD 8570D), 64 bit Debian, kernel, drm, mesa built from git today. I see nothing and receive no message on the monitors (i have 2 identical ones, one on the DVI andother on HDMI), but the system is running fine otherwise it seems, i could switch to the console, log in and reboot blindly. Cristian's branch didnt help.
Reverting 32167016076f714f0e35e287fbead7de0f1fb179 did work.
Does booting with "radeon.modeset=0" help?
Honestly didnt try that but i assume yes, since the screens go black when it should change resolution.
On Tue, Apr 15, 2014 at 09:02:35PM +0300, Kertesz Laszlo wrote:
Honestly didnt try that but i assume yes, since the screens go black when it should change resolution.
Pls try it and let us know whether you see the machine booting further, albeit without modesetting.
Thanks.
Borislav Petkov wrote:
On Tue, Apr 15, 2014 at 09:02:35PM +0300, Kertesz Laszlo wrote:
Honestly didnt try that but i assume yes, since the screens go black when it should change resolution.
Pls try it and let us know whether you see the machine booting further, albeit without modesetting.
Thanks.
Yes, it is working that way. But no X, i assume this is expected.
-----Original Message----- From: Kertesz Laszlo [mailto:laszlo.kertesz@gmail.com] Sent: Tuesday, April 15, 2014 5:50 PM To: Borislav Petkov Cc: Alex Deucher; Deucher, Alexander; Koenig, Christian; Maling list - DRI developers; lkml Subject: Re: 15-rc1: radeon modesetting fails
Borislav Petkov wrote:
On Tue, Apr 15, 2014 at 09:02:35PM +0300, Kertesz Laszlo wrote:
Honestly didnt try that but i assume yes, since the screens go black when it should change resolution.
Pls try it and let us know whether you see the machine booting further, albeit without modesetting.
Thanks.
Yes, it is working that way. But no X, i assume this is expected.
Turning off modesetting basically disables the driver.
Alex
On Tue, Apr 15, 2014 at 10:32:56PM +0000, Deucher, Alexander wrote:
Turning off modesetting basically disables the driver.
Well, in my case, I was using the radeon.modeset=0 variant to rule out issues in x.org. And in my case x.org did start still, albeit with a jacked-up resolution.
But in Laszlo's case, x.org gets "puzzled" too.
Borislav Petkov wrote:
On Tue, Apr 15, 2014 at 10:32:56PM +0000, Deucher, Alexander wrote:
Turning off modesetting basically disables the driver.
Well, in my case, I was using the radeon.modeset=0 variant to rule out issues in x.org. And in my case x.org did start still, albeit with a jacked-up resolution.
But in Laszlo's case, x.org gets "puzzled" too.
Maybe your distro's xorg has some generic vga fallback method. I am not aware that mine (Debian Testing) has one. BTW I use Debian Testing (xfce) and glamor (compiled from git) so i need a specific xorg.conf.
Am 16.04.2014 10:32, schrieb Kertesz Laszlo:
Borislav Petkov wrote:
On Tue, Apr 15, 2014 at 10:32:56PM +0000, Deucher, Alexander wrote:
Turning off modesetting basically disables the driver.
Well, in my case, I was using the radeon.modeset=0 variant to rule out issues in x.org. And in my case x.org did start still, albeit with a jacked-up resolution.
But in Laszlo's case, x.org gets "puzzled" too.
Maybe your distro's xorg has some generic vga fallback method. I am not aware that mine (Debian Testing) has one. BTW I use Debian Testing (xfce) and glamor (compiled from git) so i need a specific xorg.conf.
Using "nomodeset" or radeon.modeset=0 tries to use the deprecated user mode setting, which in your case isn't even supported by the driver.
Please provide dmesg logs with drm-debug=0xe instead.
Thanks in advance, Christian.
dri-devel@lists.freedesktop.org