https://bugzilla.kernel.org/show_bug.cgi?id=61891
Bug ID: 61891 Summary: Cannot switch off Radeon 6400M with vgaswitcheroo Product: Drivers Version: 2.5 Kernel Version: 3.12-rc1 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: madcatx@atlas.cz Regression: No
Created attachment 109251 --> https://bugzilla.kernel.org/attachment.cgi?id=109251&action=edit dmesg
I use systemd's tmpfiles to power off the Radeon DIS early during boot to save power. This works fine with kernel 3.11.1 but it breaks with 3.12-rc1. I removed the systemd rule and tried to power the card off manually (echo OFF > /sys/kernel/debug/vgaswitcheroo/switch). I got a kernel warning and vga_switcheroo died. See the attached file for full dmesg dump.
https://bugzilla.kernel.org/show_bug.cgi?id=61891
madcatx@atlas.cz changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |madcatx@atlas.cz Regression|No |Yes
https://bugzilla.kernel.org/show_bug.cgi?id=61891
Alex Deucher alexdeucher@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |alexdeucher@gmail.com
--- Comment #1 from Alex Deucher alexdeucher@gmail.com --- Can you bisect?
https://bugzilla.kernel.org/show_bug.cgi?id=61891
Dave Airlie airlied@linux.ie changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |airlied@linux.ie
--- Comment #2 from Dave Airlie airlied@linux.ie --- wierd I'm guessing something in acpi is causing a hot unplug we haven't seen before, or did we hook up the radeon release method and just see this now?
https://bugzilla.kernel.org/show_bug.cgi?id=61891
--- Comment #3 from madcatx@atlas.cz --- Created attachment 109261 --> https://bugzilla.kernel.org/attachment.cgi?id=109261&action=edit Error on hard freeze
https://bugzilla.kernel.org/show_bug.cgi?id=61891
--- Comment #4 from madcatx@atlas.cz --- Bisecting of git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git revealed that the first bad commit is "bbd34fcdd1b201e996235731a7c98fd5197d9e51". I was getting hard freezes from which the only escape was a hard reset during bisecting, see the attached image for the error message.
https://bugzilla.kernel.org/show_bug.cgi?id=61891
--- Comment #5 from madcatx@atlas.cz --- Kernel 3.12-rc2 seems to fix the issue for me. (The kernel still crashes with the patches for powerxpress dynamic power switching, but that's obviously another story).
https://bugzilla.kernel.org/show_bug.cgi?id=61891
--- Comment #6 from madcatx@atlas.cz --- Created attachment 113521 --> https://bugzilla.kernel.org/attachment.cgi?id=113521&action=edit dmesg from 3.12 final
https://bugzilla.kernel.org/show_bug.cgi?id=61891
--- Comment #7 from madcatx@atlas.cz --- I just updated to 3.12 final and it is happening again. The problem seemed to be fixed in 3.12-rc2 and I switched back to stable releases then. New dmesg log attached...
https://bugzilla.kernel.org/show_bug.cgi?id=61891
--- Comment #8 from Alex Deucher alexdeucher@gmail.com --- Can you bisect?
https://bugzilla.kernel.org/show_bug.cgi?id=61891
--- Comment #9 from Matthieu Baerts matttbe@gmail.com --- Hello,
As Alex said on FreeDesktop's bugzilla, it looks like this bug might be a duplicate of this one: https://bugs.freedesktop.org/show_bug.cgi?id=70687
There, we can find another call trace of this crash and a bisect. Maybe it can help :-)
https://bugzilla.kernel.org/show_bug.cgi?id=61891
--- Comment #10 from Alex Deucher alexdeucher@gmail.com --- see also: https://bugs.freedesktop.org/show_bug.cgi?id=71930
https://bugzilla.kernel.org/show_bug.cgi?id=61891
--- Comment #11 from madcatx@atlas.cz --- I tried to revert my git repo to 3.12-rc2 tag to see if I could do another round of bisecting but it turns out that even 3.12-rc2 was broken. I don't know I missed that. It seems that the previously pinpointed commit is the cause. Unfortunately the commit won't revert cleanly no matter what I try...
https://bugzilla.kernel.org/show_bug.cgi?id=61891
Alex Deucher alexdeucher@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |rjw@sisk.pl
--- Comment #12 from Alex Deucher alexdeucher@gmail.com --- See also: https://bugzilla.kernel.org/show_bug.cgi?id=65761 https://bugs.freedesktop.org/show_bug.cgi?id=70687
From: https://bugs.freedesktop.org/show_bug.cgi?id=70687
"I seem to have discovered the root of the issue.
I've just built 3.13-rc5 kernel which has the dynamic powering of the discrete gpu and all hell broke loose.
I've narrowed the error down to the pci hotplug driver. My machine loads shpchp pci hotplug driver from what I can see in lsmod output. But the trick is, that there is another pci hotplug driver, acpi pci hotplug one, which seems to break all hell loose here. Disabling it seems to fix everything for me, at least on kernel 3.13.
# CONFIG_HOTPLUG_PCI_ACPI is not set
This kernel config option is the culprit for this, and that also can be seen from my backtrace:
[ 22.731998] [<ffffffff81343cb1>] ? acpiphp_check_bridge+0x72/0x88
So the trick behind this is that acpi pci hotplug driver conflicts with shpchp one that my machine uses. And since it is a builtin driver, and can't be built as module it is always loaded. The other possibility is that this machine doesn't support acpi hotplug, but does support shpc pci hotplug. We need a kernel workarround so that acpi pci hotplug is disabled and out of the way when shpc pci hotplug is enabled."
Rafael, any ideas?
https://bugzilla.kernel.org/show_bug.cgi?id=61891
--- Comment #13 from madcatx@atlas.cz --- "acpiphp.disable=1" in the kernel bootline fixes the problem for me. The Radeon is reported as off in vgaswitcheroo and the laptop draws less power. The DIS even powers up and down correctly with DRI_PRIME.
Acpidump provided
https://bugzilla.kernel.org/show_bug.cgi?id=61891
--- Comment #14 from madcatx@atlas.cz --- Created attachment 119691 --> https://bugzilla.kernel.org/attachment.cgi?id=119691&action=edit Acpidump for HP ProBook4730s
https://bugzilla.kernel.org/show_bug.cgi?id=61891
Rafael J. Wysocki rjw@rjwysocki.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |rjw@rjwysocki.net
--- Comment #15 from Rafael J. Wysocki rjw@rjwysocki.net --- Yes, this most likely is related to PCI hotplug, because ACPIPHP now handles devices it didn't try to handle before. This means that if there are ACPI hotplug events for those devices, it will try to handle them.
What happens is probably that there is a bus check or device check causing ACPIPHP to rescan the bus and during that bus rescan it finds a device that doesn't respond (no wonder), so it decides that the device has gone and tries to remove it.
The solution might be to tell ACPIPHP somehow that the device in question didn't really go away. Or to ignore that device entirely.
I guess we may use a flag in struct acpi_device set for the graphics adapter's ACPI companion by the radeon driver during probe. Or something like that.
https://bugzilla.kernel.org/show_bug.cgi?id=61891
Rafael J. Wysocki rjw@rjwysocki.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |NEEDINFO
--- Comment #16 from Rafael J. Wysocki rjw@rjwysocki.net --- madcatx@atlas.cz: Can you please check if reverting commit ab1225901da2 makes any difference for you?
https://bugzilla.kernel.org/show_bug.cgi?id=61891
--- Comment #17 from Rafael J. Wysocki rjw@rjwysocki.net --- Can anyone please point me to the switcheroo code removing power from the radeon device?
https://bugzilla.kernel.org/show_bug.cgi?id=61891
--- Comment #18 from Alex Deucher alexdeucher@gmail.com --- See drivers/gpu/drm/radeon/radeon_atpx_handler.c radeon_atpx_set_discrete_state() is the specific function that calls the ACPI method to power off the dGPU.
https://bugzilla.kernel.org/show_bug.cgi?id=61891
--- Comment #19 from Rafael J. Wysocki rjw@rjwysocki.net --- Thanks. And where is atpx->handler set?
https://bugzilla.kernel.org/show_bug.cgi?id=61891
--- Comment #20 from Rafael J. Wysocki rjw@rjwysocki.net --- OK, I see. The method is called "ATPX" and I suppose it is device-specific?
https://bugzilla.kernel.org/show_bug.cgi?id=61891
--- Comment #21 from Alex Deucher alexdeucher@gmail.com --- ATPX is the AMD specific switching interface for AMD/AMD and AMD/Intel PowerXpress laptops.
https://bugzilla.kernel.org/show_bug.cgi?id=61891
--- Comment #22 from Alex Deucher alexdeucher@gmail.com --- Nvidia/Nvidia and Nvidia/Intel laptops use a different interface (called DSM I think).
https://bugzilla.kernel.org/show_bug.cgi?id=61891
--- Comment #23 from madcatx@atlas.cz --- I created a patch file for commit ab1225901da2 ("Revert ACPI hotplug...") and applied it with -R onto 3.13-rc5 source, but it didn't change anything.
https://bugzilla.kernel.org/show_bug.cgi?id=61891
--- Comment #24 from Rafael J. Wysocki rjw@rjwysocki.net --- Created attachment 119791 --> https://bugzilla.kernel.org/attachment.cgi?id=119791&action=edit ACPIPHP / radeon: Avoid removing devices that are not really gone
Maybe something like this helps (for radeon).
Totally untested, may kill your hamster pet.
https://bugzilla.kernel.org/show_bug.cgi?id=61891
--- Comment #25 from Rafael J. Wysocki rjw@rjwysocki.net --- No, it won't help, sorry.
https://bugzilla.kernel.org/show_bug.cgi?id=61891
Rafael J. Wysocki rjw@rjwysocki.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #119791|0 |1 is obsolete| |
--- Comment #26 from Rafael J. Wysocki rjw@rjwysocki.net --- Created attachment 119801 --> https://bugzilla.kernel.org/attachment.cgi?id=119801&action=edit ACPIPHP / radeon: Avoid removing devices that are not really gone, v2
Please try this one instead (hamster pet disclaimer still applies).
https://bugzilla.kernel.org/show_bug.cgi?id=61891
--- Comment #27 from madcatx@atlas.cz --- Applied onto 3.13-rc5, unfortunately this does not fix the problem (dmesg attached). Also KDM failed to start with this patch applied, I didn't try to start X manually...
https://bugzilla.kernel.org/show_bug.cgi?id=61891
--- Comment #28 from madcatx@atlas.cz --- Created attachment 119811 --> https://bugzilla.kernel.org/attachment.cgi?id=119811&action=edit Dmesg with fix v2 applied.
https://bugzilla.kernel.org/show_bug.cgi?id=61891
Rafael J. Wysocki rjw@rjwysocki.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #119801|0 |1 is obsolete| |
--- Comment #29 from Rafael J. Wysocki rjw@rjwysocki.net --- Created attachment 119821 --> https://bugzilla.kernel.org/attachment.cgi?id=119821&action=edit ACPIPHP / radeon: Avoid removing devices that are not really gone, v3
This is a slightly modified version of the patch that should give us a bit more debug information.
Please apply it instead of the previous one, retest and attach dmesg.
https://bugzilla.kernel.org/show_bug.cgi?id=61891
Mike Lothian mike@fireburn.co.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mike@fireburn.co.uk
--- Comment #30 from Mike Lothian mike@fireburn.co.uk --- Created attachment 119831 --> https://bugzilla.kernel.org/attachment.cgi?id=119831&action=edit Dmesg with patch 3
My whole system stutters when the card is being powered up / down
This is with runpm=1
https://bugzilla.kernel.org/show_bug.cgi?id=61891
--- Comment #31 from Mike Lothian mike@fireburn.co.uk --- Yikes after testing this patch the laptop complains that there is no boot disk attached to the system.
I'm trying sysrescuecd now
https://bugzilla.kernel.org/show_bug.cgi?id=61891
--- Comment #32 from Mike Lothian mike@fireburn.co.uk --- Created attachment 119841 --> https://bugzilla.kernel.org/attachment.cgi?id=119841&action=edit Dmesg from SysRescueCD
I'm thinking either something has happened to the SSD or the controller
Also when X starts the screen goes blank and I don't know if the system remains responsive or not
https://bugzilla.kernel.org/show_bug.cgi?id=61891
--- Comment #33 from Mike Lothian mike@fireburn.co.uk --- The drive shows up fine on another system so it looks like something's happened to the controller or its not being initialized properly. Is there anything obvious in the above dmesg that might suggest the problem
https://bugzilla.kernel.org/show_bug.cgi?id=61891
--- Comment #34 from Mike Lothian mike@fireburn.co.uk --- Looks like leaving the laptop unplugged with the battery out for a wee while sorted the issue (phew)
Are there any other patches that need testing?
https://bugzilla.kernel.org/show_bug.cgi?id=61891
--- Comment #35 from madcatx@atlas.cz --- Created attachment 119861 --> https://bugzilla.kernel.org/attachment.cgi?id=119861&action=edit dmesg with v3 fix applied on clean 3.13-rc5
https://bugzilla.kernel.org/show_bug.cgi?id=61891
--- Comment #36 from Rafael J. Wysocki rjw@rjwysocki.net --- Thanks! Evidently, the power_removed flag is set for a wrong device (i.e. not the one the hotplug events are signaled for).
Please attach the output of "ls -lR /sys/devices/LNXSYSTM:00/" from your system.
https://bugzilla.kernel.org/show_bug.cgi?id=61891
--- Comment #37 from madcatx@atlas.cz --- Created attachment 119871 --> https://bugzilla.kernel.org/attachment.cgi?id=119871&action=edit Output of "ls -lR /sys/devices/LNXSYSTM:00/"
https://bugzilla.kernel.org/show_bug.cgi?id=61891
--- Comment #38 from Rafael J. Wysocki rjw@rjwysocki.net --- @Mike: I have no idea why the system behaves like that with the patch applied, sorry about that.
At this point I need to figure out how this all thing is supposed to work and that doesn't appear to be straightforward.
https://bugzilla.kernel.org/show_bug.cgi?id=61891
--- Comment #39 from Mike Lothian mike@fireburn.co.uk --- Created attachment 119881 --> https://bugzilla.kernel.org/attachment.cgi?id=119881&action=edit Output of "ls -lR /sys/devices/LNXSYSTM:00/"
In case mine is different
https://bugzilla.kernel.org/show_bug.cgi?id=61891
--- Comment #40 from Rafael J. Wysocki rjw@rjwysocki.net --- (In reply to madcatx from comment #37)
Created attachment 119871 [details] Output of "ls -lR /sys/devices/LNXSYSTM:00/"
Thanks!
Please do: cat /sys/devices/LNXSYSTM:00/device:00/PNP0A08:00/LNXVIDEO:01/path cat /sys/devices/LNXSYSTM:00/device:00/PNP0A08:00/device:01/LNXVIDEO:00/path
and post the output.
https://bugzilla.kernel.org/show_bug.cgi?id=61891
--- Comment #41 from Rafael J. Wysocki rjw@rjwysocki.net --- (In reply to Mike Lothian from comment #39)
Created attachment 119881 [details] Output of "ls -lR /sys/devices/LNXSYSTM:00/"
In case mine is different
It is different, but the layout seems to be analogous.
In your case the files of interest are: /sys/devices/LNXSYSTM:00/device:00/PNP0A08:00/device:2f/LNXVIDEO:00/path /sys/devices/LNXSYSTM:00/device:00/PNP0A08:00/LNXVIDEO:01/path
In both cases LNXVIDEO:00 and LNXVIDEO:01 seem to be the Radeon and the Intel graphics, respectively.
If that's the case, the attached dmesg output means that the power_removed flag in the patch is set for the Intel graphics, but the hotplug event is generated for the Radeon. I'm not sure why at the moment.
https://bugzilla.kernel.org/show_bug.cgi?id=61891
--- Comment #42 from Rafael J. Wysocki rjw@rjwysocki.net --- OK, so GFX0 is the Intel graphics and that's the one having the ATPX method.
https://bugzilla.kernel.org/show_bug.cgi?id=61891
--- Comment #43 from madcatx@atlas.cz --- "cat /sys/devices/LNXSYSTM:00/device:00/PNP0A08:00/LNXVIDEO:01/path" _SB_.PCI0.GFX0
"cat /sys/devices/LNXSYSTM:00/device:00/PNP0A08:00/device:01/LNXVIDEO:00/path" _SB_.PCI0.PEGP.DGFX
https://bugzilla.kernel.org/show_bug.cgi?id=61891
--- Comment #44 from Mike Lothian mike@fireburn.co.uk --- These are my two:
cat /sys/devices/LNXSYSTM:00/device:00/PNP0A08:00/device:2f/LNXVIDEO:00/path _SB_.PCI0.PEG0.PEGP
cat /sys/devices/LNXSYSTM:00/device:00/PNP0A08:00/LNXVIDEO:01/path _SB_.PCI0.GFX0
https://bugzilla.kernel.org/show_bug.cgi?id=61891
Rafael J. Wysocki rjw@rjwysocki.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #119821|0 |1 is obsolete| |
--- Comment #45 from Rafael J. Wysocki rjw@rjwysocki.net --- Created attachment 119891 --> https://bugzilla.kernel.org/attachment.cgi?id=119891&action=edit ACPIPHP / radeon: Debug switcheroo problem
OK, thanks! Everything is consistent at least. :-)
This patch doesn't fix anything yet, it just should set the no_hotplug flag for the radeon device (which ACPIPHP will be able to use later) during switcheroo detection.
Please apply it, boot the kernel and send dmesg.
https://bugzilla.kernel.org/show_bug.cgi?id=61891
--- Comment #46 from Mike Lothian mike@fireburn.co.uk --- It's not applying cleanly:
patching file drivers/gpu/drm/radeon/radeon_atpx_handler.c patching file include/acpi/acpi_bus.h Hunk #1 FAILED at 163. 1 out of 1 hunk FAILED -- saving rejects to file include/acpi/acpi_bus.h.rej
Does it need to be applied in conjunction with one of the other patches?
https://bugzilla.kernel.org/show_bug.cgi?id=61891
--- Comment #47 from madcatx@atlas.cz --- Should we apply it over the "v3" fix attempt or on a clean source?
https://bugzilla.kernel.org/show_bug.cgi?id=61891
--- Comment #48 from Mike Lothian mike@fireburn.co.uk --- Looks like the issue is
u32 reserved:27;
In your patch its 25 changing to 24
https://bugzilla.kernel.org/show_bug.cgi?id=61891
Mike Lothian mike@fireburn.co.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #119831|0 |1 is obsolete| | Attachment #119841|0 |1 is obsolete| |
--- Comment #49 from Mike Lothian mike@fireburn.co.uk --- Created attachment 119901 --> https://bugzilla.kernel.org/attachment.cgi?id=119901&action=edit Dmesg with reserved 26
This is the dmesg with reserved 26 - I'm guessing the number is decremented every time you add a new option
https://bugzilla.kernel.org/show_bug.cgi?id=61891
--- Comment #50 from Rafael J. Wysocki rjw@rjwysocki.net --- (In reply to madcatx from comment #47)
Should we apply it over the "v3" fix attempt or on a clean source?
Clean source, but I forgot I had some more patches on top of the Linus' tree applied.
Mike did that right.
https://bugzilla.kernel.org/show_bug.cgi?id=61891
Mike Lothian mike@fireburn.co.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #119901|0 |1 is obsolete| |
--- Comment #51 from Mike Lothian mike@fireburn.co.uk --- Created attachment 119911 --> https://bugzilla.kernel.org/attachment.cgi?id=119911&action=edit Dmesg with runpm off - so switcheroo is enabled propery
https://bugzilla.kernel.org/show_bug.cgi?id=61891
--- Comment #52 from madcatx@atlas.cz --- Created attachment 119921 --> https://bugzilla.kernel.org/attachment.cgi?id=119921&action=edit Dmesg with "Debug" patch applied
https://bugzilla.kernel.org/show_bug.cgi?id=61891
Rafael J. Wysocki rjw@rjwysocki.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #119891|0 |1 is obsolete| |
--- Comment #53 from Rafael J. Wysocki rjw@rjwysocki.net --- Created attachment 119931 --> https://bugzilla.kernel.org/attachment.cgi?id=119931&action=edit ACPIPHP / radeon: Debug (and possibly fix) switcheroo problem
OK, thanks!
This patch contains the ACPIPHP part too, so hopefully it will help.
Please apply instead of the previous one (should apply cleanly on top of 3.13-rc5), retest and report back (please attach dmesg after a single attempt to switch graphics in any case).
https://bugzilla.kernel.org/show_bug.cgi?id=61891
Mike Lothian mike@fireburn.co.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #119911|0 |1 is obsolete| |
--- Comment #54 from Mike Lothian mike@fireburn.co.uk --- Created attachment 119941 --> https://bugzilla.kernel.org/attachment.cgi?id=119941&action=edit Seems to work :D
That seems to work for me with radeon.runpm=1
So the system successfully powers up the card only when DRI_PRIME=1 is set when running an application (after xrandr --setprovideroffloadsink radeon Intel)
Thanks for this!
Do you think it'll land in 3.13?
https://bugzilla.kernel.org/show_bug.cgi?id=61891
--- Comment #55 from madcatx@atlas.cz --- Created attachment 119951 --> https://bugzilla.kernel.org/attachment.cgi?id=119951&action=edit Dmesg with "v4" fix applied
Brilliant! This seems to work for me too. I can finally drop below 10 Watts again:) I'll do some more testing and report back if I come across anything odd. Thanks for taking care of this.
https://bugzilla.kernel.org/show_bug.cgi?id=61891
--- Comment #56 from Rafael J. Wysocki rjw@rjwysocki.net --- Created attachment 119961 --> https://bugzilla.kernel.org/attachment.cgi?id=119961&action=edit ACPIPHP / radeon: Fix VGA switcheroo problem related to hotplug events
Thanks for testing!
That was a debug-only version of the patch, though, because the no_hotplug flag also needs to be checked in trim_stale_devices(). The attached one is a candidate for the final version (in addition to extending the ACPIPHP changes I removed the debug output from it and added a comment explaining what's going on to radeon_atpx_detect().
Please test this one and report back.
https://bugzilla.kernel.org/show_bug.cgi?id=61891
Mike Lothian mike@fireburn.co.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #119941|0 |1 is obsolete| |
--- Comment #57 from Mike Lothian mike@fireburn.co.uk --- Created attachment 119971 --> https://bugzilla.kernel.org/attachment.cgi?id=119971&action=edit Works great
Powering up and down automatically just fine
Feel free to add my tested by
https://bugzilla.kernel.org/show_bug.cgi?id=61891
--- Comment #58 from Alex Deucher alexdeucher@gmail.com --- Looks like we need a similar patch for DSM on nvidia laptops. See bug 64891.
https://bugzilla.kernel.org/show_bug.cgi?id=61891
--- Comment #59 from madcatx@atlas.cz --- Everything seems fine with the hopefully-final version. Good job!
https://bugzilla.kernel.org/show_bug.cgi?id=61891
--- Comment #60 from Rafael J. Wysocki rjw@rjwysocki.net --- OK, I'll send the patch to mailing lists later today. Many thanks to everyone involved!
@Alex: I'll have a look at that one too.
https://bugzilla.kernel.org/show_bug.cgi?id=61891
Jack q@cyphernaut.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |q@cyphernaut.org
--- Comment #61 from Jack q@cyphernaut.org --- Hey guys
I'm running into an issue with my 7970M/Intel muxless in which the discrete GPU doesn't actually power down once I've started X.
With acpiphp disabled I don't get the errors that were indicated in https://bugzilla.kernel.org/show_bug.cgi?id=65761 however vgaswitcheroo/switch remainds on DynPwr and never goes to DynOff (until I kill X, anyway)
I tried Rafael's patch in the hopes that this might resolve the issue, but it doesn't seem to have done so -- still stuck in DynPwr when X is started.
Is this patch specific for certain Radeon models, ie, would it not work with radeonsi? My first guess was no it shouldn't, but I don't know all that much s I figured I'd ask. :)
Thanks!
https://bugzilla.kernel.org/show_bug.cgi?id=61891
--- Comment #62 from Jack q@cyphernaut.org --- Created attachment 119991 --> https://bugzilla.kernel.org/attachment.cgi?id=119991&action=edit 7970m+3.13rc5+acipphp+rafael's patch
This is the dmesg output from my 7970M with 3.13rc5 + acpiphp.disable + rafael's latest patch from this bug report
https://bugzilla.kernel.org/show_bug.cgi?id=61891
--- Comment #63 from Jack q@cyphernaut.org --- Also both radeon.dpm=1 and radeon.runpm=1 were set in grub
https://bugzilla.kernel.org/show_bug.cgi?id=61891
--- Comment #64 from Jack q@cyphernaut.org --- Created attachment 120001 --> https://bugzilla.kernel.org/attachment.cgi?id=120001&action=edit Also acpidump from 7970M
https://bugzilla.kernel.org/show_bug.cgi?id=61891
Rafael J. Wysocki rjw@rjwysocki.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |ASSIGNED Component|Video(DRI - non Intel) |Config-Hotplug Assignee|drivers_video-dri@kernel-bu |rjw@rjwysocki.net |gs.osdl.org | Product|Drivers |ACPI
--- Comment #65 from Rafael J. Wysocki rjw@rjwysocki.net --- (In reply to Jack from comment #61)
Hey guys
I'm running into an issue with my 7970M/Intel muxless in which the discrete GPU doesn't actually power down once I've started X.
The patch in this entry only fixes the problem where ACPIPHP is involved. Moreover, I suppose that the failing removal of radeon may also play a role here, so that bug should be addressed first. Please continue to use bug #65761 to track the issues you have reported.
dri-devel@lists.freedesktop.org
-
bugzilla-daemon＠bugzilla.kernel.org