| What | Removed | Added |
|---|---|---|
| QA Contact | xorg-team@lists.x.org | |
| Component | DRM/other | Driver/nouveau |
| Version | XOrg git | unspecified |
| Product | DRI | xorg |
| Assignee | dri-devel@lists.freedesktop.org | nouveau@lists.freedesktop.org |
Created attachment 127486 [details]
New dmesg output after manually turning on power management
So Lekensteyn asked me to run a few commands to also shut off the bus the G=
PU
is on.
If I do so and then proceed by running powertop on battery, intel_pstate
complains about turbo not being available, a usb device disconnects, a while
later Nouveau resumes kernel object trees, Bluetooth reconnects and nouveau
suspends again.
The commands are:
# echo auto > /sys/bus/pci/devices/0000\:00\:1c.4/power/control=20
# grep .
/sys/bus/pci/devices/0000:0{0:1c.4,1:00.0}/power/{control,runtime_status}
The latter returns auto, suspended, auto, suspended before running powertop,
and on, active, auto, suspended after running powertop.
Created attachment 127487 [details]
lspci -nnvvv output
Adding pcie_port_pm=3Doff to my kernel command line causes the= card to turn off and powertop to report ~7.5W of power usage. According to Lekensteyn this reverts nouveau to the 4.7 and lower behavior of using DSM, so I think this= is a regression from using the new method.
Booting without pcie_port_pm=3Doff, while blacklisting nouveau= on boot, then executing: echo 0 > /sys/bus/pci/devices/0000:01:00.0/d3cold_allowed && mo= dprobe nouveau also causes powertop to report a ~7.5W value.
Just to add extra info here, this problem also happens with bb= switch https:= //github.com/Bumblebee-Project/bbswitch/issues/140 Guys, do you know if this is really a bug from Linux or a feature? I meant,= if changes to fix this problem would be at kernel side (PM team) or kernel interface side (vgaswitcheroo / bbswitch) ? Regards
| What | Removed | Added |
|---|---|---|
| Summary | [Nouveau] Vgaswitcharoo fails to turn off GPU properly | Acer Aspire V7-582PG (Haswell, GTX 750M) fails to power off = GPU with runtime PM |
| CC | peter@lekensteyn.nl |
Pablo, the issues that bbswitch has is different from the one = reported here. bbswitch is not updated for 4.8 requiring the pcie_port_pm=3Doff workaround. There are more details for this bug from the reporter in IRC (search for NanoSector): https://people.freedesktop.org/~cbrill/dr= i-log/index.php?channel=3Dnouveau&date=3D2016-10-22 In particular, Rick reported that the issue apparently also appears with ol= der kernels, including 4.3 to 4.8. This is significant and a surprising result because kernel 4.8 plus pcie_port_pm=3Doff (or the d3cold_allowed change) s= hould have the same result as 4.7 or before. Rick, can you re-test it with 4.7? It also occurs to me that older kernels might not support your GPU, so be s= ure to keep a dmesg around.
Sure, I'll have another test run with 4.7 this week.
Hmm I just installed Linux 4.7.6 and ran it without any additi= onal kernel parameters and I am getting results close to =CB=9C7.5W too, so it seems to= work there.
So 4.7 and before used the "DSM" method on runtime-s=
uspend:
- \_SB.PCI0.RP05.PEGP._DSM would be invoked to enable Optimus
- \_SB.PCI0.RP05.PEGP._PS3 is then invoked which would enter D3cold
(note, this method is still used in 4.8 on older laptops or with the
pcie_pm_port=3Doff kernel option)
Since 4.8, _DSM is not called anymore by nouveau (when support from the PCI
core is detected) and this sequence should instead happen:
- \_SB.PCI0.RP05.PEGP._PS3 (does nothing besides updating _STA)
- PCIe core removes power for the PCIe port since all its children are in
D3 and are willing to transition to D3cold. It does so by invoking
\NVP3._OFF (where \NVP3 is the power resource from \_SB.PCI0.RP05._PR3)
That is how I think it should work in theory, but on Ricks laptop running
4.8.4,
/sys/bus/devices/0000:1c.4/firmware_node/ does not have power_resources_D0
devices (which I do have on my own laptop for 0000:01:0).
The SSDT1 of Rick's Acer laptop shows this structure:
If (\_OSI ("Windows 2013"))
{
Scope (\_SB.PCI0.RP05)
{
//...
Name (_PR0, Package (0x01) // _PR0: Power Resources for D0
{
NVP3
})
Name (_PR2, Package (0x01) // _PR2: Power Resources for D2
{
NVP2
})
Name (_PR3, Package (0x01) // _PR3: Power Resources for D3hot
{
NVP3
})
// ...
Method (_PS0, 0, NotSerialized) // _PS0: Power State 0
{
}
Method (_PS3, 0, NotSerialized) // _PS3: Power State 3
{
}
}
Name (MSD3, Zero)
PowerResource (NVP3, 0x00, 0x0000)
{
Name (_STA, One) // _STA: Status
// ...
Method (_ON, 0, NotSerialized) // _ON_: Power On
{
// ...
}
Method (_OFF, 0, NotSerialized) // _OFF: Power Off
{
// ...
}
}
The dmesg does show "ACPI: Power Resource [NVP3] (on)", so I gues=
s that the
methods are found. It is a mystery to me why the "power_resources_Dx&q=
uot; files are
not created, possibly breaking PM.
| What | Removed | Added |
|---|---|---|
| Status | NEW | ASSIGNED |
At the moment it looks like an ACPI core bug which manifested = in nouveau. See https://lists.freedesktop.org/archives/nouveau/2016-October/026395= .html and the replies. I'll post a workaround patch soon.