Bug 55311

Created attachment 97521 [details]
acpidump

Is there any other information which might be needed in order to fix this issue?

Similar downstream bug at https://bugs.gentoo.org/show_bug.cgi?id=458746.

The issues do look similar. I have tried a few things myself but the only solution is to revert to kernel 3.6.10-3.

Should not be difficult to fix the issue since it was working before.

Can you bisect?

Same problem here  on debian with a vanilla kernel (3.7.6).
If I can help testing something .... 
( However I am not an expert [and don't even understand what "Can you bisect means"..)

Alex,

Do you mean test exactly which commit did this? I wouldn't know where to start.

I found the following commits were done for 3.7. There were a few for backlight, not sure if any of these caused the issue:

========================
Add DRM GEM CMA helper (commit), add DRM KMS/FB CMA helper (commit)

backlight

    Add TPS65217 WLED driver (commit)

    Add Backlight driver for lm3630 chip (commit)

    Add new lm3639 backlight driver (commit)

    Remove ProGear driver (commit)

i915: Support for ns2501-DVO (commit)

Renesas SH Mobile DRM driver (commit)

gma500: Add eDP support (commit), add the support of display port on CDV (commit)

Remove pnx4008 driver (commit)


=======================

Please let me know if there is any information I can provide about the issue.

Thanks!

Google for "git bisect howto".  If you have a git tree checked out, you can use git bisect to identify exactly which commit causes a regression.

I am starting a bisect but might take the whole week ... Maybe Fede can be faster.

Bisect going on... 
By the way Fede I got this regression in a 3.6.0+ Kernel 
so its seems to have been introduced before 3.6.10  
If as you said it's working with 3.6.10-3, You may start a bisect with this   kernel version  as good and find an another occurence of the regression (
or I am saying complete bullshit because I don't understand much about all this stuff)

Sure, I'll start running the bisect soon. I'm not with the affected laptop now.

Bisect done, I found it : 

a261b246ebd552fd5d5a8ed84cc931bb821c427f is the first bad commit
commit a261b246ebd552fd5d5a8ed84cc931bb821c427f
Author: Daniel V......[does robot can read this page?]
Date:   Thu Jul 26 19:21:47 2012 +0200

    drm/i915: disable all crtcs at suspend time
    
    We need this to avoid confusing the hw state readout code with the cpt
    pch plls at resume time: We'd read the new pipe state (which is
    disabled), but still believe that we have a life pll connected to that
    pipe (from before the suspend). Hence properly disable pipes to clear
    out all the residual state.
    
    This has the neat side-effect that we don't enable ports prematurely
    by restoring bogus state from the saved register values.

The Black screen is always reproductible, when in the release just before [n-1] the switch seems to work. However I experimented one kernel oops when switching  in [n-1] as well as some previous kernel but it was not the same issue as well as not consistantly reproductible. 
I really think I found the good[well bad] one. 
Fede you might check this to confirm. 
I will write to daniel to point this out.

Ok, this looks like an intel driver bug then.  It seems the intel driver still controls the backlight even when you switch the display mux to the radeon chip.  You'd probably need to add some logic to the switcheroo interface to have the intel driver not disable the backlight when switching the mux.

We have a similar bug already here: https://bugs.freedesktop.org/show_bug.cgi?id=61115

And yes I really hate it when hw engineers cut corners like this ...

I'm still running the bisect. Another 8 compilations to go approx.

Bisect done, I can confirm the issue is due to the same commit:

==========================
a261b246ebd552fd5d5a8ed84cc931bb821c427f is the first bad commit
commit a261b246ebd552fd5d5a8ed84cc931bb821c427f
Author: Daniel Vetter <daniel.vetter@>
Date:   Thu Jul 26 19:21:47 2012 +0200

    drm/i915: disable all crtcs at suspend time
    
    We need this to avoid confusing the hw state readout code with the cpt
    pch plls at resume time: We'd read the new pipe state (which is
    disabled), but still believe that we have a life pll connected to that
    pipe (from before the suspend). Hence properly disable pipes to clear
    out all the residual state.
    
    This has the neat side-effect that we don't enable ports prematurely
    by restoring bogus state from the saved register values.
    
    Reviewed-by: Jesse Barnes <jbarnes@>
    Signed-Off-by: Daniel Vetter <daniel.vetter@>

:040000 040000 172a95b49a63a014db9219e27b2762d35c33ebee 920e4028ba71530ca938231e7e39cde01b42d231 M	drivers
===========================

What's the next step?

Thanks!

Fede

Well I guess that our jobs as end-users is done. :)

Looking on Google for the offending commit, I bumped into the following bug report:

https://bugs.freedesktop.org/show_bug.cgi?id=59785

The last patch attached to that ticket does fix the issue for me. However I'm not sure if that is the better way to do it.

I was able to patch kernel 3.9.0-rc6 and tested it to be working correctly (at least when it comes to the backlight issue).

I hope the patch can be quickly applied, if there is no better way to do so.

Regards,


Fede

--- intel_display.c	2013-01-27 21:50:55.000000000 -0700
+++ linux-3.7.5/drivers/gpu/drm/i915/intel_display.c	2013-01-29 13:30:06.246268500 -0700
@@ -3252,9 +3252,6 @@
 	if (!intel_crtc->active)
 		return;
 
-	for_each_encoder_on_crtc(dev, crtc, encoder)
-		encoder->disable(encoder);
-
 	intel_crtc_wait_for_pending_flips(crtc);
 	drm_vblank_off(dev, pipe);
 	intel_crtc_update_cursor(crtc, false);
@@ -3270,10 +3267,6 @@
 	I915_WRITE(PF_CTL(pipe), 0);
 	I915_WRITE(PF_WIN_SZ(pipe), 0);
 
-	for_each_encoder_on_crtc(dev, crtc, encoder)
-		if (encoder->post_disable)
-			encoder->post_disable(encoder);
-
 	ironlake_fdi_disable(crtc);
 
 	intel_disable_transcoder(dev_priv, pipe);

It seems you didn't read what follows in this page :p 

As mentionned I only comment the line which disable blacklight and now it is working fine for me as well. Probably a better solution but don't know if it is a good one ....:) :

# git diff  HEAD drivers/gpu/drm/i915/intel_lvds.c: 



--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -217,7 +217,7 @@ static void intel_disable_lvds(struct intel_encoder *encoder)
                stat_reg = PP_STATUS;
        }
 
-       intel_panel_disable_backlight(dev);
+/*        intel_panel_disable_backlight(dev); */
 
        I915_WRITE(ctl_reg, I915_READ(ctl_reg) & ~POWER_TARGET_ON);
        if (wait_for((I915_READ(stat_reg) & PP_ON) == 0, 1000))

Good job anyway. If it is also working for you we might get our bug as a duplicated of 59785. 
Regards

I did see it however the comment was for a different patch, or so I thought. One is for intel_lvds.c and the other is for intel_display.c

I changed the latter.

I'll try the patch you mentioned since it is the most recent one.

This patch works too. Then again, someone should be looking into this to let us know if it is correct.

I wrote to daniel to ask him exactly that ...

I had an answer from daniel, which asked me to attach the folowing :

"The patch
itself is imo not safe since it'll break other systems where we really
want to disable the backlight. But I have an idea for a slightly
different solution. I'll attach a quick patch to the relevant bug
reports."

Regards.

Created attachment 98861 [details]
Don't clamp backlight when disabling on gen4+

Can everyone affected by this bug please test the attached patch? It hopefully fixes the backlight issues without causing problems on other systems - since on most systems we really want to disable the backlight.

(In reply to comment #26)
> Created an attachment (id=98861) [details]
> Don't clamp backlight when disabling on gen4+
> 
> Can everyone affected by this bug please test the attached patch? It
> hopefully
> fixes the backlight issues without causing problems on other systems - since
> on
> most systems we really want to disable the backlight.

Unfortunately it does not but the behavior has changed a bit so I will try to explain. In one word  the backlight seems now to be disabled later in the process. 

Before as quickly as I hit enter the screen went off, now i see the typical litle "tiring"  of the switch and one second later or so the backlight is disabled. 
An other interesting point is that now it do the same when trying to switch back to the intel driver. For one second or so I have the backlight back then it shutdown. [And in a practical point of view it makes thing words in that regards]

Look likes your patch avoid one disabling of the backlight but a second occurs after.
Regards,

I tested the patch today and I can confirm the issue is still there. Assuming the IF statement is correct, then the backlight is still being switched off at a later point.

I tried:
======================
*** ./linux/drivers/gpu/drm/i915/intel_panel.c	2013-04-20 15:01:15.000000000 +0800
--- ./intel_panel.c	2013-04-20 18:25:15.000000000 +0800
***************
*** 296,302 ****
  	struct drm_i915_private *dev_priv = dev->dev_private;
  
  	dev_priv->backlight_enabled = false;
! 	intel_panel_actually_set_backlight(dev, 0);
  
  	if (INTEL_INFO(dev)->gen >= 4) {
  		uint32_t reg, tmp;
--- 296,302 ----
  	struct drm_i915_private *dev_priv = dev->dev_private;
  
  	dev_priv->backlight_enabled = false;
! 	//intel_panel_actually_set_backlight(dev, 0);
  
  	if (INTEL_INFO(dev)->gen >= 4) {
  		uint32_t reg, tmp;

======================

Hence removing the Else statement Daniel added and 'intel_panel_actually_set_backlight(dev, 0);' which he had removed too. Nonetheless the backlight still goes off. There must be a request to switch it off somewhere down the code.

Regards,

Would something like this make any sense? I added the same check (well, inverse) which was on intel_panel.c but into intel_lvds.c.

The switch does work on my setup. I apologize if that was something horrible to do.

======================
*** ./linux/drivers/gpu/drm/i915/intel_lvds.c   2013-04-20 13:55:42.000000000 +0800
--- ./intel_lvds.c      2013-04-20 22:31:57.000000000 +0800
***************
*** 216,224 ****
                ctl_reg = PP_CONTROL;
                stat_reg = PP_STATUS;
        }
! 
!       intel_panel_disable_backlight(dev);
! 
        I915_WRITE(ctl_reg, I915_READ(ctl_reg) & ~POWER_TARGET_ON);
        if (wait_for((I915_READ(stat_reg) & PP_ON) == 0, 1000))
                DRM_ERROR("timed out waiting for panel to power off\n");
--- 216,224 ----
                ctl_reg = PP_CONTROL;
                stat_reg = PP_STATUS;
        }
!       if (INTEL_INFO(dev)->gen < 4) {
!               intel_panel_disable_backlight(dev);
!       }
        I915_WRITE(ctl_reg, I915_READ(ctl_reg) & ~POWER_TARGET_ON);
        if (wait_for((I915_READ(stat_reg) & PP_ON) == 0, 1000))
                                                              1,1           Top

*** This bug has been marked as a duplicate of bug 53111 ***

Wrong bug, blergh.

The issue here is that on normal systems we _need_ to disable the backlight (since otherwise you'll see random garbage and burning through power with an enabled backlight isn't great, either). Not disabling the backlight was the old behaviour, but simply a bug.

But on these systems here the radeong gpu doesn't have it's own backlight, so we need to somehow teach radeon/intel drivers that they need to use a different backlight driver in this case.

Did aynone know/check if the new stuff from Dave Airlie Helps this issue ?

Aximab, I have not seen any new stuff. Could you provide us a link to it?

Vanilla 3.9.6 still doesn't fix this the issue in our downstream bug, is there any progress in 3.10 or 3.11 going on on this?

https://bugs.gentoo.org/show_bug.cgi?id=458746

Maybe worth trying out some of David Arlie's branches?

http://cgit.freedesktop.org/~airlied/linux/refs/

I have not received any updates nor request about this ticket. The patch I proposed works however Daniel Vetter wanted another type of solution I believe. I have not seen any reply from him about this.

Fix present in 3.10 for the Gentoo bug.

We discovered through a git bisect that a line intel_modeset_disable(dev); was added to i915_drm_freeze in drivers/gpu/drm/i915/i915_drv.c which is called when the user switches away from Intel; since the system in question is MUX-ed the Radeon output is routed through (or near) the Intel card, therefore disabling modesetting (CRTC) causes the Radeon output to not show.

We verified that removing the added line above resolves the issue. When I was planning to file a bug about this I checked for the presence of that line in the latest kernel releases; and apparently it isn't, to my surprise the commit below appears to remove the line because disabling modesetting (CRTC) appears to no longer be needed.

http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=24576d23976746cb52e7700c4cadbf4bc1bc3472

As noted in https://bugs.gentoo.org/show_bug.cgi?id=458746 and Tom wrote removing intel_modeset_disable(dev); from sys-kernel/gentoo-sources-3.9.6 made radeon visible again. Going to 3.10.0, however, even if intel_modeset_disable(dev); line isn't present in  drivers/gpu/drm/i915/i915_drv.c disappears radeon screen again.

(In reply to jimis hol from comment #39)
> As noted in https://bugs.gentoo.org/show_bug.cgi?id=458746 and Tom wrote
> removing intel_modeset_disable(dev); from sys-kernel/gentoo-sources-3.9.6
> made radeon visible again. Going to 3.10.0, however, even if
> intel_modeset_disable(dev); line isn't present in 
> drivers/gpu/drm/i915/i915_drv.c disappears radeon screen again.

Yeah, sorry, haven't looked at the other things the patch did.

    list_for_each_entry(crtc, &dev->mode_config.crtc_list, head)
        dev_priv->display.crtc_disable(crtc);

Removing the above two CRTC disable lines should be a temporary fix for 3.10.

I think these somehow not need to be called when vga_switcheroo is being used.

Yes!! you were right. I have my "Gallium 0.4 on AMD CEDAR" radeon on my
HP G62 laptop 3.10.0-gentoo #1 SMP Sun Jul 7 09:49:39 EEST 2013 x86_64 Intel(R) Core(TM) i5 CPU M 460 @ 2.53GHz GenuineIntel GNU/Linux

again!!!

Compilation complained about some crtc variable at line 520 not used but it is normal since i removed those two lines.
Txs

So this error still happens on kernel 3.10.0-16.

This was a regression (it was working for us before), I'm not sure how bad reverting this commit would be for the users this patch affects. That being said, for us, this commit made our graphic card unusable. If we remove the commit, how bad does it affect the other users?

Since fixing this issue is taking a long time, wouldn't it be possible to remove the commit completely? I mean, for us, this is killing the graphic card with no option of getting it to work unless we manually patch the kernel.

Regards,

Fede

Jani is volunteered to add a quirk list - fixing this for real by teaching the radeon driver more smarts looks like it's no going to happen, and reverting the patch isn't cool either since that leaves ugly dirt on tons of systems where it's not needed.

Meanwhile everyone with this issue please attach the output of the dmidecode tool.

The tricky part is that vgaswitcheroo lives kind of outside of both the intel and radeon drivers so there's not really an easy way to tie it back the gpu drivers.

That said, I'm not sure how to detect whether the intel driver controls the backlight exclusively or not so we'd probably need quirks anyway.

Couldn't userspace just use the intel or acpi backlight device if the non-intel GPU doesn't provide a backlight interface?  Or does the intel driver prevent backlight control if the relevant encoder is disabled?

Created attachment 107002 [details]
dmidecode.txt

From a Gentoo user in https://bugs.gentoo.org/show_bug.cgi?id=458746

Created attachment 107004 [details]
drm/i915: do not disable backlight on vgaswitcheroo switch off

All, please test the attached patch to see if it helps.

Alex, do you see any issues with this approach, particularly on non-Intel GPUs that do provide a backlight interface?

I think it should be ok.  If the backlight is muxed, it shouldn't matter if the intel backlight controller is on and if it's not muxed, it will leave it on for the dGPU.  For non-muxed systems, we shouldn't end up switching, only powering up/down the dGPU.

Testing feedback on the patch would be appreciated to move this bug forward. Thanks.

I hoped someone would do it but ... i can try if you tell me how i apply the patch. As i see it i would manually (with copy paste) add the plus (+) lines to proper file. How to use the "patch" its a mistery to me since when i click at your attachment i read it in browser without downloading something where i could give "patch -p1 your.patch or something.

Created attachment 107028 [details]
dmidecode output

I will download and test the patch, I'll let you know once I get to test it.

Thanks!

Hi Jani,

I had to adjust your patch to my current kernel source (3.10.3-19.gec6c1d9-desktop). The lines you mentioned were not exactly at the same location. Anyway, after applying the patch, the screen still goes black while trying to do the switch.

The patch I tried earlier, was doing the check on intel_lvds.c instead in this way:

!       if (INTEL_INFO(dev)->gen < 4) {
!               intel_panel_disable_backlight(dev);
!       }

Which seemed to work, at least for me. What is the difference between setting the conditional in intel_lvds.c or intel_panel.c ?

By the way, I can't change the status of this ticket so it remains as NEEDINFO.

Here below is a copy of my version of your patch, just in case you want to make sure I did not accidentally screwed it up.

*** ./a/intel_panel.c	 2013-07-29 06:04:22.000000000 +0800
--- ./b/intel_panel.c	2013-07-29 06:10:32.000000000 +0800
***************
*** 299,305 ****
  	struct drm_i915_private *dev_priv = dev->dev_private;
  
  	dev_priv->backlight.enabled = false;
- 	intel_panel_actually_set_backlight(dev, 0);
  
  	if (INTEL_INFO(dev)->gen >= 4) {
  		uint32_t reg, tmp;
--- 299,304 ----
***************
*** 313,318 ****
--- 312,321 ----
  			tmp &= ~BLM_PCH_PWM_ENABLE;
  			I915_WRITE(BLC_PWM_PCH_CTL1, tmp);
  		}
+ 	} else {
+ 		/* pre-gen4 doesn't have a separate enable bit so we need to
+ 		 * smash the actual backlight pwm to 0 */
+ 		intel_panel_actually_set_backlight(dev, 0);
  	}
  }

Fede, I think you've used the wrong patch as the starting point. I'm checking for dev->switch_power_state == DRM_SWITCH_POWER_CHANGING, *not* the gen. Please try again with the attachment titled "drm/i915: do not disable backlight on vgaswitcheroo switch off".

This is what it should look like on 3.10, although I'd obviously prefer you tried the latest 3.11-rc.

diff --git a/drivers/gpu/drm/i915/intel_panel.c b/drivers/gpu/drm/i915/intel_panel.c
index eb5e6e9..9275169 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -298,6 +298,17 @@ void intel_panel_disable_backlight(struct drm_device *dev)
 {
 	struct drm_i915_private *dev_priv = dev->dev_private;
 
+	/*
+	 * Do not disable backlight on the vgaswitcheroo path. When switching
+	 * away from i915, the other client may depend on i915 to handle the
+	 * backlight. This will leave the backlight on unnecessarily when
+	 * another client is not activated.
+	 */
+	if (dev->switch_power_state == DRM_SWITCH_POWER_CHANGING) {
+		DRM_DEBUG_DRIVER("Skipping backlight disable on vga switch\n");
+		return;
+	}
+
 	dev_priv->backlight.enabled = false;
 	intel_panel_actually_set_backlight(dev, 0);

Yes, it seems it was the wrong one the one I downloaded. Sorry about that! I'm compiling the new patch now.

I'll let you know once I complete the test.

Ok, test done. It works. At least for me. I can't wait for the patch to arrive and be sent downstream.

Is anyone else testing this?

Thanks Jani!

Hi all, 
I just test the patch as well and it works. 
Good Job! 

(Now I have the pleasure to try to fix issue of this Bug https://bugs.freedesktop.org/show_bug.cgi?id=63935
:X)




(In reply to Fede from comment #55)
> Ok, test done. It works. At least for me. I can't wait for the patch to
> arrive and be sent downstream.
> 
> Is anyone else testing this?
> 
> Thanks Jani!

FWIW, I tested it on a 3820TG hybrid laptop (Intel Ironlake / Radeon 6550M),
and the patch works for me as well... But a limited number of times :-(
I commented on https://bugs.freedesktop.org/show_bug.cgi?id=59785 which looks like a very similar issue.

I should have mentionned that I performed this test with kernel 3.11-rc3. For wich the switch works properly.
Regards

(In reply to Aximab from comment #56)
> Hi all, 
> I just test the patch as well and it works. 
> Good Job! 
> 
> (Now I have the pleasure to try to fix issue of this Bug
> https://bugs.freedesktop.org/show_bug.cgi?id=63935
> :X)
> 
> 
> 
> 
> (In reply to Fede from comment #55)
> > Ok, test done. It works. At least for me. I can't wait for the patch to
> > arrive and be sent downstream.
> > 
> > Is anyone else testing this?
> > 
> > Thanks Jani!

After I read the last messages of Sebastien, I try to reproduce multiple switch (because the test I did was only one switch) to see if I Have the same problem.
To my surprise at the very first attempt to sswitch my all system freeze/crash with the need for an Hard reboot... 

Here is the log I found in the Kernel about it : 

Aug  5 11:57:16 laurent-debian kernel: [ 2603.122196] radeon: switched on
Aug  5 11:57:16 laurent-debian kernel: [ 2603.122876] radeon 0000:01:00.0: power state changed by ACPI to D0
Aug  5 11:57:16 laurent-debian kernel: [ 2603.162185] [drm] PCIE GART of 512M enabled (table at 0x000000000025D000).
Aug  5 11:57:16 laurent-debian kernel: [ 2603.162385] radeon 0000:01:00.0: WB enabled
Aug  5 11:57:16 laurent-debian kernel: [ 2603.162392] radeon 0000:01:00.0: fence driver on ring 0 use gpu addr 0x0000000040000c00 and cpu addr 0xffff88014f8abc00
Aug  5 11:57:16 laurent-debian kernel: [ 2603.162397] radeon 0000:01:00.0: fence driver on ring 3 use gpu addr 0x0000000040000c0c and cpu addr 0xffff88014f8abc0c
Aug  5 11:57:16 laurent-debian kernel: [ 2603.164030] radeon 0000:01:00.0: fence driver on ring 5 use gpu addr 0x000000000005c418 and cpu addr 0xffffc90008c1c418
Aug  5 11:57:16 laurent-debian kernel: [ 2603.180866] [drm] ring test on 0 succeeded in 2 usecs
Aug  5 11:57:16 laurent-debian kernel: [ 2603.180937] [drm] ring test on 3 succeeded in 1 usecs
Aug  5 11:57:16 laurent-debian kernel: [ 2603.365570] BUG: unable to handle kernel paging request at ffff88014f946000
Aug  5 11:57:16 laurent-debian kernel: [ 2603.365598] IP: [<ffffffffa0577d4f>] radeon_ring_write+0x33/0x44 [radeon]
Aug  5 11:57:16 laurent-debian kernel: [ 2603.365601] PGD 1873067 PUD 1876067 PMD 14aca7063 PTE 800000014f946161
Aug  5 11:57:16 laurent-debian kernel: [ 2603.365603] Oops: 0003 [#1] SMP 
Aug  5 11:57:16 laurent-debian kernel: [ 2603.365645] Modules linked in: usb_storage hid_generic usbhid hid parport_pc ppdev lp parport bnep rfcomm cpufreq_conservative cpufreq_userspace cpufreq_powersave cpufreq_stats binfmt_misc uinput nfsd auth_rpcgss oid_registry nfs_acl nfs lockd fscache sunrpc loop fuse arc4 brcmsmac cordic brcmutil b43 radeon mac80211 snd_hda_codec_hdmi snd_hda_codec_idt snd_hda_intel snd_hda_codec cfg80211 snd_hwdep snd_pcm i915 btusb bluetooth ssb snd_page_alloc ttm joydev mmc_core rng_core pcmcia uvcvideo pcmcia_core snd_seq drm_kms_helper acpi_cpufreq videobuf2_vmalloc videobuf2_memops snd_seq_device snd_timer drm videobuf2_core videodev hp_accel media mei_me mei lis3lv02d mperf input_polldev snd bcma coretemp psmouse i2c_i801 i2c_algo_bit iTCO_wdt i2c_core microcode hp_wmi sparse_keymap processor soundcore rfkill iTCO_vendor_support pcspkr serio_raw evdev ac button video intel_ips battery lpc_ich mfd_core wmi ext4 crc16 jbd2 mbcache sg sd_mod crc_t10dif sr_mod cdrom ahci libahci 
libata ehci_pci ehci_hcd usbcore scsi_mod thermal thermal_sys r8169 mii usb_common
Aug  5 11:57:16 laurent-debian kernel: [ 2603.365664] CPU: 0 PID: 6140 Comm: bash Not tainted 3.11.0-rc3+ #5
Aug  5 11:57:16 laurent-debian kernel: [ 2603.365665] Hardware name: Hewlett-Packard HP Pavilion dv6 Notebook PC/144A, BIOS F.23 10/21/2010
Aug  5 11:57:16 laurent-debian kernel: [ 2603.365667] task: ffff88006e315080 ti: ffff880135b8c000 task.ti: ffff880135b8c000
Aug  5 11:57:16 laurent-debian kernel: [ 2603.365686] RIP: 0010:[<ffffffffa0577d4f>]  [<ffffffffa0577d4f>] radeon_ring_write+0x33/0x44 [radeon]
Aug  5 11:57:16 laurent-debian kernel: [ 2603.365687] RSP: 0018:ffff880135b8dd38  EFLAGS: 00010202
Aug  5 11:57:16 laurent-debian kernel: [ 2603.365688] RAX: ffff88014f946000 RBX: ffff88014ff41618 RCX: 0000000000020001
Aug  5 11:57:16 laurent-debian kernel: [ 2603.365689] RDX: ffff88014f8c6000 RSI: 0000000000003dbd RDI: ffff88014ff41618
Aug  5 11:57:16 laurent-debian kernel: [ 2603.365690] RBP: 0000000000003dbd R08: ffff880135b8c000 R09: 0000000000000000
Aug  5 11:57:16 laurent-debian kernel: [ 2603.365691] R10: 000000000000b4dc R11: ffff880157c0ea10 R12: 0000000000000000
Aug  5 11:57:16 laurent-debian kernel: [ 2603.365692] R13: 0000000000000000 R14: 0000000000001010 R15: 00000000002a002a
Aug  5 11:57:16 laurent-debian kernel: [ 2603.365694] FS:  00007f01f2d07700(0000) GS:ffff880157c00000(0000) knlGS:0000000000000000
Aug  5 11:57:16 laurent-debian kernel: [ 2603.365695] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Aug  5 11:57:16 laurent-debian kernel: [ 2603.365696] CR2: ffff88014f946000 CR3: 000000014ac03000 CR4: 00000000000007f0
Aug  5 11:57:16 laurent-debian kernel: [ 2603.365696] Stack:
Aug  5 11:57:16 laurent-debian kernel: [ 2603.365699]  ffff88014ff41618 ffff88014ff40000 ffffffffa058dc6b ffff88014ff40000
Aug  5 11:57:16 laurent-debian kernel: [ 2603.365701]  ffff88014ff41618 0000000040000a00 0000000000000000 0000000000001010
Aug  5 11:57:16 laurent-debian kernel: [ 2603.365703]  ffffffffa058d4ca ffff88014ff40000 000000000000000a 0000000000000063
Aug  5 11:57:16 laurent-debian kernel: [ 2603.365703] Call Trace:
Aug  5 11:57:16 laurent-debian kernel: [ 2603.365726]  [<ffffffffa058dc6b>] ? r600_uvd_ring_test+0x65/0xfc [radeon]
Aug  5 11:57:16 laurent-debian kernel: [ 2603.365747]  [<ffffffffa058d4ca>] ? r600_uvd_rbc_start+0x128/0x204 [radeon]
Aug  5 11:57:16 laurent-debian kernel: [ 2603.365767]  [<ffffffffa058d917>] ? r600_uvd_init+0x353/0x384 [radeon]
Aug  5 11:57:16 laurent-debian kernel: [ 2603.365787]  [<ffffffffa05a6dfd>] ? evergreen_startup+0x177a/0x17e5 [radeon]
Aug  5 11:57:16 laurent-debian kernel: [ 2603.365807]  [<ffffffffa05a6eaf>] ? evergreen_resume+0x47/0x6e [radeon]
Aug  5 11:57:16 laurent-debian kernel: [ 2603.365818]  [<ffffffffa0555725>] ? radeon_resume_kms+0x75/0x165 [radeon]
Aug  5 11:57:16 laurent-debian kernel: [ 2603.365829]  [<ffffffffa055588d>] ? radeon_switcheroo_set_state+0x78/0xd7 [radeon]
Aug  5 11:57:16 laurent-debian kernel: [ 2603.365833]  [<ffffffff8127d191>] ? vga_switchon+0x2c/0x37
Aug  5 11:57:16 laurent-debian kernel: [ 2603.365835]  [<ffffffff8127d363>] ? vga_switchto_stage1+0x1c/0x28
Aug  5 11:57:16 laurent-debian kernel: [ 2603.365837]  [<ffffffff8127da38>] ? vga_switcheroo_debugfs_write+0x25f/0x307
Aug  5 11:57:16 laurent-debian kernel: [ 2603.365841]  [<ffffffff81114dcf>] ? __sb_start_write+0xae/0xde
Aug  5 11:57:16 laurent-debian kernel: [ 2603.365842]  [<ffffffff811147a0>] ? fput+0xe/0x8d
Aug  5 11:57:16 laurent-debian kernel: [ 2603.365844]  [<ffffffff81113235>] ? vfs_write+0xa7/0x10b
Aug  5 11:57:16 laurent-debian kernel: [ 2603.365846]  [<ffffffff81113873>] ? SyS_write+0x41/0x75
Aug  5 11:57:16 laurent-debian kernel: [ 2603.365849]  [<ffffffff8138f4e9>] ? system_call_fastpath+0x16/0x1b
Aug  5 11:57:16 laurent-debian kernel: [ 2603.365865] Code: 48 89 fb 7f 15 48 c7 c6 f3 30 61 a0 48 c7 c7 b0 a5 5e a0 31 c0 e8 40 2e d4 ff 8b 43 30 48 8b 53 08 8d 48 01 48 8d 04 82 89 4b 30 <89> 28 8b 43 64 ff 4b 44 21 43 30 ff 4b 40 5b 5d c3 83 7e 78 02 
Aug  5 11:57:16 laurent-debian kernel: [ 2603.365882] RIP  [<ffffffffa0577d4f>] radeon_ring_write+0x33/0x44 [radeon]
Aug  5 11:57:16 laurent-debian kernel: [ 2603.365882]  RSP <ffff880135b8dd38>
Aug  5 11:57:16 laurent-debian kernel: [ 2603.365883] CR2: ffff88014f946000
Aug  5 11:57:16 laurent-debian kernel: [ 2603.365885] ---[ end trace 4186fc62f66daeb3 ]---


However This is likely to be unrelated to this bug (Just the fact that the recent radeon driver doesn't in that state with my spec ... which is kind of an even bigger problem but unrelated.n Because I get this message at boot


[   27.805974] [drm:r600_uvd_ring_test] *ERROR* radeon: ring 5 test failed (0xCAFEDEAD)
[   27.806081] [drm:evergreen_startup] *ERROR* radeon: error initializing UVD (-22).



As I said this is likely to be noise and unrelated to the bug .... 
Regards,
Laurent

@ Laurent : I opened a dedicated kernel bug report for my own problem here : https://bugzilla.kernel.org/show_bug.cgi?id=60606.
Long story short, my issue is likely HW specific and someone found a workaround which actually works for me as well, even for multiple switches :-)

For your UVD initialization error, the usual suspect is the lack of a proper firmware...

(In reply to jimis hol from comment #49)
> I hoped someone would do it but ... i can try if you tell me how i apply the
> patch.

Right click the link and save the attachment (or copy the contents from your browser) to a file in the kernel folder (on Gentoo, something like /usr/src/linux/bug55311-attachment107004 [details].patch) and then go to that folder (on Gentoo, /usr/src/linux/) and run `patch -p1 < bug55311-attachment107004 [details].patch`.

Alternatively, only on Gentoo, you can place it in /etc/portage/patches/sys-kernel/gentoo-sources/ and emerge the kernel package again; this ensures that if the patch work it will be applied to future kernels automatically so you don't have to do this manually every time.

Patch as it appears at Comment 53 WORKS for 3.10.0 Laptop heat promblems, systemd of gnome at gentoo and huge update world do not let me time to try newer kernel for now. Tom i was not sure from where to where i should copy the attachment so i manually entered the few plus (+) lines without + ofcourse. About radeon i always have the dream that some day i would be able to adjust brightness. I can do it only with intel. If it is somewhere near this bug pls have some thought about it too. Thank you all.

(In reply to jimis hol from comment #62)
> Tom i was not sure from where to where i should copy
> the attachment 

You could just copy the entire it works ;)...

Patch is merged to drm-intel-fixes:

commit 428cf5a505c5c81789ad0a7551ba7644ff3d1523
Author: Jani Nikula <jani.nikula@intel.com>
Date:   Thu Jul 25 14:31:30 2013 +0300

    drm/i915: do not disable backlight on vgaswitcheroo switch off

Well guys sorry to be a an atmosphere killer but I still get kernel OOPS each time I try to switch to the radeon driver (kernel 3.11rc5) ...
Should I open a specific BUG report ? 




Here is the log just following the echo DIS > bla command (in console) : 
 radeon: switched on
 radeon 0000:01:00.0: power state changed by ACPI to D0
 [drm] PCIE GART of 512M enabled (table at 0x000000000025D000).
 radeon 0000:01:00.0: WB enabled
 radeon 0000:01:00.0: fence driver on ring 0 use gpu addr 0x0000000040000c00 and cpu addr 0xffff8801518e4c00
 radeon 0000:01:00.0: fence driver on ring 3 use gpu addr 0x0000000040000c0c and cpu addr 0xffff8801518e4c0c
radeon 0000:01:00.0: fence driver on ring 5 use gpu addr 0x000000000005c418 and cpu addr 0xffffc9000929c418
[drm] ring test on 0 succeeded in 2 usecs
[drm] ring test on 3 succeeded in 1 usecs
 BUG: unable to handle kernel paging request at ffff880151b72000
 IP: [<ffffffffa0691d1b>] radeon_ring_write+0x33/0x44 [radeon]
PGD 1873067 PUD 1876067 PMD 134e67063 PTE 8000000151b72161
 Oops: 0003 [#1] SMP 
 Modules linked in: parport_pc ppdev bnep lp parport rfcomm cpufreq_conservative cpufreq_userspace cpufreq_powersave cpufreq_stats binfmt_misc uinput nfsd auth_rpcgss oid_registry nfs_acl nfs lockd fscache sunrpc loop fuse radeon i915 arc4 brcmsmac ttm cordic brcmutil drm_kms_helper b43 drm snd_hda_codec_hdmi mac80211 snd_hda_codec_idt snd_hda_intel snd_hda_codec snd_hwdep snd_pcm cfg80211 snd_page_alloc btusb uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_core bluetooth videodev snd_seq ssb mmc_core mei_me media snd_seq_device snd_timer snd rng_core coretemp pcmcia joydev psmouse iTCO_wdt mei hp_wmi acpi_cpufreq pcmcia_core microcode i2c_i801 hp_accel sparse_keymap iTCO_vendor_support mperf lpc_ich soundcore serio_raw evdev lis3lv02d bcma i2c_algo_bit i2c_core rfkill processor mfd_core pcspkr button input_polldev intel_ips battery video ac wmi ext4 crc16 jbd2 mbcache hid_generic usbhid hid sg sr_mod cdrom sd_mod crc_t10dif ahci libahci libata ehci_
pci ehci_hcd scsi_mod thermal thermal_sys usbcore r8169 mii usb_common
 CPU: 1 PID: 4115 Comm: bash Not tainted 3.11.0-rc5+ #7
 Hardware name: Hewlett-Packard HP Pavilion dv6 Notebook PC/144A, BIOS F.23 10/21/2010
task: ffff880135ae37c0 ti: ffff880135b58000 task.ti: ffff880135b58000
 RIP: 0010:[<ffffffffa0691d1b>]  [<ffffffffa0691d1b>] radeon_ring_write+0x33/0x44 [radeon]
 RSP: 0018:ffff880135b59d38  EFLAGS: 00010202
 RAX: ffff880151b72000 RBX: ffff880151039618 RCX: 0000000000020001
 RDX: ffff880151af2000 RSI: 0000000000003dbd RDI: ffff880151039618
 RBP: 0000000000003dbd R08: ffff880135b58000 R09: 0000000000000000
 R10: 0000000000000000 R11: 0000000000000020 R12: 0000000000000000
 R13: 0000000000000000 R14: 0000000000001010 R15: 00000000002a002a
 FS:  00007fd90cb5b700(0000) GS:ffff880157c40000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 CR2: ffff880151b72000 CR3: 0000000150b57000 CR4: 00000000000007e0
Stack:
  ffff880151039618 ffff880151038000 ffffffffa06a7d36 ffff880151038000
  ffff880151039618 0000000040000a00 0000000000000000 0000000000001010
  ffffffffa06a74c6 ffff880151038000 000000000000000a 0000000000000063
Call Trace:
  [<ffffffffa06a7d36>] ? r600_uvd_ring_test+0x65/0xfc [radeon]
  [<ffffffffa06a74c6>] ? r600_uvd_rbc_start+0x128/0x204 [radeon]
  [<ffffffffa06a79e2>] ? r600_uvd_init+0x35d/0x38e [radeon]
  [<ffffffffa06c0fcd>] ? evergreen_startup+0x177a/0x17e5 [radeon]
  [<ffffffffa06c107f>] ? evergreen_resume+0x47/0x6e [radeon]
  [<ffffffffa066f73f>] ? radeon_resume_kms+0x75/0x165 [radeon]
  [<ffffffffa066f8a7>] ? radeon_switcheroo_set_state+0x78/0xd7 [radeon]
  [<ffffffff8127d52f>] ? vga_switchon+0x2c/0x37
  [<ffffffff8127d701>] ? vga_switchto_stage1+0x1c/0x28
  [<ffffffff8127ddd6>] ? vga_switcheroo_debugfs_write+0x25f/0x307
  [<ffffffff81114fd6>] ? __sb_start_write+0xae/0xde
  [<ffffffff811149a7>] ? fput+0xe/0x8d
  [<ffffffff8111343c>] ? vfs_write+0xa7/0x10b
  [<ffffffff81113a7a>] ? SyS_write+0x41/0x75
  [<ffffffff8138f7a9>] ? system_call_fastpath+0x16/0x1b
 Code: 48 89 fb 7f 15 48 c7 c6 05 e1 72 a0 48 c7 c7 b0 55 70 a0 31 c0 e8 74 0e e2 ff 8b 43 30 48 8b 53 08 8d 48 01 48 8d 04 82 89 4b 30 <89> 28 8b 43 64 ff 4b 44 21 43 30 ff 4b 40 5b 5d c3 83 7e 78 02 
RIP  [<ffffffffa0691d1b>] radeon_ring_write+0x33/0x44 [radeon]
 RSP <ffff880135b59d38>
CR2: ffff880151b72000
 ---[ end trace e47088b73be36227 ]---
Aug 16 15:02:56 laurent-debian shutdown[4140]: shutting down for system halt

I opened a dedicated report Here : https://bugzilla.kernel.org/show_bug.cgi?id=60759

(In reply to Aximab from comment #66)
> I opened a dedicated report Here :
> https://bugzilla.kernel.org/show_bug.cgi?id=60759

Thanks, it does seem like a different bug from this one.

Is it possible that this same bug happens between nouveau and i915?
I have a macbookpro9,1 running a discrete nvidia and an igd intel, I boot a Debian and starts always with the DIS card, however, switching to the intel one only gives me a black screen.
This gives me 15 seconds of a black screen

echo IGD > switch && sleep 15 && echo DIS > switch

This is how the system starts:
# cat /sys/kernel/debug/vgaswitcheroo/switch 
0:IGD: :Pwr:0000:00:02.0
1:DIS:+:Pwr:0000:01:00.0
2:DIS-Audio: :Pwr:0000:01:00.1

I have compiled several kernels from 3.6.10 to current linux-stable:v3.12-rc2 but they all show the same symptoms.

Drivers are nouveau and i915 and there are no oops or weird kernel messages, all looks normal in dmesg

Even if status of this bug is "RESOLVED CODE_FIX" I would like to report, that problem reappeared.
I updated world on gentoo staying with gentoo-sources-3.10.0 where i applied succesfully the patch of comment 53. Unfortunately after some "update world", that involved xorg-server and video intel and radeon drivers, i got black screen when i try to switch to radeon (assuming no blacklight). I updated to 3.11.2, i see the patch at intel_panel.c but still no blacklight with radeon after switch. I tried deleting 

list_for_each_entry(crtc, &dev->mode_config.crtc_list, head)
        dev_priv->display.crtc_disable(crtc);

lines of i915_drv.c, even getting

 DRM_DEBUG_DRIVER("Skipping backlight disable on vga switch\n");
		return;

out of "if" statement at intel_panel.c without luck.
I tried downgrading intel by masking >x11-drivers/xf86-video-intel-2.21.13
and failing that, i downgraded xorg-server with #>x11-base/xorg-server-1.14.2 .
No luck. Seems, once again, that on switching to radeon backlight of intel sets off.
I also tried adding (after switching) intel backlight at xorg.conf.d with
 Section "Device"
  Identifier "video"
  Driver "radeon"
Option "Backlight" "intel_backlight"
EndSection

Of cource the "switch" file at vgaswitcheroo do exist.
As i noted, initially when problem reappeared, i had the same working patched kernel 3.10.0. So, maybe it isnt kernel's issue. If so, and if someone reads this, pls open a proper bug or inform me to do so here or in bugs.gentoo.org.
Thank you

I dont know id it is relevant but i get these warnings by dmesg
[    2.020262] ACPI Warning: \_SB_.PCI0.GFX0._DSM: Argument #4 type mismatch - Found [Integer], ACPI requires [Package] (20130517/nsarguments-95)
[    2.020345] ACPI Warning: \_SB_.PCI0.GFX0._DSM: Argument #4 type mismatch - Found [Integer], ACPI requires [Package] (20130517/nsarguments-95)
[    3.258350] ACPI Warning: 0x0000000000004000-0x000000000000401f SystemIO conflicts with Region \_SB_.PCI0.SBUS.SMBI 1 (20130517/utaddress-251)

Commending the line

 intel_panel_disable_backlight(dev);

at drivers/gpu/drm/i915/intel_lvds.c
despite my hopes didn't solved the issue

About comments 69,70,71 of mine, I have to report that having a dual system with windows7 I tried to login there and faced the same problem. After 2 days of trying to enter to stable intel graphics i am at a situation where as soon as windows discover my mobile HD 5470 they give me a black screen. So it is very possible i have a hardware failure even if i didnt used radeon much.
Sorry for bothering you by my last comments.

I have hybrid ATI 5650/Intel Ironlake muxed system, and when I switch to radeon, backlight stays enabled now (looks like it was fixed by patch from that bug), but I can't change in at all, and it is down when I do suspend cycle.
lspci -vv:
...
00:02.0 VGA compatible controller: Intel Corporation Core Processor Integrated Graphics Controller (rev 18) (prog-if 00 [VGA controller])
	Subsystem: Acer Incorporated [ALI] Device 0359
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin A routed to IRQ 45
	Region 0: Memory at d8000000 (64-bit, non-prefetchable) [size=4M]
	Region 2: Memory at c0000000 (64-bit, prefetchable) [size=256M]
	Region 4: I/O ports at 4050 [size=8]
	Expansion ROM at <unassigned> [disabled]
	Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
		Address: fee0f00c  Data: 4122
	Capabilities: [d0] Power Management version 2
		Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [a4] PCI Advanced Features
		AFCap: TP+ FLR+
		AFCtrl: FLR-
		AFStatus: TP-
	Kernel driver in use: i915
	Kernel modules: i915
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Madison [Mobility Radeon HD 5650/5750 / 6530M/6550M] (rev ff) (prog-if ff)
	!!! Unknown header type 7f
	Kernel driver in use: radeon
	Kernel modules: radeon
...
ls /sys/class/backlight:
acpi_video0  acpi_video1  intel_backlight
Neither of them work. What can I do to help tracing this bug further? Should I open another one?

(In reply to Nikolay Amiantov from comment #73)
> I have hybrid ATI 5650/Intel Ironlake muxed system, and when I switch to
> radeon, backlight stays enabled now (looks like it was fixed by patch from
> that bug), but I can't change in at all, and it is down when I do suspend
> cycle.
> lspci -vv:
> ...
> 00:02.0 VGA compatible controller: Intel Corporation Core Processor
> Integrated Graphics Controller (rev 18) (prog-if 00 [VGA controller])
>       Subsystem: Acer Incorporated [ALI] Device 0359
>       Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
> Stepping- SERR- FastB2B- DisINTx+
>       Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort-
> <MAbort- >SERR- <PERR- INTx-
>       Latency: 0
>       Interrupt: pin A routed to IRQ 45
>       Region 0: Memory at d8000000 (64-bit, non-prefetchable) [size=4M]
>       Region 2: Memory at c0000000 (64-bit, prefetchable) [size=256M]
>       Region 4: I/O ports at 4050 [size=8]
>       Expansion ROM at <unassigned> [disabled]
>       Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
>               Address: fee0f00c  Data: 4122
>       Capabilities: [d0] Power Management version 2
>               Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA
> PME(D0-,D1-,D2-,D3hot-,D3cold-)
>               Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
>       Capabilities: [a4] PCI Advanced Features
>               AFCap: TP+ FLR+
>               AFCtrl: FLR-
>               AFStatus: TP-
>       Kernel driver in use: i915
>       Kernel modules: i915
> 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI]
> Madison [Mobility Radeon HD 5650/5750 / 6530M/6550M] (rev ff) (prog-if ff)
>       !!! Unknown header type 7f
>       Kernel driver in use: radeon
>       Kernel modules: radeon
> ...
> ls /sys/class/backlight:
> acpi_video0  acpi_video1  intel_backlight
> Neither of them work. What can I do to help tracing this bug further? Should
> I open another one?

Please open a new bug.

I have about a month i can't bring back from black screen my CEDAR. But last times it was worked, in order to be able to change brightness i had to put ON both cards. So, if you are lucky to use your dgpu try echo "ON" > /sys/kernel/debug/vgaswitcheroo/switch

I confirm the issue reported by jimis hol. Running kernel 3.18.5 on Arch Linux.