https://bugzilla.kernel.org/show_bug.cgi?id=69301
Bug ID: 69301 Summary: no screen on update from 3.12.0 Product: Drivers Version: 2.5 Kernel Version: 3.13.0 Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri@kernel-bugs.osdl.org Reporter: jouthuis@dds.nl Regression: No
3.13.0 hangs on video initialisation for my Radeon HD7750 card. It worked on 3.12.0 and previous on 3.11.4.
After upgrading to 3.13.0, the bootprocess doesn't get past the video-initialisation and leaves me with a black screen and dead keyboard.
I'm running Debian testing on 64bit architecture.
https://bugzilla.kernel.org/show_bug.cgi?id=69301
Jan Outhuis jouthuis@dds.nl changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |intel-gfx-bugs@lists.freede | |sktop.org Component|Video(DRI - non Intel) |Video(DRI - Intel)
https://bugzilla.kernel.org/show_bug.cgi?id=69301
Alex Deucher alexdeucher@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |alexdeucher@gmail.com
--- Comment #1 from Alex Deucher alexdeucher@gmail.com --- Can you bisect? Does disabling dpm help? Add radeon.dpm=0 on the kernel command line in grub.
https://bugzilla.kernel.org/show_bug.cgi?id=69301
Damien Lespiau damien.lespiau@intel.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |damien.lespiau@intel.com
--- Comment #2 from Damien Lespiau damien.lespiau@intel.com --- You changed the component to DRI - Intel, was this intentional?
https://bugzilla.kernel.org/show_bug.cgi?id=69301
--- Comment #3 from Jan Outhuis jouthuis@dds.nl --- Yes. I don't exactly understand what these 'video components' stand for, but I have an Intel CPU and an AMD/ATI video-card. So I thought DRI - Intel would be the better choice after all.
On Thu, 2014-01-23 at 15:27 +0000, bugzilla-daemon@bugzilla.kernel.org wrote:
https://bugzilla.kernel.org/show_bug.cgi?id=69301
Damien Lespiau damien.lespiau@intel.com changed:
What |Removed |Added
CC| |damien.lespiau@intel.com--- Comment #2 from Damien Lespiau damien.lespiau@intel.com --- You changed the component to DRI - Intel, was this intentional?
https://bugzilla.kernel.org/show_bug.cgi?id=69301
Alan alan@lxorguk.ukuu.org.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |alan@lxorguk.ukuu.org.uk Component|Video(DRI - Intel) |Video(DRI - non Intel)
--- Comment #4 from Alan alan@lxorguk.ukuu.org.uk --- Ok thanks - moved to the right graphics
https://bugzilla.kernel.org/show_bug.cgi?id=69301
--- Comment #5 from Jan Outhuis jouthuis@dds.nl --- Disabling dpm gets me through the bootprocess. I have a text console on tty1-6, but still no graphic screen on tty7 (or 8). The relevant logs show no particular warnings or errors that could give a clue.
On Thu, 2014-01-23 at 15:22 +0000, bugzilla-daemon@bugzilla.kernel.org wrote:
https://bugzilla.kernel.org/show_bug.cgi?id=69301
Alex Deucher alexdeucher@gmail.com changed:
What |Removed |Added
CC| |alexdeucher@gmail.com--- Comment #1 from Alex Deucher alexdeucher@gmail.com --- Can you bisect? Does disabling dpm help? Add radeon.dpm=0 on the kernel command line in grub.
https://bugzilla.kernel.org/show_bug.cgi?id=69301
--- Comment #6 from Alex Deucher alexdeucher@gmail.com --- Does reverting: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=45... help?
https://bugzilla.kernel.org/show_bug.cgi?id=69301
--- Comment #7 from Jan Outhuis jouthuis@dds.nl --- No. Same happens as before: radeon.dpm enabled gives a deadstop early in the bootprocess (hardware reboot required); radeon.dpm=0 finishes the bootprocess, but no screen on tty7.
On Fri, 2014-01-24 at 15:08 +0000, bugzilla-daemon@bugzilla.kernel.org wrote:
https://bugzilla.kernel.org/show_bug.cgi?id=69301
--- Comment #6 from Alex Deucher alexdeucher@gmail.com --- Does reverting: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=45... help?
https://bugzilla.kernel.org/show_bug.cgi?id=69301
Jakob Kummerow jakob.kummerow@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jakob.kummerow@gmail.com
--- Comment #8 from Jakob Kummerow jakob.kummerow@gmail.com --- I'm having a similar problem: with 3.13.0, X fails to start, freezes with a blank screen instead (text mode works fine, though). Adding radeon.dpm=0 to the kernel command line helps. Reverting the commit mentioned in #6 does not help. Everything worked fine with 3.12.* and earlier. This is on a Radeon HD 6850, xf86-video-ati 7.2, mesa 9.2.5, libdrm 2.4.52, with two monitors: one is in use, the other (a TV, connected by DVI-to-HDMI cable) is usually powered off, which doesn't prevent the card from detecting its presence and reading its EDID data.
I can try to bisect this, but won't have time before the weekend.
https://bugzilla.kernel.org/show_bug.cgi?id=69301
--- Comment #9 from Jan Outhuis jouthuis@dds.nl --- Moved on to 3.13.1. This time radeon.dpm=0 solves the problem, i.e. I'm getting full functionality on all screens, textconsole as well as graphic console. Without radeon.dpm=0 on the grub commandline: still same behaviour on boot, i.e. black screen, hardware reboot required.
On Thu, 2014-01-23 at 14:44 +0000, bugzilla-daemon@bugzilla.kernel.org wrote:
https://bugzilla.kernel.org/show_bug.cgi?id=69301
Bug ID: 69301 Summary: no screen on update from 3.12.0 Product: Drivers Version: 2.5 Kernel Version: 3.13.0 Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri@kernel-bugs.osdl.org Reporter: jouthuis@dds.nl Regression: No3.13.0 hangs on video initialisation for my Radeon HD7750 card. It worked on 3.12.0 and previous on 3.11.4.
After upgrading to 3.13.0, the bootprocess doesn't get past the video-initialisation and leaves me with a black screen and dead keyboard.
I'm running Debian testing on 64bit architecture.
https://bugzilla.kernel.org/show_bug.cgi?id=69301
--- Comment #10 from Alex Deucher alexdeucher@gmail.com --- Does 3.14 (Linus git) work any better?
https://bugzilla.kernel.org/show_bug.cgi?id=69301
--- Comment #11 from Jan Outhuis jouthuis@dds.nl --- Took a linux-master.zip from here: https://github.com/torvalds/linux. That was as close as I could get to 3.14.0-rc1. Don't know if this is the right place.
Anyhow, can't report any improvement with this new compiled kernel. Same behavior as with 3.13.1.
On Thu, 2014-01-30 at 17:18 +0000, bugzilla-daemon@bugzilla.kernel.org wrote:
https://bugzilla.kernel.org/show_bug.cgi?id=69301
--- Comment #10 from Alex Deucher alexdeucher@gmail.com --- Does 3.14 (Linus git) work any better?
https://bugzilla.kernel.org/show_bug.cgi?id=69301
--- Comment #12 from Jakob Kummerow jakob.kummerow@gmail.com --- Bisection result:
commit 56684ec5b050e6a392cb3e5324eda12a13413a57 Author: Alex Deucher alexander.deucher@amd.com Date: Wed Oct 30 10:18:37 2013 -0400
drm/radeon: enable DPM by default on BTC asics
Seems to be stable on them.
Which makes sense in so far as I have a Barts card, but obviously this commit did not introduce the actual problem. I guess I'll have to bisect again with an explicit radeon.dpm=1 kernel parameter.
FWIW, on 3.12 and earlier, I used to "echo low > /sys/class/drm/card0/device/power_profile" by means of an init script, and never had any issues with that.
https://bugzilla.kernel.org/show_bug.cgi?id=69301
--- Comment #13 from Alex Deucher alexdeucher@gmail.com --- (In reply to Jakob Kummerow from comment #12)
Bisection result:
commit 56684ec5b050e6a392cb3e5324eda12a13413a57 Author: Alex Deucher alexander.deucher@amd.com Date: Wed Oct 30 10:18:37 2013 -0400
drm/radeon: enable DPM by default on BTC asics Seems to be stable on them.Which makes sense in so far as I have a Barts card, but obviously this commit did not introduce the actual problem. I guess I'll have to bisect again with an explicit radeon.dpm=1 kernel parameter.
FWIW, on 3.12 and earlier, I used to "echo low > /sys/class/drm/card0/device/power_profile" by means of an init script, and never had any issues with that.
Jakub, you are seeing bug 68571 since you have a BTC card. Jan is seeing an issue with an SI card.
https://bugzilla.kernel.org/show_bug.cgi?id=69301
--- Comment #14 from Alex Deucher alexdeucher@gmail.com --- Created attachment 124331 --> https://bugzilla.kernel.org/attachment.cgi?id=124331&action=edit possible fix for SI
Jan, does this patch help?
https://bugzilla.kernel.org/show_bug.cgi?id=69301
--- Comment #15 from Jan Outhuis jouthuis@dds.nl --- No, I'm sorry. Picture stays the same.
I've also done a Git bisect, but the outcome of that doesn't seem to make any sense:
023838542dc8a4eac9650f98942671078a4ce73d is the first bad commit commit 023838542dc8a4eac9650f98942671078a4ce73d Author: Mengdong Lin mengdong.lin@intel.com Date: Thu Oct 31 18:31:51 2013 -0400
ALSA: hda - not choose assigned converters for unused pins of Valleyview
For Valleyview display codec, if an unused pin chooses an assgined converter selected by a used pin, playback on the unused pin can also give sound to the output device of the used pin. It's because data flows from the same convertor to the display port of the used pin. This issue is same as Haswell.
So this patch avoids using assinged convertors for unused pins. The related function haswell_config_cvts() is renamed for code reuse.
Signed-off-by: Mengdong Lin mengdong.lin@intel.com Signed-off-by: Takashi Iwai tiwai@suse.de
:040000 040000 122edb5fbe717222baf3ce8062b444b29d797f1b e04819f96de6c9b46f14b9749e739667edd7422e M sound ++++++++++++++++++++++++++++++ So I guess I'll have to do that all over again. I'm not that familiar yet with doing bisections. By the way, do I have to do a ' make clean' before each new compile?
On Mon, 2014-02-03 at 15:25 +0000, bugzilla-daemon@bugzilla.kernel.org wrote:
https://bugzilla.kernel.org/show_bug.cgi?id=69301
--- Comment #14 from Alex Deucher alexdeucher@gmail.com --- Created attachment 124331 --> https://bugzilla.kernel.org/attachment.cgi?id=124331&action=edit possible fix for SI
Jan, does this patch help?
https://bugzilla.kernel.org/show_bug.cgi?id=69301
--- Comment #16 from Alex Deucher alexdeucher@gmail.com --- (In reply to Jan Outhuis from comment #15)
So I guess I'll have to do that all over again. I'm not that familiar yet with doing bisections. By the way, do I have to do a ' make clean' before each new compile?
No, you don't have to.
https://bugzilla.kernel.org/show_bug.cgi?id=69301
--- Comment #17 from Michel Dänzer michel@daenzer.net --- (In reply to Jan Outhuis from comment #15)
I've also done a Git bisect, but the outcome of that doesn't seem to make any sense: [...] So I guess I'll have to do that all over again. I'm not that familiar yet with doing bisections.
Did you explicitly set radeon.dpm=1 for the bisection? DPM wasn't enabled by default in 3.12.
https://bugzilla.kernel.org/show_bug.cgi?id=69301
--- Comment #18 from Jan Outhuis jouthuis@dds.nl --- Okay, I did a test on that. It appears that 3.12.0 is also 'bad' on radeon.dpm=1. Boot hangs in the same way as with 3.13.
So there's no use in bisecting this issue any further for the moment: none of the available kernels is 'good'.
On Fri, 2014-02-07 at 02:02 +0000, bugzilla-daemon@bugzilla.kernel.org wrote:
https://bugzilla.kernel.org/show_bug.cgi?id=69301
--- Comment #17 from Michel Dänzer michel@daenzer.net --- (In reply to Jan Outhuis from comment #15)
I've also done a Git bisect, but the outcome of that doesn't seem to make any sense: [...] So I guess I'll have to do that all over again. I'm not that familiar yet with doing bisections.
Did you explicitly set radeon.dpm=1 for the bisection? DPM wasn't enabled by default in 3.12.
https://bugzilla.kernel.org/show_bug.cgi?id=69301
--- Comment #19 from Jan Outhuis jouthuis@dds.nl --- I think this bug can be closed. Since the Xorg radeon_si driver does not yet support dpm, the only solution to this problem for now is to simply put radeon.dpm=0 on the kernel command line.
On Thu, 2014-01-23 at 14:44 +0000, bugzilla-daemon@bugzilla.kernel.org wrote:
https://bugzilla.kernel.org/show_bug.cgi?id=69301
Bug ID: 69301 Summary: no screen on update from 3.12.0 Product: Drivers Version: 2.5 Kernel Version: 3.13.0 Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri@kernel-bugs.osdl.org Reporter: jouthuis@dds.nl Regression: No3.13.0 hangs on video initialisation for my Radeon HD7750 card. It worked on 3.12.0 and previous on 3.11.4.
After upgrading to 3.13.0, the bootprocess doesn't get past the video-initialisation and leaves me with a black screen and dead keyboard.
I'm running Debian testing on 64bit architecture.
https://bugzilla.kernel.org/show_bug.cgi?id=69301
EmanueL Czirai emanueLczirai@cryptoLab.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |emanueLczirai@cryptoLab.net
--- Comment #20 from EmanueL Czirai emanueLczirai@cryptoLab.net --- "hangs on video initialisation"
This worked for me(disabling PAT) in a different but seemingly similar case:
" CONFIG_X86_PAT:
Use PAT attributes to setup page level cache control. PATs are the modern equivalents of MTRRs and are much more flexible than MTRRs.
Say N here if you see bootup problems (boot crash, boot hang, spontaneous reboots) or a non-working video driver.
If unsure, say Y. "
I wrote this for another user:
" You could try with kernel option CONFIG_X86_PAT turned off. (I'm assuming here, that you had it turned on; it's a child option to MTRR which is in 'Processor features' main menu in eg. 'make nconfig') I get random black screens right when luks password is about to be entered(and system seems locked up) because that's when radeon switches from text mode into frame buffer(graphics) mode, and that's when it happens(for me anyway). But sometimes I just keep getting this black screen on startup, in which case, I just pass radeon.modeset=0 to kernel cmdline(through grub) and this way I get past it(because it doesn't change into graphics mode) so that I can recompile kernel with that PAT option off; during this time you don't have KMS so X (eg. startx) won't work. "
Cheers, EmanueL.
https://bugzilla.kernel.org/show_bug.cgi?id=69301
Jan Outhuis jouthuis@dds.nl changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |OBSOLETE
--- Comment #21 from Jan Outhuis jouthuis@dds.nl --- I'm changing the status of this bug to 'resolved'. I've moved on to kernel 4.0. And somewhere down the line from 3.13.0 to 4.0 the issue with radeon.dpm disappeared. So I could remove Radeon.dpm=0 from the kernel commandline, I'm not quite sure, but I would say since kernel 3.15.0.
Apparently the support for dpm got implemented in the Radeon_si video driver. I'm on Debian 8 now.
Greetings Jan
dri-devel@lists.freedesktop.org
-
bugzilla-daemon＠bugzilla.kernel.org