Bug 69301

Summary: no screen on update from 3.12.0
Product: Drivers Reporter: Jan Outhuis (jouthuis)
Component: Video(DRI - non Intel)Assignee: drivers_video-dri
Status: RESOLVED OBSOLETE    
Severity: normal CC: abandonedaccountubdprczb8hs, alan, alexdeucher, damien.lespiau, jakob.kummerow
Priority: P1    
Hardware: x86-64   
OS: Linux   
Kernel Version: 3.13.0 Subsystem:
Regression: No Bisected commit-id:
Attachments: possible fix for SI
attachment-17918-0.html

Description Jan Outhuis 2014-01-23 14:44:05 UTC
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.
Comment 1 Alex Deucher 2014-01-23 15:22:16 UTC
Can you bisect?  Does disabling dpm help?  Add radeon.dpm=0 on the kernel command line in grub.
Comment 2 Damien Lespiau 2014-01-23 15:27:31 UTC
You changed the component to DRI - Intel, was this intentional?
Comment 3 Jan Outhuis 2014-01-23 17:14:32 UTC
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?
>
Comment 4 Alan 2014-01-23 20:50:46 UTC
Ok thanks - moved to the right graphics
Comment 5 Jan Outhuis 2014-01-23 23:04:49 UTC
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.
>
Comment 7 Jan Outhuis 2014-01-26 15:48:51 UTC
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=4573388c92ee60b4ed72b8d95b73df861189988c
> help?
>
Comment 8 Jakob Kummerow 2014-01-28 18:45:57 UTC
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.
Comment 9 Jan Outhuis 2014-01-30 13:39:57 UTC
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: 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.
>
Comment 10 Alex Deucher 2014-01-30 17:18:40 UTC
Does 3.14 (Linus git) work any better?
Comment 11 Jan Outhuis 2014-01-31 14:48:03 UTC
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?
>
Comment 12 Jakob Kummerow 2014-02-02 18:38:56 UTC
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.
Comment 13 Alex Deucher 2014-02-03 15:18:56 UTC
(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.
Comment 14 Alex Deucher 2014-02-03 15:25:49 UTC
Created attachment 124331 [details]
possible fix for SI

Jan, does this patch help?
Comment 15 Jan Outhuis 2014-02-06 17:03:44 UTC
Created attachment 124871 [details]
attachment-17918-0.html

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 [details]
>   --> https://bugzilla.kernel.org/attachment.cgi?id=124331&action=edit
> possible fix for SI
> 
> Jan, does this patch help?
>
Comment 16 Alex Deucher 2014-02-06 17:10:30 UTC
(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.
Comment 17 Michel Dänzer 2014-02-07 02:02:31 UTC
(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.
Comment 18 Jan Outhuis 2014-02-07 13:44:19 UTC
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.
>
Comment 19 Jan Outhuis 2014-02-16 12:51:46 UTC
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: 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.
>
Comment 20 abandoned account 2015-04-25 16:37:27 UTC
"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.
Comment 21 Jan Outhuis 2015-04-30 12:06:47 UTC
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