similar to: Optimizing the loop for large data

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

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 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

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

Which Debian version do you use? Because in either version (0 oer 10) in nsswitch.conf is wirtten "files winbind" in Debian 9 it's "compat winbind" and in 10 it's "files systemd winbind" so you removed (I think) systemd maybe you should put it back in Am 01.05.20 um 02:12 schrieb miguel medalha via samba: >> I am trying to use the backend = rid but it

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

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

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

diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/temp.c b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/temp.c index b9703c0..adb1deb 100644 --- a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/temp.c +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/temp.c @@ -120,6 +120,11 @@ nvkm_therm_sensor_event(struct nvkm_therm *therm, enum nvkm_therm_thrs thrs, struct work_struct *work; work =

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 2020-05-03 12:39, Stefan Kania via samba wrote: > Which Debian version do you use? Because in either version (0 oer 10) in > nsswitch.conf is wirtten "files winbind" in Debian 9 it's "compat > winbind" and in 10 it's "files systemd winbind" so you removed (I think) > systemd maybe you should put it back in root at samba01:~# dpkg -l winbind

Hi : I am new to ICEcast, and really am just starting to get to grips with the ability of community radio, however I have a reason to look into the set up process and concepts some more, while I work with people in the Pacific region on using information communications technologies (ICT's) to empower learning networks, the foundations of indigenous music, and communities which have lots to

Thanks for the pointer. But I don't like this patch. If you find a bug, make a bug report or just fix it if you know the fix already. Or write something in IRC. Or write on the Mailing list as a general question or something else But I really don't agree on doing it this way. You would have needed like the same amount of time to actual fix the problem. Anyway, for adding a printk:

Hi! Not only it is unneccessarily complex, it is also broken; GFP_ATOMIC allocation can fail.. and then you fail to shut down the machine. Someone please fix this. Thanks, Pavel --- a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/temp.c +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/temp.c @@ -120,6 +120,11 @@ nvkm_therm_sensor_event(struct nvkm_therm *therm, enum nvkm_therm_thrs thrs,

---------- Forwarded message ---------- From: Sean Linton <sean at lpnz.org> Date: 20 November 2010 18:33 Subject: Festival of Pacific Arts web cast To: Robert Loomans <robertl at apnic.net>, George Michaelson <ggm at apnic.net>, sylvia at apnic.net, Gaurab Raj Upadhaya <gaurab at lahai.com>, Ian Pringle < ipringle at col.org>, Martin Hadlow <m.hadlow at

Hi, I have a 3 columns data and need to generate a vector of counts. These counts are the number of rows that are contiguous. It looks easy for manual counting, but to turn it algorithmic really split my head. For example, 11 (i.e. 18004 to 180014), 1 (i.e., 18017), 7 (i.e., 18060 to 18064) 18004 10314568 0.5205757 18005 10333837 0.5135572 18006 10566333 0.5111271 18007 10566624 0.8196611