similar to: [Bug 69345] New: nouveau no longer reports D3cold on linux-next as of at least 20130906

In the autumn and winter it's considered bad form to set power state to D3cold, it might cause the device to freeze to death. This is also the case in the other seasons, so any device in the southern hemisphere is affected too. D3cold is not a valid state in a call to pci_set_power_state, only up to D3hot is allowed. Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com>

Even if PR3 support is available on the bridge, 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

https://bugs.freedesktop.org/show_bug.cgi?id=69375 Priority: medium Bug ID: 69375 Assignee: nouveau at lists.freedesktop.org Summary: [NV4E] GPU lockup when using chrome/flash QA Contact: xorg-team at lists.x.org Severity: normal Classification: Unclassified OS: Linux (All) Reporter: taylor_tails at

Hi, PR17975 was caused by r191059 which was reverted on the 3.4 branch in r196521. However, the problem still occurs with trunk (confirmed as of r206186). >From a thread on cfe-commits I see that Kai Nacke (the author of r191059) was working on a patch to fix PR17975, but the conversation ends: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20131202/197968.html So my question

On Wed, Oct 16, 2019 at 11:37 PM Bjorn Helgaas <helgaas at kernel.org> wrote: > > [+cc linux-acpi] > > On Wed, Oct 16, 2019 at 09:18:32PM +0200, Karol Herbst wrote: > > but setting the PCI_DEV_FLAGS_NO_D3 flag does prevent using the > > platform means of putting the device into D3cold, right? That's > > actually what should still happen, just the D3hot step

+Rafael On Fri, May 27, 2016 at 01:10:37PM +0200, Peter Wu wrote: > On Wed, May 25, 2016 at 04:55:35PM +0300, Mika Westerberg wrote: > > On Wed, May 25, 2016 at 12:53:01AM +0200, Peter Wu wrote: > > > Since "PCI: Add runtime PM support for PCIe ports", the parent PCIe port > > > can be runtime-suspended which disables power resources via ACPI. This > >

On Wed, May 25, 2016 at 12:53:01AM +0200, Peter Wu wrote: > Since "PCI: Add runtime PM support for PCIe ports", the parent PCIe port > can be runtime-suspended which disables power resources via ACPI. This > is incompatible with DSM, resulting in a GPU device which is still in D3 > and locks up the kernel on resume. > > Mirror the behavior of Windows 8 and newer[1] (as

The attached patch includes no test-case and isn't consistent with the rest of the file: - constants should be on the right hand side of comparisons - the braces around your single line 'if' aren't needed. On Sun, Sep 15, 2013 at 2:39 PM, James Courtier-Dutton < james.dutton at gmail.com> wrote: > I attach a patch that fixes this bug. Applies to llvm 3.4svn > >

https://bugs.freedesktop.org/show_bug.cgi?id=69349 Priority: medium Bug ID: 69349 Assignee: nouveau at lists.freedesktop.org Summary: Random image corruptions (in Debian Wheezy with Linux 3.2) QA Contact: xorg-team at lists.x.org Severity: normal Classification: Unclassified OS: All

On Sun, Feb 18, 2018 at 09:38:32AM +0100, Lukas Wunner wrote: > PCI devices not bound to a driver are supposed to stay in D0 during > runtime suspend. Doesn't "runtime suspend" mean an individual device is suspended while the rest of the system remains active? If so, maybe it would be more direct to say "PCI devices not bound to a driver cannot be runtime

On Wed, Oct 16, 2019 at 11:48:22PM +0200, Karol Herbst wrote: > On Wed, Oct 16, 2019 at 11:37 PM Bjorn Helgaas <helgaas at kernel.org> wrote: > > > > [+cc linux-acpi] > > > > On Wed, Oct 16, 2019 at 09:18:32PM +0200, Karol Herbst wrote: > > > but setting the PCI_DEV_FLAGS_NO_D3 flag does prevent using the > > > platform means of putting the device

Hi, I'm running dovecot on a OmniOS installation and I'm wondering what I can do about all those mount point warnings in my logfile. The problem occurs because of the running auto-mounter which manages my mail directories. Isn't it possible for dovecot just try to access the directories before logging an error message. Shall I remove the corresponding mount points from the list of

On Mon, Oct 21, 2019 at 3:33 PM Mika Westerberg <mika.westerberg at intel.com> wrote: > > On Wed, Oct 16, 2019 at 11:48:22PM +0200, Karol Herbst wrote: > > On Wed, Oct 16, 2019 at 11:37 PM Bjorn Helgaas <helgaas at kernel.org> wrote: > > > > > > [+cc linux-acpi] > > > > > > On Wed, Oct 16, 2019 at 09:18:32PM +0200, Karol Herbst wrote:

On Mon, May 30, 2016 at 02:20:10PM +0200, Peter Wu wrote: > On Mon, May 30, 2016 at 12:57:09PM +0300, Mika Westerberg wrote: > > +Rafael > > > > On Fri, May 27, 2016 at 01:10:37PM +0200, Peter Wu wrote: > > > On Wed, May 25, 2016 at 04:55:35PM +0300, Mika Westerberg wrote: > > > > On Wed, May 25, 2016 at 12:53:01AM +0200, Peter Wu wrote: > > >

but setting the PCI_DEV_FLAGS_NO_D3 flag does prevent using the platform means of putting the device into D3cold, right? That's actually what should still happen, just the D3hot step should be skipped. On Wed, Oct 16, 2019 at 9:14 PM Bjorn Helgaas <helgaas at kernel.org> wrote: > > On Wed, Oct 16, 2019 at 04:44:49PM +0200, Karol Herbst wrote: > > Fixes state transitions of

On Tue, Nov 19, 2019 at 10:50 PM Bjorn Helgaas <helgaas at kernel.org> wrote: > > [+cc Dave] > > On Thu, Oct 17, 2019 at 02:19:01PM +0200, Karol Herbst wrote: > > Fixes state transitions of Nvidia Pascal GPUs from D3cold into higher device > > states. > > > > v2: convert to pci_dev quirk > > put a proper technical explanation of the issue as a

Hello, I'm trying to setup a UPS configuration whereas I have one physical UPS but two UPS entities loaded by the system used by different network slaves. In my ups.conf configuration I have ... [ups] driver = apcsmart port = /dev/ttyS0 desc = "APC UPS" [qnapups] driver = dummy-ups port = ups at localhost desc = "APC UPS for

From: Rafael J. Wysocki <rjw at rjwysocki.net> We leave PCI devices not bound to a driver in D0 during runtime suspend. But they may have a parent which is bound and can be transitioned to D3cold at runtime. Once the parent goes to D3cold, the unbound child may go to D3cold as well. When the child comes out of D3cold, its BARs are uninitialized and thus inaccessible when a driver tries to

PCI devices not bound to a driver are supposed to stay in D0 during runtime suspend. But they may have a parent which is bound and can be transitioned to D3cold at runtime. Once the parent goes to D3cold, the unbound child may go to D3cold as well. When the child comes out of D3cold, its BARs are uninitialized and thus inaccessible when a driver tries to probe. One example are recent hybrid

Hi Karol, On Tue, Nov 19, 2019 at 11:26:45PM +0100, Karol Herbst wrote: > On Tue, Nov 19, 2019 at 10:50 PM Bjorn Helgaas <helgaas at kernel.org> wrote: > > > > [+cc Dave] > > > > On Thu, Oct 17, 2019 at 02:19:01PM +0200, Karol Herbst wrote: > > > Fixes state transitions of Nvidia Pascal GPUs from D3cold into higher device > > > states. > >