similar to: [PATCH] drm/nouveau/therm: fix a potential deadlock in the therm monitoring code

https://bugs.freedesktop.org/show_bug.cgi?id=77102 --- Comment #7 from Stefan Ringel <mail at stefanringel.de> --- Created attachment 96999 --> https://bugs.freedesktop.org/attachment.cgi?id=96999&action=edit ls -- You are receiving this mail because: You are the assignee for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL:

https://bugs.freedesktop.org/show_bug.cgi?id=77102 --- Comment #9 from Stefan Ringel <mail at stefanringel.de> --- (In reply to comment #8) > OK, so it seems like the firmware is correctly in place, and there are no > errors coming from dmesg, which means it's getting loaded (or at least isn't > failing to load). > > What version of Mesa are you using? I recently

https://bugs.freedesktop.org/show_bug.cgi?id=77102 --- Comment #11 from Stefan Ringel <mail at stefanringel.de> --- (In reply to comment #10) > Would you mind booting with > > nouveau.debug=PBSP=trace > > and putting up a dmesg from that (after the vdpauinfo, that is). BTW, silly > question -- do you have a libvdpau_nouveau.so? yes I have libvdpau_nouveau.so. It is

https://bugs.freedesktop.org/show_bug.cgi?id=77102 --- Comment #12 from Stefan Ringel <mail at stefanringel.de> --- Created attachment 97000 --> https://bugs.freedesktop.org/attachment.cgi?id=97000&action=edit dmesg -- You are receiving this mail because: You are the assignee for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL:

https://bugs.freedesktop.org/show_bug.cgi?id=77102 --- Comment #14 from Stefan Ringel <mail at stefanringel.de> --- (In reply to comment #13) > Created attachment 97009 [details] [review] > firmware present patch > > OK, upon further code reading, it looks like the way nouveau does class id's > is a bit off. That doesn't strictly matter for BSP, but there's a

https://bugs.freedesktop.org/show_bug.cgi?id=77102 --- Comment #15 from Stefan Ringel <mail at stefanringel.de> --- Created attachment 97014 --> https://bugs.freedesktop.org/attachment.cgi?id=97014&action=edit correct profile in vdpauinfo + vainfo -- You are receiving this mail because: You are the assignee for the bug. -------------- next part -------------- An HTML attachment

https://bugs.freedesktop.org/show_bug.cgi?id=77102 --- Comment #16 from Stefan Ringel <mail at stefanringel.de> --- (In reply to comment #15) > Created attachment 97014 [details] > correct profile in vdpauinfo + vainfo dmseg: [ 97.292274] nouveau T[ PBSP][0000:01:00.0] inc() == 4 [ 97.341821] nouveau T[ PBSP][0000:01:00.0] use(+1) == 1 [ 97.341827] nouveau T[

+ 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

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. Reported-by: Marcin Slusarz <marcin.slusarz at gmail.com>

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

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

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:

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

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

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> This patchset is mostly about fixing fdo bug #66177, reported by Dash Four. This bug is about fan/temp management not working after a suspend/resume cycle. Fan/therm management relies on ptimer's alarm feature to call periodically multiple callbacks that poll the temperature and update the fan speed if needed. The problem is that there is

<adding nouveau-devel to the Cc> Hi Ben, On 02-03-16 04:23, Ben Skeggs wrote: > On 03/01/2016 09:37 PM, Hans de Goede wrote: <snip> >> Ok, I've but an mmiotrace of the blob starting with a monitor connected >> to the troubesome connector here: >> >> https://fedorapeople.org/~jwrdegoede/mmiotrace.log.xz >> >> And a demmio-ed version (with