| Message ID | 20140415070204.GA4806@pd.tnic (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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=32167016076f714f0e35e287fbead7de0f1fb179 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=32167016076f714f0e35e287fbead7de0f1fb179 > 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=32167016076f714f0e35e287fbead7de0f1fb179 > 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
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=32167016076f714f0e35e287fbead7de0f1fb179 > 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.
--- /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 +