similar to: gk104: disable display underflow reporting

Hi Martin, I was asked to clarify a few things: (1) Are all the user reports of loud fans on Fermi-era GPUs? (2) When the VBIOS POSTs the card, it loads initial ucode onto the Falcon processor (PMU), which will do basic fan management on its own. We call this init ucode "IFR" (Init From ROM). nvidia.ko will restore the IFR ucode when unloaded. I assume the loud fan symptom occurs

Hey, Thanks for your answer, Andy! On 22/11/17 04:06, Ilia Mirkin wrote: > On Tue, Nov 21, 2017 at 8:29 PM, Andy Ritger <aritger at nvidia.com> wrote: >> Hi Martin, > > Martin should have complete answers, > >> >> I was asked to clarify a few things: >> >> (1) Are all the user reports of loud fans on Fermi-era GPUs? > > Yes. Although I

On Mon, Nov 24, 2014 at 8:33 PM, Andy Ritger <aritger at nvidia.com> wrote: > On Fri, Nov 21, 2014 at 01:39:55AM -0500, Ilia Mirkin wrote: >> On Fri, Nov 21, 2014 at 1:16 AM, Andy Ritger <aritger at nvidia.com> wrote: >> > Hi Ilia, >> > >> > Actually 0x90b8 is different than copy engine. I'm not very familiar >> > with it, but 0x90b8 is

The offset should be 8 on Kepler and later. Signed-off-by: Vince Hsu <vinceh at nvidia.com> --- drm/nouveau/nvkm/engine/fifo/gk104.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Hi, According to the header[1] the offset for engine status register is 8. [1] https://github.com/kfractal/nouveau/blob/hwref/drm/nouveau/include/nvkm/hwref/gk104/fifo.h Thanks, Vince diff --git

On Thu, Sep 12, 2019 at 3:00 PM Karol Herbst <kherbst at redhat.com> wrote: > > taken from nvgpu > > Signed-off-by: Karol Herbst <kherbst at redhat.com> > --- > drm/nouveau/nvkm/subdev/pci/gk104.c | 7 +++++++ > 1 file changed, 7 insertions(+) > > diff --git a/drm/nouveau/nvkm/subdev/pci/gk104.c b/drm/nouveau/nvkm/subdev/pci/gk104.c > index

On 2017-09-15 — 17:11, Karol Herbst wrote: > While my gpu was powered off, hwmon returned 0.6V as the current voltage. > If nvkm_rd32 fails for any reason, return the error. > > With that sensors will display a "N/A" instead of 0.6V. Small nitpick, add a comma between “that” and “sensors”. Otherwise, Reviewed-by: Pierre Moreau <pierre.morrow at free.fr> > >

Signed-off-by: ZhiHu <huzhi001 at 208suo.com> --- .../gpu/drm/nouveau/nvkm/engine/fifo/gk104.c | 40 ++++++++++++++----- 1 file changed, 29 insertions(+), 11 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gk104.c b/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gk104.c index d8a4d773a58c..b99e0a7c96bb 100644 --- a/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gk104.c +++

not sure how i got signed up for this and i don?t see a way to unsubscribe. this is flooding my email with things i don?t care about. On Fri, Jul 14, 2023, at 1:14 AM, huzhi001 at 208suo.com wrote: > Signed-off-by: ZhiHu <huzhi001 at 208suo.com> > --- > .../gpu/drm/nouveau/nvkm/engine/fifo/gk104.c | 40 ++++++++++++++----- > 1 file changed, 29 insertions(+), 11 deletions(-)

NAK - checkpatch.pl is a (strongish) guideline, but not a rule. In the cases corrected in the patch series here, we format the switch cases on single lines as it dramatically improves the readability of what is otherwise just a /long/ list of slightly different static mappings. I don't believe we're the only part of the kernel to do this either. On Fri, 2023-07-14 at 14:58 +0800, huzhi001

Signed-off-by: ZhiHu <huzhi001 at 208suo.com> --- .../gpu/drm/nouveau/nvkm/engine/fifo/gk104.c | 40 ++++++++++++++----- 1 file changed, 29 insertions(+), 11 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gk104.c b/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gk104.c index d8a4d773a58c..b99e0a7c96bb 100644 --- a/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gk104.c +++

On Fri, Nov 21, 2014 at 1:16 AM, Andy Ritger <aritger at nvidia.com> wrote: > Hi Ilia, > > Actually 0x90b8 is different than copy engine. I'm not very familiar > with it, but 0x90b8 is an engine for performing LZO decompression as > part of performing the copy. It has a variety of limitations (e.g., > cannot handle blocklinear format), and was only in a few Fermi

Hi, The VBIOS on GM20x GPUs uses a slightly updated version of the DCB. I've posted an updated DCB spec here: ftp://download.nvidia.com/open-gpu-doc/DCB/2/DCB-4.x-Specification.html You can diff it against the previous version: ftp://download.nvidia.com/open-gpu-doc/DCB/1/DCB-4.0-Specification.html to see what changed (sorry for having to diff html files). The biggest differences are

fisher.test() gives a very small p-value, which is underflow on my machine. However, the log of it should not be underflow. I'm wondering if there is a way get log() of a small p-value. An approximation is acceptable in this case. Thank you! > fisher.test(rbind(c(10000,100000),c(100000,10000000)))$p.value [1] 0

Dear all, I'm a bit concerned about underflow problems. Such problems typically occur when two almost equal numbers are subtracted. I was wondering if R has any mechanisms for warning users about potential problems, or if any policy has been developed? To check, I just did: > 1.0000000000000001 - 1 [1] 0 > 1.000000000000001 - 1 [1] 1.110223e-15 > 1.00000000000001 - 1 [1]

When xl is called to create a domU and there is not enough memory available, then the autoballooning is called to extract memory from dom0. During the ballooning a loop in libxl_wait_for_free_memory() waits unless enough memory is available to create the domU. But because of a variable-underflow the loop can finish too soon and xl finally aborts with the message: xc: error: panic:

The besselK() function knows about overflows/underflows internally; there is a constant xmax_BESS_K in src/nmath/bessel.h (and referred to only in bessel_k.c), equal to 705.342, which is checked if expon.scaled is FALSE. (The equivalent number for bessel_i.c is 709, defined as exparg_BESS in bessel.h.) However, besselK(x) silently returns +Inf if x>705.342. This behavior is reasonable for

Hello http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1536 "Integer underflow in the file_printf function in the "file" program before 4.20 allows user-assisted attackers to execute arbitrary code via a file that triggers a heap-based buffer overflow." Is FreeBSD 5.x/6.x affected too? It looks the System has file 4.12. The port has 4.20. Regards, Thomas -- Terry

On Wed, Dec 10, 2014 at 7:36 AM, Ben Skeggs <skeggsb at gmail.com> wrote: > On Wed, Dec 10, 2014 at 4:26 AM, Andy Ritger <aritger at nvidia.com> wrote: >> Hi, > Hey Andy, > >> >> The VBIOS on GM20x GPUs uses a slightly updated version of the DCB. >> I've posted an updated DCB spec here: >> >>

NVIDIA GPUs include a common scripting language (devinit) that can be interpreted by a number of "engines", e.g. within a kernel-mode software driver, the VGA BIOS or an on-board small microcontroller which provides certain security assertions (the 'PMU'). This system allows a GPU programming sequence to be shared by multiple entities that would not otherwise be able to execute

The "vma->vm_pgoff" variable is an unsigned long so if it's larger than INT_MAX then "index" can be negative leading to an underflow. Fix this by changing the type of "index" to "unsigned long". Fixes: ddd89d0a059d ("vhost_vdpa: support doorbell mapping via mmap") Signed-off-by: Dan Carpenter <dan.carpenter at oracle.com> ---