similar to: [PATCH] pm/fan: drop the fan lock in fan_update() before rescheduling

From: Martin Peres <martin.peres at labri.fr> This should fix a deadlock that has been reported to us where fan_update() would hold the fan lock and try to grab the alarm_program_lock to reschedule an update. On an other CPU, the alarm_program_lock would have been taken before calling fan_update(), leading to a deadlock. We should Cc: <stable at vger.kernel.org> # 3.9+ Reported-by:

On Sun, Mar 9, 2014 at 10:51 AM, Marcin Slusarz <marcin.slusarz at gmail.com> wrote: > [ 326.168487] ====================================================== > [ 326.168491] [ INFO: possible circular locking dependency detected ] > [ 326.168496] 3.13.6 #1270 Not tainted > [ 326.168500] ------------------------------------------------------- > [ 326.168504] ldconfig/22297 is

From: Martin Peres <martin.peres at labri.fr> Signed-off-by: Martin Peres <martin.peres at free.fr> --- drm/Kbuild | 1 + drm/core/subdev/therm/gm107.c | 1 + nvkm/engine/device/gm100.c | 4 +- nvkm/include/subdev/therm.h | 1 + nvkm/subdev/therm/Makefile.am | 3 +- nvkm/subdev/therm/fan.c | 9 ++++- nvkm/subdev/therm/gm107.c | 93

https://bugs.freedesktop.org/show_bug.cgi?id=65554 Priority: medium Bug ID: 65554 Assignee: nouveau at lists.freedesktop.org Summary: CPU lock with nouveau_fan_update QA Contact: xorg-team at lists.x.org Severity: major Classification: Unclassified OS: Linux (All) Reporter: ddamienn at gmail.com

From: Martin Peres <martin.peres at labri.fr> Re-use the therm-exported fan structure with only two minor modifications: - pwm_freq: u16 -> u32; - add fan_type (toggle or PWM) Signed-off-by: Martin Peres <martin.peres at free.fr> --- drm/Kbuild | 1 + drm/core/include/subdev/bios/fan.h | 1 + drm/core/subdev/bios/fan.c | 1 +

Hi, I used to experience kernel panics caused by CPUx hard lockup once almost everyday. I'm running Ubuntu 14.10 on vanilla linux kernel 3.19.2 on Core i7-3770 with Gallium 0.4 on NV108. The panic log looked like: [ 9227.509744] ------------[ cut here ]------------ [ 9227.509750] WARNING: CPU: 0 PID: 0 at kernel/watchdog.c:290 watchdog_overflow_callback+0x92/0xc0() [ 9227.509751] Watchdog

All kernel patches must have a Signed-off-by: $user. See https://www.kernel.org/doc/html/latest/process/submitting-patches.html#sign-your-work-the-developer-s-certificate-of-origin On Mon, Apr 17, 2017 at 3:47 AM, Oscar Salvador <osalvador.vilardaga at gmail.com> wrote: > This is a preparation for the next patches. It just adds the sensors with > their possible configurable settings

Hi again, I've split the patches as Karol Herbst suggested. I hope now it's fine. This series of patches introduce the new hwmon_device_register_with_info and gets rid of the old hwmon_device_register. This patch adds the default sensors with their possible config values. Just to prepare for the next patches --- linux/drivers/gpu/drm/nouveau/nouveau_hwmon.c.orig 2017-04-12

This patch introduces the structure "struct hwmon_ops" and sets up the ".visible" operation. Is also a preparation for the next patch. --- linux/drivers/gpu/drm/nouveau/nouveau_hwmon.c.orig 2017-04-12 19:18:09.638073562 +0200 +++ linux/drivers/gpu/drm/nouveau/nouveau_hwmon.c 2017-04-12 19:19:44.244797202 +0200 @@ -692,6 +692,78 @@ static const struct attribute_group hwmo

This is a preparation for the next patches. It just adds the sensors with their possible configurable settings and then fills the struct hwmon_channel_info with all this information. --- drivers/gpu/drm/nouveau/nouveau_hwmon.c | 72 +++++++++++++++++++++++++++++++++ 1 file changed, 72 insertions(+) diff --git a/drivers/gpu/drm/nouveau/nouveau_hwmon.c b/drivers/gpu/drm/nouveau/nouveau_hwmon.c

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

Signed-off-by: Martin Peres <martin.peres at free.fr> Tested-by: Stefan Ringel <mail at stefanringel.de> --- drivers/gpu/drm/nouveau/core/subdev/therm/temp.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/nouveau/core/subdev/therm/temp.c b/drivers/gpu/drm/nouveau/core/subdev/therm/temp.c index cfde9eb..6212537 100644 ---

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

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

https://bugs.freedesktop.org/show_bug.cgi?id=78116 Priority: medium Bug ID: 78116 Assignee: nouveau at lists.freedesktop.org Summary: Auto fan speed management doesn't do anything in non critical temperature range (NVC0) QA Contact: xorg-team at lists.x.org Severity: enhancement Classification: Unclassified

https://bugs.freedesktop.org/show_bug.cgi?id=76414 Priority: medium Bug ID: 76414 Assignee: nouveau at lists.freedesktop.org Summary: [NVE4] Flash player triggers freeze with: PFIFO: read fault at ... [UNSUPPORTED_KIND] from PBDMA0/HOST ... QA Contact: xorg-team at lists.x.org Severity: major Classification:

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

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, 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 >> negative values are not for error reporting, but rather when you