search for: d3cold_allowed

On Fri, Nov 22, 2019 at 1:13 AM Karol Herbst <kherbst at redhat.com> wrote: > > so while trying to test with d3cold disabled, I noticed that I run > into the exact same error. Does this mean that you disabled d3cold on the GPU via sysfs (the "d3cold_allowed" attribute was 0) and the original problem still occurred in that configuration? > And I verified that the > \_SB.PCI0.PEG0.PG00._STA returns 1, which indicates it should still be > turned on. I don't really understand this comment, so can you explain it a bit to me, please?

...it will not be used if the PCI layer considers it unavailable (i.e. on all laptops from 2013 and 2014). Ensure that this condition is checked to allow a fallback to the Optimus DSM for device poweroff. Initially I wanted to call pci_d3cold_enable before checking bridge_d3 (in case the user changed d3cold_allowed), but that is such an unlikely case and likely fragile anyway. The current patch is suggested by Mika in http://www.spinics.net/lists/linux-pci/msg52599.html Cc: Mika Westerberg <mika.westerberg at linux.intel.com> Signed-off-by: Peter Wu <peter at lekensteyn.nl> --- Hi, This idea is...

...cpus}=="3" ATTRS{device}=="0x1004" ATTRS{enable}=="1" ATTRS{msi_bus}=="" ATTRS{local_cpulist}=="0-1" ATTRS{vendor}=="0x1af4" ATTRS{subsystem_device}=="0x0008" ATTRS{numa_node}=="-1" ATTRS{d3cold_allowed}=="0" looking at parent device '/devices/pci0000:00': KERNELS=="pci0000:00" SUBSYSTEMS=="" DRIVERS=="" # udevadm info -q all -a /dev/sdb looking at device '/devices/pci0000:00/0000:00:04.0/virtio1/host1/target1:0:1/1:0:1:0/block...

...git a/include/linux/pci.h b/include/linux/pci.h index 930fab293073..3e5938b91966 100644 --- a/include/linux/pci.h +++ b/include/linux/pci.h @@ -340,6 +340,7 @@ struct pci_dev { unsigned int no_d3cold:1; /* D3cold is forbidden */ unsigned int bridge_d3:1; /* Allow D3 for bridge */ unsigned int d3cold_allowed:1; /* D3cold is allowed by user */ + unsigned int parent_d3cold:1; /* power manage the parent instead */ unsigned int mmio_always_on:1; /* Disallow turning off io/mem decoding during BAR sizing */ unsigned int wakeup_prepared:1; -- 2.24.1

https://bugs.freedesktop.org/show_bug.cgi?id=98398 --- Comment #6 from rick.2889 at gmail.com --- Booting without pcie_port_pm=off, while blacklisting nouveau on boot, then executing: echo 0 > /sys/bus/pci/devices/0000:01:00.0/d3cold_allowed && modprobe nouveau also causes powertop to report a ~7.5W value. -- You are receiving this mail because: You are the assignee for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/nouveau/attachments/20161...

...): https://people.freedesktop.org/~cbrill/dri-log/index.php?channel=nouveau&date=2016-10-22 In particular, Rick reported that the issue apparently also appears with older kernels, including 4.3 to 4.8. This is significant and a surprising result because kernel 4.8 plus pcie_port_pm=off (or the d3cold_allowed change) should 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 sure to keep a dmesg around. -- You are receiving this mail because: You are the assignee for the bug. -------------- next part -----...

Hi everyone, after following in the footsteps of the following discussion (http://lists.xenproject.org/archives/html/xen-users/2013-09/msg00106.html) I had been able to turn my GTX 480 into a Quadro 6000. When I VT-d passthrough it to a Debian jessie VM it shows up fine and CUDA 5.5 seems to function properly up to a point: lspci -v: 00:04.0 VGA compatible controller: NVIDIA Corporation GF100GL

...not using DSM in the end. I agree. > Poking at the probing code in nouveau_pr3_present, I started to wonder: > should I try to hack it to disable d3cold and pr3 and see what > happens? I guess it is worth a try. You can do it from sysfs for the graphics PCI device there is an attribute d3cold_allowed that controls this. [snip] > > > 00:14.3 Network controller: Intel Corporation Wireless-AC 9560 [Jefferson Peak] (rev 10) > > > > > > so really shouldn't be affected, but go figure. If driver really is getting > > > all-ones from the device, it just might...

.... > > > Poking at the probing code in nouveau_pr3_present, I started to wonder: > > should I try to hack it to disable d3cold and pr3 and see what > > happens? > > I guess it is worth a try. You can do it from sysfs for the graphics > PCI device there is an attribute d3cold_allowed that controls this. > > [snip] But probably too late by time nouveau is up at boot? > > > > 00:14.3 Network controller: Intel Corporation Wireless-AC 9560 [Jefferson Peak] (rev 10) > > > > > > > > so really shouldn't be affected, but go figure. If d...

...d for the idle power consumption on my > laptop. That doesn't involve the PCIe port PM, however. > But I guess I should retest with calling pci_d3cold_disable > from nouveau instead? Or is there a different preferable way of > testing this? There is a sysfs attribute called "d3cold_allowed" which can be used for "blocking" D3cold, so can you please retest using that?

On Wed, Nov 28, 2018 at 01:08:57PM +0200, Mika Westerberg wrote: > On Tue, Nov 27, 2018 at 09:49:44PM -0500, Michael S. Tsirkin wrote: > > On Tue, Nov 27, 2018 at 11:36:50AM +0200, Mika Westerberg wrote: > > > +linux-acpi > > > > > > Hi Michael, > > > > > > On Mon, Nov 26, 2018 at 10:53:26PM -0500, Michael S. Tsirkin wrote: > > >

...at the probing code in nouveau_pr3_present, I started to wonder: > > > should I try to hack it to disable d3cold and pr3 and see what > > > happens? > > > > I guess it is worth a try. You can do it from sysfs for the graphics > > PCI device there is an attribute d3cold_allowed that controls this. > > > > [snip] > > But probably too late by time nouveau is up at boot? > > > > > > 00:14.3 Network controller: Intel Corporation Wireless-AC 9560 [Jefferson Peak] (rev 10) > > > > > > > > > > so really shouldn...

.../linux/pci.h > index 930fab293073..3e5938b91966 100644 > --- a/include/linux/pci.h > +++ b/include/linux/pci.h > @@ -340,6 +340,7 @@ struct pci_dev { > unsigned int no_d3cold:1; /* D3cold is forbidden */ > unsigned int bridge_d3:1; /* Allow D3 for bridge */ > unsigned int d3cold_allowed:1; /* D3cold is allowed by user */ > + unsigned int parent_d3cold:1; /* power manage the parent instead */ Just to be consistent with the other comments, start with a capital letter: unsigned int parent_d3cold:1; /* Power manage the parent instead */

...ack? xen-backend:xen-pciback > > [root at xen1 ~]# ls /sys/bus/pci/devices/0000\:81\:02.6/driver/0000:81:02.6 > broken_parity_status? consistent_dma_mask_bits? dma_mask_bits??? enable > local_cpus? numa_node? reset????? resource0_wc? subsystem ?uevent > class???????????????? d3cold_allowed??????????? driver?????????? irq > modalias??? physfn???? resource?? resource3???? subsystem_device ?vendor > config??????????????? device??????????????????? driver_override local_cpulist > msi_bus???? power????? resource0? resource3_wc subsystem_vendor > > >> If bou...

On Fri, Apr 24, 2020 at 4:35 PM Peter Crowther <peter.crowther@melandra.com> wrote: > > On Fri, 24 Apr 2020 at 21:10, Mauricio Tavares <raubvogel@gmail.com> wrote: >> >> Let's say I have libvirt >> >> [root@vmhost2 ~]# virsh version >> [...] >> >> Running hypervisor: QEMU 2.12.0 >> [root@vmhost2 ~]# >> [...] > > When

...> > --- a/include/linux/pci.h > > +++ b/include/linux/pci.h > > @@ -340,6 +340,7 @@ struct pci_dev { > > unsigned int no_d3cold:1; /* D3cold is forbidden */ > > unsigned int bridge_d3:1; /* Allow D3 for bridge */ > > unsigned int d3cold_allowed:1; /* D3cold is allowed by user */ > > + unsigned int parent_d3cold:1; /* power manage the parent instead */ > > Just to be consistent with the other comments, start with a capital > letter: > > unsigned int parent_d3cold:1; /* Power manage...

[big snip] > There is a sysfs attribute called "d3cold_allowed" which can be used > for "blocking" D3cold, so can you please retest using that? > Hey-this is almost certainly not the right place in this thread to respond, but this thread has gotten so deep evolution can't push the subject further to the right, heh. So I'll just r...

On Thu, Nov 21, 2019 at 1:53 PM Karol Herbst <kherbst at redhat.com> wrote: > > On Thu, Nov 21, 2019 at 12:46 PM Mika Westerberg > <mika.westerberg at intel.com> wrote: > > > > On Thu, Nov 21, 2019 at 12:34:22PM +0100, Rafael J. Wysocki wrote: > > > On Thu, Nov 21, 2019 at 12:28 PM Mika Westerberg > > > <mika.westerberg at intel.com> wrote:

...git a/include/linux/pci.h b/include/linux/pci.h index 3840a541a9de..3c01f043519a 100644 --- a/include/linux/pci.h +++ b/include/linux/pci.h @@ -340,6 +340,7 @@ struct pci_dev { unsigned int no_d3cold:1; /* D3cold is forbidden */ unsigned int bridge_d3:1; /* Allow D3 for bridge */ unsigned int d3cold_allowed:1; /* D3cold is allowed by user */ + unsigned int parent_d3cold:1; /* Power manage the parent instead */ unsigned int mmio_always_on:1; /* Disallow turning off io/mem decoding during BAR sizing */ unsigned int wakeup_prepared:1; -- 2.24.1

On Thu, Nov 21, 2019 at 11:39 PM Rafael J. Wysocki <rafael at kernel.org> wrote: > > On Thu, Nov 21, 2019 at 8:49 PM Mika Westerberg > <mika.westerberg at intel.com> wrote: > > > > On Thu, Nov 21, 2019 at 04:43:24PM +0100, Rafael J. Wysocki wrote: > > > On Thu, Nov 21, 2019 at 1:52 PM Mika Westerberg > > > <mika.westerberg at intel.com>