[Nouveau] [Bug 98852] Nvidia graphics card fan not running or to slow, danger of overheating
https://bugs.freedesktop.org/show_bug.cgi?id=98852 --- Comment #13 from Martin Peres --- (In reply to Egon Niessner from comment #12) > I did some further tests with setting of the boot time parameter > in the yast kernel parameter line. > > Also with > > nouveau.runpm=0 or > nouveau.runpm=1 > the fan on the graphic card does not start. > > Beside this I use for PC tests also the systemrescue-Distribution > where DVD images can be found on > http://www.system-rescue-cd.org/Download > > I observed that until version 4.6.1 the fan on the graphic card was running. > Starting with version 4.7.1 the fan stops after loading of the rescue system. This is really weird as there are no changes related to the fan between 4.6 and 4.7 :s I guess, at this point, we need to check out what nouveau is doing versus what the blob is doing. Please download and compile envytools[0] and run the following command when running Nouveau, then when using the proprietary driver: - nvapeek e114 10 Please report back. [0] https://github.com/envytools/envytools/commits/master -- You are receiving this mail because: You are the assignee for the bug.___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH] nouveau/led: prevent compiling the led-code if nouveau=y and leds=m
The proper fix would have been to select LEDS_CLASS but this can lead
to a circular dependency, as found out by Arnd.
This patch implements Arnd's suggestion instead, at the cost of some
auto-magic for a fringe feature.
Cc: # 4.9.x-
Reported-by: Arnd Bergmann
Reported-by: Intel's 0-DAY
Fixes: 8d021d71b324 ("drm/nouveau/drm/nouveau: add a LED driver for the NVIDIA
logo")
Signed-off-by: Martin Peres
---
drivers/gpu/drm/nouveau/nouveau_led.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_led.h
b/drivers/gpu/drm/nouveau/nouveau_led.h
index 187ecdb..21a5775 100644
--- a/drivers/gpu/drm/nouveau/nouveau_led.h
+++ b/drivers/gpu/drm/nouveau/nouveau_led.h
@@ -42,7 +42,7 @@ nouveau_led(struct drm_device *dev)
}
/* nouveau_led.c */
-#if IS_ENABLED(CONFIG_LEDS_CLASS)
+#if IS_REACHABLE(CONFIG_LEDS_CLASS)
int nouveau_led_init(struct drm_device *dev);
void nouveau_led_suspend(struct drm_device *dev);
void nouveau_led_resume(struct drm_device *dev);
--
2.10.2
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH] nouveau/led: introduce CONFIG_DRM_NOUVEAU_LEDS
On 07/12/16 05:32, Martin Peres wrote: This fixes the auto-magic detection of LEDS_CLASS by fixing the case where nouveau would be built-in and the LEDS_CLASS would be built as as module. Cc: # 4.9.x- Reported-by: Intel's 0-DAY Signed-off-by: Martin Peres --- drivers/gpu/drm/nouveau/Kbuild | 2 +- drivers/gpu/drm/nouveau/Kconfig | 9 + 2 files changed, 10 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/Kbuild b/drivers/gpu/drm/nouveau/Kbuild index fde6e36..0935396 100644 --- a/drivers/gpu/drm/nouveau/Kbuild +++ b/drivers/gpu/drm/nouveau/Kbuild @@ -22,7 +22,7 @@ nouveau-$(CONFIG_DEBUG_FS) += nouveau_debugfs.o nouveau-y += nouveau_drm.o nouveau-y += nouveau_hwmon.o nouveau-$(CONFIG_COMPAT) += nouveau_ioc32.o -nouveau-$(CONFIG_LEDS_CLASS) += nouveau_led.o +nouveau-$(CONFIG_DRM_NOUVEAU_LEDS) += nouveau_led.o nouveau-y += nouveau_nvif.o nouveau-$(CONFIG_NOUVEAU_PLATFORM_DRIVER) += nouveau_platform.o nouveau-y += nouveau_usif.o # userspace <-> nvif diff --git a/drivers/gpu/drm/nouveau/Kconfig b/drivers/gpu/drm/nouveau/Kconfig index 2922a82..9dbb816 100644 --- a/drivers/gpu/drm/nouveau/Kconfig +++ b/drivers/gpu/drm/nouveau/Kconfig @@ -16,6 +16,7 @@ config DRM_NOUVEAU select INPUT if ACPI && X86 select THERMAL if ACPI && X86 select ACPI_VIDEO if ACPI && X86 + select LEDS_CLASS if DRM_NOUVEAU_LEDS help Choose this option for open-source NVIDIA support. @@ -62,3 +63,11 @@ config DRM_NOUVEAU_BACKLIGHT help Say Y here if you want to control the backlight of your display (e.g. a laptop panel). + +config DRM_NOUVEAU_LEDS + bool "Support for high-end GPUs' NVIDIA-logo LED control" + depends on DRM_NOUVEAU + default y + help + Say Y here if you want to control the LED behind the NVIDIA logo on + high-end GPUs. Cancel this,the thread "[PATCH] drm/nouveau: fix LEDS_CLASS=m configuration" on DRI-devel explained why it was a bad idea (circular dependencies). Will implement his proposal of using IS_REACHABLE instead of IS_DEFINED. Martin ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH] nouveau/led: introduce CONFIG_DRM_NOUVEAU_LEDS
This fixes the auto-magic detection of LEDS_CLASS by fixing the case where nouveau would be built-in and the LEDS_CLASS would be built as as module. Cc: # 4.9.x- Reported-by: Intel's 0-DAY Signed-off-by: Martin Peres --- drivers/gpu/drm/nouveau/Kbuild | 2 +- drivers/gpu/drm/nouveau/Kconfig | 9 + 2 files changed, 10 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/Kbuild b/drivers/gpu/drm/nouveau/Kbuild index fde6e36..0935396 100644 --- a/drivers/gpu/drm/nouveau/Kbuild +++ b/drivers/gpu/drm/nouveau/Kbuild @@ -22,7 +22,7 @@ nouveau-$(CONFIG_DEBUG_FS) += nouveau_debugfs.o nouveau-y += nouveau_drm.o nouveau-y += nouveau_hwmon.o nouveau-$(CONFIG_COMPAT) += nouveau_ioc32.o -nouveau-$(CONFIG_LEDS_CLASS) += nouveau_led.o +nouveau-$(CONFIG_DRM_NOUVEAU_LEDS) += nouveau_led.o nouveau-y += nouveau_nvif.o nouveau-$(CONFIG_NOUVEAU_PLATFORM_DRIVER) += nouveau_platform.o nouveau-y += nouveau_usif.o # userspace <-> nvif diff --git a/drivers/gpu/drm/nouveau/Kconfig b/drivers/gpu/drm/nouveau/Kconfig index 2922a82..9dbb816 100644 --- a/drivers/gpu/drm/nouveau/Kconfig +++ b/drivers/gpu/drm/nouveau/Kconfig @@ -16,6 +16,7 @@ config DRM_NOUVEAU select INPUT if ACPI && X86 select THERMAL if ACPI && X86 select ACPI_VIDEO if ACPI && X86 + select LEDS_CLASS if DRM_NOUVEAU_LEDS help Choose this option for open-source NVIDIA support. @@ -62,3 +63,11 @@ config DRM_NOUVEAU_BACKLIGHT help Say Y here if you want to control the backlight of your display (e.g. a laptop panel). + +config DRM_NOUVEAU_LEDS + bool "Support for high-end GPUs' NVIDIA-logo LED control" + depends on DRM_NOUVEAU + default y + help + Say Y here if you want to control the LED behind the NVIDIA logo on + high-end GPUs. -- 2.10.2 ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 94727] [NV30/NV40] nouveau/pushbuf.c:238: pushbuf_krel: Assertion `bkref` failed.
https://bugs.freedesktop.org/show_bug.cgi?id=94727 --- Comment #8 from Ilia Mirkin --- OK, well staring at the code didn't do me much good. bkref == NULL means that the pushbuf thing doesn't know about the bo we're trying to reloc. However just a few lines above in nv30_transfer_rect_m2mf we do nouveau_pushbuf_refn (push, refs, 2) which should tell it about the src/dst bo's. So either there's concurrency going on, or something's not working as advertised. In the no-concurrency case, I'd need repro steps (that can't start with "install tons of software"). -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 94727] nouveau/pushbuf.c:238: pushbuf_krel: Assertion `bkref` failed.
https://bugs.freedesktop.org/show_bug.cgi?id=94727 --- Comment #7 from Ilia Mirkin --- (In reply to Olivier Fourdan from comment #5) > This is affecting Xwayland as well, as reported downstream in Fedora 25: > > https://bugzilla.redhat.com/show_bug.cgi?id=1372878 > > wrt comment 1, Xwayland is not using multithreaded GL, even through glamor, > is it? Oh dear. That's using glamor on a nv30 (or nv40) board. The nv30 driver is ... erm ... imperfect. And looking back at the first comments, the Quadro 1500M appears to be a G71, and the 6600LE is obviously some nv4x as well. In which case these issues are just as likely to not be caused by the multithreading stuff at all. But you're in (limited) luck - I have a NV34 plugged in. If you can send me an apitrace I can replay to cause this to happen, I can investigate [and the NV34 doesn't support as much stuff as a NV4x, but I can fake it]. I'll also stare at the nv30_resource_copy_region code to see what it's missing. -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 94727] [NV30/NV40] nouveau/pushbuf.c:238: pushbuf_krel: Assertion `bkref` failed.
https://bugs.freedesktop.org/show_bug.cgi?id=94727 Ilia Mirkin changed: What|Removed |Added Summary|nouveau/pushbuf.c:238: |[NV30/NV40] |pushbuf_krel: Assertion |nouveau/pushbuf.c:238: |`bkref` failed. |pushbuf_krel: Assertion ||`bkref` failed. -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 91954] "link training failed": nouveau does not recover from monitor suspend
https://bugs.freedesktop.org/show_bug.cgi?id=91954 --- Comment #11 from Martin Peres --- We are trying to push in DRM link-status that will allow the userspace to react to errors like this. I may be convinced to add support for this in Nouveau-drm and -nouveau, since I studied it and have patches for -modesetting already. -- You are receiving this mail because: You are the assignee for the bug.___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
