| Priority | medium |
|---|---|
| Bug ID | 71930 |
| Assignee | dri-devel@lists.freedesktop.org |
| Summary | Kernel Bug and X fails to start when using radeon.runpm=1 |
| Severity | normal |
| Classification | Unclassified |
| OS | All |
| Reporter | mike@fireburn.co.uk |
| Hardware | Other |
| Status | NEW |
| Version | XOrg CVS |
| Component | DRM/Radeon |
| Product | DRI |
Created attachment 89664 [details]
Dmesg of bug
During 3.13-rc0 I was unable to boot my system to capture the logs, since
3.13-rc1 has been cut the have been improvements where I can now boot the
system but X won't start whilst radeon.runpm=1
I'll attach my dmesg
| What | Removed | Added |
|---|---|---|
| CC | mike@fireburn.co.uk |
I should add I think this bug is also triggered during shutdown but systmed is a little too quick for me to see If required I can do a git bisect testing the shutdown rather than the boot with runpm as I don't think the runpm code is at fault but only manifests the issue
I think the same issue has been reported upstream too https://bugzilla.kernel.org/show_bug.cgi?id=65761
Does manually turning off the dGPU using switcheroo still work with radeon.runpm=0? If not, can you bisect? runpm and switcheroo use the same apci mechanism to turn off the dGPU.
It locks up the machine Output from journalctl -f will be attached which was captured by sshing from another machine It froze up the laptop completely and the connection died
X is now starting with runpm=1 but I get a kworker eating lots of cpu and a slight freeze / stutter every few seconds Looks like the card is initialised every few seconds in the dmesg
(In reply to comment #4) > It locks up the machine Can you bisect to see what broke vgaswitcheroo on your system? Both runpm and switcheroo use the same acpi method, so fixing one with likely fix both.
I bisected back to [bbd34fcdd1b201e996235731a7c98fd5197d9e51] ACPI / hotplug / PCI: Register all devices under the given bridge Which was during the 3.11 cycle I believe - I guess there's a chance I picked up on a previous bug I'll do some more testing
(In reply to comment #9) > I bisected back to [bbd34fcdd1b201e996235731a7c98fd5197d9e51] ACPI / hotplug > / PCI: Register all devices under the given bridge > > Which was during the 3.11 cycle I believe - I guess there's a chance I > picked up on a previous bug I'll do some more testing Does reverting that commit fix the issues?
I've just tried but it doesn't revert cleanly - not even on 3.11
I think that was when I was playing around with the dynamic shutdown patches in one of Dave's git branches - which explains why I haven't really noticed this until now - I rarely used switcheroo This is also possibly related to https://bugzilla.kernel.org/show_bug.cgi?id=61891
Same problem. My graphics cards: lspci | grep VGA 01:05.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI RS880M [Mobility Radeon HD 4225/4250] 02:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Park [Mobility Radeon HD 5430/5450/5470] If radeon.runpm=0 all o.k. If manually turning off the dGPU using switcheroo then freeze Use Ubuntu 14.04 with 13.rc1
(In reply to comment #13) > Same problem. > My graphics cards: > lspci | grep VGA > 01:05.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI > RS880M [Mobility Radeon HD 4225/4250] > 02:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Park > [Mobility Radeon HD 5430/5450/5470] > If radeon.runpm=0 all o.k. > If manually turning off the dGPU using switcheroo then freeze > > I'm use Ubuntu 14.04 with kernel 3.13.rc1
$ sudo cat /sys/kernel/debug/vgaswitcheroo/switch 0:IGD:+:DynPwr:0000:01:05.0 1:DIS: :DynPwr:0000:02:00.0 The DynPwr should exist on both cards or only the dGPU? Does runpm extinguished and the two cards and the computer freezes?
Switching back to airlied's drm-radeon-poweroff branch which is based on 3.11-rc3 (which doesn't show my radeon card as a provider) has the following in switcheroo 0:DIS: :DynOff:0000:01:00.0 1:IGD:+:Pwr:0000:00:02.0 and this is what is shows with runpm=0 but with this set I'm able to see my radeon card as a provider
Created attachment 90020 [details]
Dmesg from drm-fixes-3.12-radeon-poweroff
This is the dmesg from adg5f's drm-fixes-3.12-radeon-poweroff branch when I do
a switcheroo OFF then ON with runpm=0
With runpm=1 on adg5f's drm-fixes-3.12-radeon-poweroff which is based on 3.11.0-rc7 I get the following in switcheroo 0:DIS: :DynOff:0000:01:00.0 1:IGD:+:Pwr:0000:00:02.0 It also lists providers and DRI_PRIME works great powering the card as and when I fire something up and shows this in switcheroo 0:DIS: :DynPwr:0000:01:00.0 1:IGD:+:Pwr:0000:00:02.0
This is currently what's in switcheroo in 3.13-rc2 with runpm=1 0:IGD:+:Pwr:0000:00:02.0 1:DIS: :DynPwr:0000:01:00.0 Which seems to have a reversed order - the system keeps powering up the radeon card and powering down
I'm only seeing the intel provider out out xrandr --listproviders and the system keeps stuttering when the card is either powered up (looks like when it's printing the dpm tables)
I also experience issues with radeon.runpm=1 on 3.13-rc2. My system is intel hd4000 + Mobile radeon 7750M. However lspci shows the following: 00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09) 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Chelsea LP [Radeon HD 7730M] Below are attached dmesg with radeon.runpm=1 and Xorg.0.log.