search for: runpm

..."David Airlie" <airlied at redhat.com> > Cc: "Ben Skeggs" <skeggsb at gmail.com>, "Ben Skeggs" <bskeggs at redhat.com>, nouveau at lists.freedesktop.org > Sent: Thursday, 20 March, 2014 9:49:47 AM > Subject: Re: [Nouveau] [PATCH] drm: compute runpm on load, don't register autosuspend for non-runpm > > On Wed, Mar 19, 2014 at 7:45 PM, David Airlie <airlied at redhat.com> wrote: > > > >> On Thu, Mar 20, 2014 at 1:28 AM, Ilia Mirkin <imirkin at alum.mit.edu> wrote: > >> > There was a proliferatio...

> On Thu, Mar 20, 2014 at 1:28 AM, Ilia Mirkin <imirkin at alum.mit.edu> wrote: > > There was a proliferation of duplicated checks for runpm == -1 && > > optimus. Instead of continuing that tradition, get rid of all of them, > > only doing the optimus computation once on load. > > > > This should hopefully fix secondary cards suspending and then being > > unable to come back in non-optimus setups. &...

I have the issue when loading nouveau with runpm=0 set, that further nouveau loads without runpm set or runpm=1 don't put the card into sleep state. This is caused by calling pm_runtime_get_sync in drm_device.unload when the usage_counter isn't 0. pm_runtime_get_sync always increases the suage_counter and so the usage_counter gets increa...

On Wed, Mar 19, 2014 at 7:45 PM, David Airlie <airlied at redhat.com> wrote: > >> On Thu, Mar 20, 2014 at 1:28 AM, Ilia Mirkin <imirkin at alum.mit.edu> wrote: >> > There was a proliferation of duplicated checks for runpm == -1 && >> > optimus. Instead of continuing that tradition, get rid of all of them, >> > only doing the optimus computation once on load. >> > >> > This should hopefully fix secondary cards suspending and then being >> > unable to come back in n...

On Thu, Mar 20, 2014 at 1:28 AM, Ilia Mirkin <imirkin at alum.mit.edu> wrote: > There was a proliferation of duplicated checks for runpm == -1 && > optimus. Instead of continuing that tradition, get rid of all of them, > only doing the optimus computation once on load. > > This should hopefully fix secondary cards suspending and then being > unable to come back in non-optimus setups. > > Signed-off-by: I...

There was a proliferation of duplicated checks for runpm == -1 && optimus. Instead of continuing that tradition, get rid of all of them, only doing the optimus computation once on load. This should hopefully fix secondary cards suspending and then being unable to come back in non-optimus setups. Signed-off-by: Ilia Mirkin <imirkin at alum.mi...

https://bugs.freedesktop.org/show_bug.cgi?id=70464 Priority: medium Bug ID: 70464 Assignee: nouveau at lists.freedesktop.org Summary: [NVC3] runpm not working QA Contact: xorg-team at lists.x.org Severity: normal Classification: Unclassified OS: Linux (All) Reporter: michele.cane at gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: 7.7 (2011) Compo...

Fixes runpm breakage mainly on Nvidia GPUs as they are not able to resume. Works perfectly with this workaround applied. RFC comment: 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 ru...

https://bugs.freedesktop.org/show_bug.cgi?id=93065 Bug ID: 93065 Summary: nouveau kernel module needs to increase runpm use counter more often Product: xorg Version: git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Driver/nouveau Assignee: nouveau at lists.freedes...

...Component: Driver/nouveau Assignee: nouveau at lists.freedesktop.org Reporter: wolf480 at interia.pl QA Contact: xorg-team at lists.x.org Created attachment 117518 --> https://bugs.freedesktop.org/attachment.cgi?id=117518&action=edit dmesg log from freeze with runpm=0 I have a Medion X7827 laptop with GK104 GPU in an Optimus setup, running: Linux 4.1.2 x86_64 Mesa 10.6.2 Xorg 1.17.2 I've been experiencing some freezes: - a total freeze (no ping, no sysrq, only hard reset) shortly after xorg start - if nouveau is loaded *without* runpm=0 - a recoverable f...

...ad regulatory.db > [ 67.024463] cfg80211: failed to load regulatory.db > [ 99.980625] iwlwifi 0000:00:14.3: Error sending STATISTICS_CMD: time out after 2000ms. > > followed by soft lockups and sometimes hard lockups in places > like attempts to walk skb lists. > > Adding runpm=0 does away with this issue. > > The specific test was with noaccel=1 - it does not seem to change > things for me. > > I poked at the ACPI method NVPO and yes it does actually > seem to execute a while loop waiting for some register > to become 0. Which I guess never happens...

https://bugs.freedesktop.org/show_bug.cgi?id=108873 Bug ID: 108873 Summary: nouveau/Quadro P2000 Mobile: runpm causing ACPI errors, lockups Product: xorg Version: git Hardware: Other OS: All Status: NEW Severity: major Priority: medium Component: Driver/nouveau Assignee: nouveau at lists.fr...

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 with runpm=1. > > Fix by taking the runtime pm ref under the same condition that it was > released on driver load. > > Fixes: 5addcf0a5f0f ("nouveau: add runtime PM suppor...

[+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 this, &...

...m the device, it just might try to poke at a wrong b:d.f by mistake > maybe ... Or it the power resource is shared by wifi as well. > > > followed by soft lockups and sometimes hard lockups in places > > > like attempts to walk skb lists. > > > > > > Adding runpm=0 does away with this issue. > > > > > > The specific test was with noaccel=1 - it does not seem to change > > > things for me. > > > > > > I poked at the ACPI method NVPO and yes it does actually > > > seem to execute a while loop waiting for...

...nouveau_drm.h | 3 +++ > 2 files changed, 21 insertions(+) > > diff --git a/drm/nouveau/nouveau_drm.c b/drm/nouveau/nouveau_drm.c > index 89049335b738..e4bd6ed51e73 100644 > --- a/drm/nouveau/nouveau_drm.c > +++ b/drm/nouveau/nouveau_drm.c > @@ -75,6 +75,10 @@ MODULE_PARM_DESC(runpm, "disable (0), force enable (1), optimus only default (-1 > int nouveau_runtime_pm = -1; > module_param_named(runpm, nouveau_runtime_pm, int, 0400); > > +MODULE_PARM_DESC(staging, "enable staging APIs"); > +int nouveau_staging = 0; > +module_param_named(staging, n...

On Thu, Nov 29, 2018 at 2:29 AM Michael S. Tsirkin <mst at redhat.com> wrote: > > On Thu, Nov 29, 2018 at 12:21:31AM +0100, Karol Herbst wrote: > > this was already debugged and there is no point in searching inside > > the Firmware. It's not a firmware bug or anything. > > > > The proper fix is to do something inside Nouveau so that we don't > >

...67.021934] cfg80211: failed to load regulatory.db [ 67.024463] cfg80211: failed to load regulatory.db [ 99.980625] iwlwifi 0000:00:14.3: Error sending STATISTICS_CMD: time out after 2000ms. followed by soft lockups and sometimes hard lockups in places like attempts to walk skb lists. Adding runpm=0 does away with this issue. The specific test was with noaccel=1 - it does not seem to change things for me. I poked at the ACPI method NVPO and yes it does actually seem to execute a while loop waiting for some register to become 0. Which I guess never happens? Because card is in a low power st...

On Wed, Nov 28, 2018 at 10:09:22AM -0500, Michael S. Tsirkin wrote: > Yea all this is weird, in particular I wonder why does everyone > using dsm insists on saying Arg4 > when they actually mean Arg3. ACPI numbers arguments from 0. > > So it's a bit ugly, and maybe worth fixing but unlikely to be > an actual issue simply because we end up not using DSM in the end. I agree.

...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 something inside devinit makes runpm break. If Nouveau loads up to the point right before doing devinit, runpm works without any issues, if devinit is ran, not anymore. Out of curiousity I even tried to "bisect" devinit by not running it on vbios provide...