similar to: [RFC PATCH] pci: prevent putting pcie devices into lower device states on certain intel bridges

[+cc Rafael, Mika, linux-pm] On Fri, Sep 27, 2019 at 04:44:21PM +0200, Karol Herbst wrote: > Fixes runpm breakage mainly on Nvidia GPUs as they are not able to resume. I don't know what runpm is. Some userspace utility? Module parameter? > Works perfectly with this workaround applied. > > RFC comment: > We are quite sure that there is a higher amount of bridges affected by

On Fri, Sep 27, 2019 at 11:42 PM Bjorn Helgaas <helgaas at kernel.org> wrote: > > [+cc Rafael, Mika, linux-pm] > > On Fri, Sep 27, 2019 at 04:44:21PM +0200, Karol Herbst wrote: > > Fixes runpm breakage mainly on Nvidia GPUs as they are not able to resume. > > I don't know what runpm is. Some userspace utility? Module > parameter? > runpm aka runtime

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

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 in-code comment v3: disable it only for certain combinations of intel and nvidia hardware Signed-off-by: Karol Herbst <kherbst at redhat.com> Cc: Bjorn Helgaas <bhelgaas at google.com> Cc: Lyude Paul <lyude at

Fixes state transitions of Nvidia Pascal GPUs from D3cold into higher device states. v2: convert to pci_dev quirk put a proper technical explenation of the issue as a in-code comment RFC comment (copied from last sent): We are quite sure that there is a higher amount of bridges affected by this, but I was only testing it on my own machine for now. I've stresstested runpm by doing 5000

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

Hi Tobias, On Mon, Sep 11, 2017 at 8:49 PM, Tobias Klausmann < tobias.johannes.klausmann at mni.thm.de> wrote: > Hi, > > i remember seeing the same error with earlier firmware version with a > similar system (GP106) once in a while on boot, yet it does not happen > with newer versions. Maybe you could try to update the firmware to the > latest version from

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 in-code comment v3: disable it only for certain combinations of intel and nvidia hardware v4: simplify quirk by setting flag on the GPU itself Signed-off-by: Karol Herbst <kherbst at redhat.com> Cc: Bjorn Helgaas

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 in-code comment v3: disable it only for certain combinations of intel and nvidia hardware v4: simplify quirk by setting flag on the GPU itself v5: restructure quirk to make it easier to add new IDs fix whitespace issues

Hi, the system fails to initialize your vbios using secureboot (i had a rare chance to on my system to witness it again), for now i traced it to acr_boot_falcon() in "linux/drivers/gpu/drm/nouveau/nvkm/falcon/msgqueue_0148cdec.c" where it throws -110 which is -ETIMEDOUT. You could try to increase the timeout and see if it helps something, similar to the following: diff --git

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: > > So a new thinkpad: > > 01:00.0 VGA compatible controller: NVIDIA Corporation GP107GLM [Quadro P2000 Mobile] (rev a1) > > > > Hangs whenever I try to poke at the card. It starts happily

So a new thinkpad: 01:00.0 VGA compatible controller: NVIDIA Corporation GP107GLM [Quadro P2000 Mobile] (rev a1) Hangs whenever I try to poke at the card. It starts happily enough with [ 3.971515] ACPI Warning: \_SB.PCI0.GFX0._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20181003/nsarguments-66) [ 3.971553] ACPI Warning: \_SB.PCI0.PEG0.PEGP._DSM: Argument #4

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

On Wed, Mar 4, 2020 at 10:33 AM Mika Westerberg <mika.westerberg at intel.com> wrote: > > Hi, > > On Tue, Mar 03, 2020 at 11:10:52AM +0100, Karol Herbst wrote: > > Fixes state transitions of Nvidia Pascal GPUs from D3cold into higher device > > states. > > I think it is good to explain bit more here why this fix is needed. > is something like this fine?

CCing linux-pci and Bjorn Helgaas. Maybe we could get better insights on how a reasonable fix would look like. Anyway, to me this entire issue looks like something which has to be fixed on a PCI level instead of inside a driver, so it makes sense to ask the pci folks if they have any better suggestions. Original cover letter: While investigating the runpm issues on my GP107 I noticed that

On Tue, Nov 21, 2017 at 6:46 PM, Thierry Reding <thierry.reding at gmail.com> wrote: > On Tue, Nov 21, 2017 at 04:01:16PM +0100, Karol Herbst wrote: >> This should make systems more stable where resuming the GPU fails. This >> can happen due to bad firmware or due to a bug within the kernel. The >> last thing which should happen in either case is an unusable system.

On Tue, May 24, 2016 at 06:03:27PM +0200, Lukas Wunner wrote: > nouveau_drm_load() calls pm_runtime_put() if nouveau_runtime_pm != 0, > but nouveau_drm_unload() calls pm_runtime_get_sync() unconditionally. > We therefore leak a runtime pm ref whenever nouveau is loaded with > runpm=0 and then unloaded. The GPU will subsequently never runtime > suspend even if nouveau is loaded again

https://bugs.freedesktop.org/show_bug.cgi?id=94725 Bug ID: 94725 Summary: Nouveau driver fails to load on GM204 Product: xorg Version: unspecified Hardware: Other OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Driver/nouveau Assignee: nouveau at

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 in-code comment v3: disable it only for certain combinations of intel and nvidia hardware v4: simplify quirk by setting flag on the GPU itself v5: restructure quirk to make it easier to add new IDs fix whitespace issues

On Mon, Sep 30, 2019 at 6:30 PM Mika Westerberg <mika.westerberg at linux.intel.com> wrote: > > On Mon, Sep 30, 2019 at 06:05:14PM +0200, Karol Herbst wrote: > > still happens with your patch applied. The machine simply gets shut down. > > > > dmesg can be found here: > >