search for: downclocked

From: Colin Ian King <colin.king at canonical.com> Array thresolds should be named thresholds, rename it. Also make it static static const char * const Signed-off-by: Colin Ian King <colin.king at canonical.com> --- drivers/gpu/drm/nouveau/nvkm/subdev/therm/temp.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git

+ the same for shutdown threshold - seems impossible, but shutdown can fail. Signed-off-by: Marcin Slusarz <marcin.slusarz at gmail.com> --- drivers/gpu/drm/nouveau/core/subdev/therm/temp.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/nouveau/core/subdev/therm/temp.c b/drivers/gpu/drm/nouveau/core/subdev/therm/temp.c index bf9b3ce..8f27b44

I see no problem with your nvidia temps But, i have seen this exact behavior when 'indirect rendering' is enabled. On Wed, Aug 19, 2009 at 2:00 PM, <compiz-request at lists.freedesktop.org>wrote: > Send compiz mailing list submissions to > compiz at lists.freedesktop.org > > To subscribe or unsubscribe via the World Wide Web, visit >

https://bugs.freedesktop.org/show_bug.cgi?id=88415 Bug ID: 88415 Summary: [NVA8] nouveau GPU lockup when reclocking Product: xorg Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Driver/nouveau Assignee:

From: Martin Peres <martin.peres at labri.fr> This is safe because ptherm hasn't been configured yet and will be a little further down the initialization path. Ptherm should be safe regarding to runtime reconfiguration. v2: - do not limit this patch to nv84-a3 and make it nv84+ v3: - move the ack to fini() - disable IRQs on fini() - silently ignore un-requested IRQs

On 07/10/2014 06:50 PM, Mikko Perttunen wrote: > Does GK20A itself have any kind of thermal protection capabilities? > Upstream SOCTHERM support is not yet available (though I have a driver > in my tree), so we are thinking of disabling CPU DVFS on boards that > don't have always-on active cooling for now. Same might be necessary for > GPU as well. There is a small thermal

Hello, does this sound as a good combination, mini-itx board with Atom dual core 1.6ghz 2G ram and a sangoma USB? For a setup with PSTN for incoming and IAX2(alaw/gsm) for outgoing calls. - Would you say its a good choice from a hardware perspective? - Roughly how many concurrent calls would one of these be able to handle? Regards, Veselin K

Signed-off-by: Karol Herbst <karolherbst at gmail.com> --- drm/nouveau/include/nvkm/subdev/clk.h | 1 + drm/nouveau/nvkm/subdev/clk/base.c | 35 +++++++++++++++++++++++++++++++---- 2 files changed, 32 insertions(+), 4 deletions(-) diff --git a/drm/nouveau/include/nvkm/subdev/clk.h b/drm/nouveau/include/nvkm/subdev/clk.h index f5ff1fd9..b79bf657 100644 ---

v2: make message about relaxed throttling an info rework reporting about current clk state Signed-off-by: Karol Herbst <karolherbst at gmail.com> --- drm/nouveau/include/nvkm/subdev/clk.h | 1 + drm/nouveau/nvkm/subdev/clk/base.c | 44 +++++++++++++++++++++++++---------- 2 files changed, 33 insertions(+), 12 deletions(-) diff --git a/drm/nouveau/include/nvkm/subdev/clk.h

Hi! We (an astronomical center) are building a small cluster for our number-crunching. The problem is that we have 12 mobos A7V600 by Asus (for athlons) - 1 server + 11 diskless nodes. And here comes the trouble... hardware: mobo: a7v600 net: 1 gigabit by 3com - 3c940, integrated in mobo the problem is: dhcp - works fine tftp - works fine pxelinux.0 - downloads fine (I hope) linux kernel -

The temp_get() function currently returns negative error numbers or a temperature. However, the thermal sensors can (in theory) measure negative temperatures. Some implementations of temp_get() correctly clamp negative temperature readings to 0 so that users do not mistake them for errors, but some, like gp100_temp_get(), do not. Rather than relying on implementations remembering to clamp values,

On Wed, Sep 16, 2020 at 10:01 PM Karol Herbst <kherbst at redhat.com> wrote: > > On Wed, Sep 16, 2020 at 9:47 PM Jeremy Cline <jcline at redhat.com> wrote: > > > > The temp_get() function currently returns negative error numbers or a > > temperature. However, the thermal sensors can (in theory) measure > > negative temperatures. Some implementations of

On 17/11/17 02:04, Karol Herbst wrote: > The current hwmon code doesn't check if the returned value was actually an > error. > > Since Kepler temperature sensors are able to report negative values. Those > negative values are not for error reporting, but rather when you buried > your GPU in snow somewhere in Antarctica and still want a valid > temperature to be reported

As you changed the return value of `temp_get()` to solely be the error code, or absence of an error, I would change all those tests that checked whether the returned value was strictly less, or greater than, 0 to now only compare against 0 (no error). For example, if (therm && therm->attr_get && nvkm_therm_temp_get(therm, &val) < 0) if

The current hwmon code doesn't check if the returned value was actually an error. Since Kepler temperature sensors are able to report negative values. Since Pascal (and maybe earlier) we have sensors with improved precision. Adjust the nvkm_get_temp method to be able to deal with those changes and let hwmon return an error properly. Signed-off-by: Karol Herbst <karolherbst at

On 22/11/17 03:42, Karol Herbst wrote: > On Wed, Nov 22, 2017 at 1:32 AM, Martin Peres <martin.peres at free.fr> wrote: >> On 17/11/17 02:04, Karol Herbst wrote: >>> The current hwmon code doesn't check if the returned value was actually an >>> error. >>> >>> Since Kepler temperature sensors are able to report negative values. Those

On Wed, Sep 16, 2020 at 9:47 PM Jeremy Cline <jcline at redhat.com> wrote: > > The temp_get() function currently returns negative error numbers or a > temperature. However, the thermal sensors can (in theory) measure > negative temperatures. Some implementations of temp_get() correctly > clamp negative temperature readings to 0 so that users do not mistake > them for

before we can let nouveau fully reclock the gpu automatically, we should have a fail safe mechanism to prevent the card from overheating. Starting with G84 GPUs the so called FSRM does the job and automatically downclocks the GPU when specific temperatures thresholds are hit. Lucky for us the needed bits are already configured through a script inside the vbios at POST time and we only need to

The current hwmon code doesn't check if the returned value was actually an error. Since Kepler temperature sensors are able to report negative values. Those negative values are not for error reporting, but rather when you buried your GPU in snow somewhere in Antarctica and still want a valid temperature to be reported (unverified). Since Pascal (and maybe earlier) we have sensors with

On Wed, Sep 16, 2020 at 10:03:22PM +0200, Karol Herbst wrote: > On Wed, Sep 16, 2020 at 10:01 PM Karol Herbst <kherbst at redhat.com> wrote: > > > > On Wed, Sep 16, 2020 at 9:47 PM Jeremy Cline <jcline at redhat.com> wrote: > > > > > > The temp_get() function currently returns negative error numbers or a > > > temperature. However, the thermal