Bug 69301

Can you bisect?  Does disabling dpm help?  Add radeon.dpm=0 on the kernel command line in grub.

You changed the component to DRI - Intel, was this intentional?

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?
>

Ok thanks - moved to the right graphics

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.
>

Does reverting:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=4573388c92ee60b4ed72b8d95b73df861189988c
help?

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?
>

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.

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.
>

Does 3.14 (Linus git) work any better?

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?
>

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.

(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.

Created attachment 124331 [details]
possible fix for SI

Jan, does this patch help?

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?
>

(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.

(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.

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.
>

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.
>

"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.

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