Re: [Nouveau] [PATCH 1/3] drm/nouveau/therm: turn on a fan only when crossing threshold in positive direction
On 03/02/2013 21:07, Marcin Slusarz wrote:
+ the same for shutdown threshold - seems impossible, but shutdown can fail.
Signed-off-by: Marcin Slusarz marcin.slus...@gmail.com
Looks good. Please add my signed-off-by
Signed-off-by: Martin Peres martin.pe...@labri.fr
---
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 100644
--- a/drivers/gpu/drm/nouveau/core/subdev/therm/temp.c
+++ b/drivers/gpu/drm/nouveau/core/subdev/therm/temp.c
@@ -105,7 +105,7 @@ void nouveau_therm_sensor_event(struct nouveau_therm *therm,
return;
if (dir == NOUVEAU_THERM_THRS_FALLING)
- nv_info(therm, temperature (%u C) went bellow the '%s'
threshold\n,
+ nv_info(therm, temperature (%u C) went below the '%s'
threshold\n,
temperature, thresolds[thrs]);
else
nv_info(therm, temperature (%u C) hit the '%s' threshold\n,
@@ -114,8 +114,10 @@ void nouveau_therm_sensor_event(struct nouveau_therm
*therm,
active = (dir == NOUVEAU_THERM_THRS_RISING);
switch (thrs) {
case NOUVEAU_THERM_THRS_FANBOOST:
- nouveau_therm_fan_set(therm, true, 100);
- nouveau_therm_mode(therm, NOUVEAU_THERM_CTRL_AUTO);
+ if (active) {
+ nouveau_therm_fan_set(therm, true, 100);
+ nouveau_therm_mode(therm, NOUVEAU_THERM_CTRL_AUTO);
+ }
break;
case NOUVEAU_THERM_THRS_DOWNCLOCK:
if (priv-emergency.downclock)
@@ -126,7 +128,8 @@ void nouveau_therm_sensor_event(struct nouveau_therm *therm,
priv-emergency.pause(therm, active);
break;
case NOUVEAU_THERM_THRS_SHUTDOWN:
- orderly_poweroff(true);
+ if (active)
+ orderly_poweroff(true);
break;
case NOUVEAU_THERM_THRS_NR:
break;
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 2/3] drm/nv40/therm: reset temperature sensor on init
On 03/02/2013 21:07, Marcin Slusarz wrote: Current uninitialized sensor detection does not work for me on nv4b and sensor returns crazy values (190°C). It stabilises later, but it's too late - therm code shutdowns the machine... Let's just reset it on init. Signed-off-by: Marcin Slusarz marcin.slus...@gmail.com Hmm, so it means the bios initializes your sensor at POST. This was not the case on mine and we used to rely on the fact that nv4x's sensor was not initialized. Anyway, forcing a reset is not a bad idea. Please add my signed-off-by. Thanks for your ptherm patchset :) ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 3/3] drm/nouveau/therm: use workqueue to shutdown the machine
On 03/02/2013 21:07, Marcin Slusarz wrote: orderly_poweroff cannot be called from atomic context. Signed-off-by: Marcin Slusarz marcin.slus...@gmail.com Oops, my bad. Please add my signed-off-by. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH] drm/nouveau: add lockdep annotations
Hi Maarten
On Mon, 2013-02-04 at 22:59 +0100, Maarten Lankhorst wrote:
Op 04-02-13 22:30, Marcin Slusarz schreef:
1) Lockdep thinks all nouveau subdevs belong to the same class and can be
locked in arbitrary order, which is not true (at least in general case).
Tell it to distinguish subdevs by (o)class type.
Apart from this specific case, is there any other reason why we require being
able to nest 2 subdev locks?
Add a NVOBJ_FLAG_CREATE_EXCLUSIVE flag to nouveau_engctx_create and return
-EBUSY if there is any existing object. Problem solved, and lockdep is still
generic.
2) DRM client can be locked under user client lock - tell lockdep to put DRM
client lock in a separate class.
Can you copy paste a typical lockdep splat for this? Also this should be a
separate patch. :-)
PS - Deep call chain. Has anyone looked into max stack depth yet?
[5.995881] =
[5.995886] [ INFO: possible recursive locking detected ]
[5.995892] 3.8.0-next-20130125+ttypatch-xeon+lockdep #20130125+ttypatch Not
tainted
[5.995898] -
[5.995904] modprobe/275 is trying to acquire lock:
[5.995909] (subdev-mutex){+.+.+.}, at: [a00d10b8]
nouveau_instobj_create_+0x48/0x90 [nouveau]
[5.995955]
[5.995955] but task is already holding lock:
[5.995961] (subdev-mutex){+.+.+.}, at: [a00da3b5]
nv50_disp_data_ctor+0x65/0xd0 [nouveau]
[5.995989]
[5.995989] other info that might help us debug this:
[5.995995] Possible unsafe locking scenario:
[5.995995]
[5.996001]CPU0
[5.996004]
[5.996005] lock(subdev-mutex);
[5.996005] lock(subdev-mutex);
[5.996005]
[5.996005] *** DEADLOCK ***
[5.996005]
[5.996005] May be due to missing lock nesting notation
[5.996005]
[5.996005] 4 locks held by modprobe/275:
[5.996005] #0: (__lockdep_no_validate__){..}, at:
[8146fa5b] __driver_attach+0x5b/0xb0
[5.996005] #1: (__lockdep_no_validate__){..}, at:
[8146fa69] __driver_attach+0x69/0xb0
[5.996005] #2: (drm_global_mutex){+.+.+.}, at: [a0028d86]
drm_get_pci_dev+0xc6/0x2d0 [drm]
[5.996005] #3: (subdev-mutex){+.+.+.}, at: [a00da3b5]
nv50_disp_data_ctor+0x65/0xd0 [nouveau]
[5.996005]
[5.996005] stack backtrace:
[5.996005] Pid: 275, comm: modprobe Not tainted
3.8.0-next-20130125+ttypatch-xeon+lockdep #20130125+ttypatch
[5.996005] Call Trace:
[5.996005] [810bd437] __lock_acquire+0x687/0x1a70
[5.996005] [810bf70b] ? mark_held_locks+0x9b/0x100
[5.996005] [810bf87d] ? trace_hardirqs_on_caller+0x10d/0x1a0
[5.996005] [810bf91d] ? trace_hardirqs_on+0xd/0x10
[5.996005] [8170a87a] ? _raw_write_unlock_irqrestore+0x4a/0x90
[5.996005] [810bedc8] lock_acquire+0x98/0x150
[5.996005] [a00d10b8] ? nouveau_instobj_create_+0x48/0x90
[nouveau]
[5.996005] [a00d10b8] ? nouveau_instobj_create_+0x48/0x90
[nouveau]
[5.996005] [81707f60] mutex_lock_nested+0x50/0x390
[5.996005] [a00d10b8] ? nouveau_instobj_create_+0x48/0x90
[nouveau]
[5.996005] [a00b6376] ? nouveau_object_ref+0x46/0xd0 [nouveau]
[5.996005] [a00b64b5] ? nouveau_object_create_+0x65/0xa0
[nouveau]
[5.996005] [a00d10b8] nouveau_instobj_create_+0x48/0x90 [nouveau]
[5.996005] [a00d1be1] nv50_instobj_ctor+0x51/0xf0 [nouveau]
[5.996005] [a00b62a8] nouveau_object_ctor+0x38/0xc0 [nouveau]
[5.996005] [a00d1b36] nv50_instmem_alloc+0x26/0x30 [nouveau]
[5.996005] [a00b49a7] nouveau_gpuobj_create_+0x247/0x2f0
[nouveau]
[5.996005] [8170afed] ? _raw_spin_unlock_irqrestore+0x6d/0x90
[5.996005] [810bf87d] ? trace_hardirqs_on_caller+0x10d/0x1a0
[5.996005] [a00b34dc] nouveau_engctx_create_+0x26c/0x2b0
[nouveau]
[5.996005] [a00da411] nv50_disp_data_ctor+0xc1/0xd0 [nouveau]
[5.996005] [a00b62a8] nouveau_object_ctor+0x38/0xc0 [nouveau]
[5.996005] [a00b6b82] nouveau_object_new+0x112/0x240 [nouveau]
[5.996005] [a0155fe5] nv50_display_create+0x1a5/0x890 [nouveau]
[5.996005] [8107837b] ? __cancel_work_timer+0x8b/0xe0
[5.996005] [a013c80b] nouveau_display_create+0x3cb/0x670
[nouveau]
[5.996005] [a012ba0f] nouveau_drm_load+0x26f/0x590 [nouveau]
[5.996005] [8146caee] ? device_register+0x1e/0x30
[5.996005] [a002a626] ? drm_sysfs_device_add+0x86/0xb0 [drm]
[5.996005] [a0028e46] drm_get_pci_dev+0x186/0x2d0 [drm]
[5.996005] [a012bf9a] nouveau_drm_probe+0x26a/0x2c0 [nouveau]
[5.996005] [8170afca] ? _raw_spin_unlock_irqrestore+0x4a/0x90
[5.996005] [81393a8b] local_pci_probe+0x4b/0x80
[5.996005]
Re: [Nouveau] Monitor with corrupted EDID
On 02/07/2013 08:37 PM, mwesten wrote: I recently used a DOS program called ddcw.exe to fix the corrupted EDID on one of my monitors. I already tried to write the good EDID into the monitor but I failed. I also tried to do that using i2cset with the same result. I suspect the EEPROM is write protected... I'll give a shot to this program. If that doesn't work, the drm_kms_helper module in newer kernels should have a parameter to get around the problem. See https://www.osadl.org/Single-View.111+M50eaf2f2c66.0.html That's working! My monitor now is powered and I can use it. There's only one minor issue: the nouveau module keeps complaining about the wrong EDID received by this monitor. Is there a way to tell the driver to stop probing the monitor? Thanks a lot for the help Flavio ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Monitor with corrupted EDID
On 02/08/2013 03:23 AM, Flavio Castelli wrote: On 02/07/2013 08:37 PM, mwesten wrote: I recently used a DOS program called ddcw.exe to fix the corrupted EDID on one of my monitors. I already tried to write the good EDID into the monitor but I failed. I also tried to do that using i2cset with the same result. I suspect the EEPROM is write protected... I'll give a shot to this program. My suspicion is that if the EDID data got corrupted in the first place, then it's not protected. I don't know about i2cset, or any other methods. If that doesn't work, the drm_kms_helper module in newer kernels should have a parameter to get around the problem. See https://www.osadl.org/Single-View.111+M50eaf2f2c66.0.html That's working! My monitor now is powered and I can use it. There's only one minor issue: the nouveau module keeps complaining about the wrong EDID received by this monitor. Is there a way to tell the driver to stop probing the monitor? I've noticed that too, and I'm not aware of a way to prevent it. Thanks a lot for the help No problem. -Mike ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Monitor with corrupted EDID
On 02/08/2013 11:44 AM, mwesten wrote: My suspicion is that if the EDID data got corrupted in the first place, then it's not protected. I don't know about i2cset, or any other methods. That's exactly what I'm thinking. I'm trying to overwrite the EEPROM using a DVI cable (since it's the DVI EDID which is broken). I saw other people used a vga - dvi cable to do that because some pins could not be exposed by the DVI cable. I'm don't fully believe in this explanation. Cheers Flavio ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 60510] New: Firefox 18.0.2 Crash On Nvidia GeForce2
https://bugs.freedesktop.org/show_bug.cgi?id=60510 Priority: medium Bug ID: 60510 Assignee: nouveau@lists.freedesktop.org Summary: Firefox 18.0.2 Crash On Nvidia GeForce2 QA Contact: xorg-t...@lists.x.org Severity: normal Classification: Unclassified OS: Linux (All) Reporter: sacanti.erne...@gmail.com Hardware: x86 (IA32) Status: NEW Version: unspecified Component: Driver/nouveau Product: xorg Firefox 18.0.2 and Thunderbird 17.0.2 crashes randomly. Error Report:GLXtest process failed (exited with status 1): X error occurred in GLX probe, error_code=11, request_code=154, minor_code=3 lspci command: 02:00.0 VGA compatible controller: nVidia Corporation NVCrush11 [GeForce2 MX Integrated Graphics] (rev b1) (prog-if 00 [VGA controller]) Subsystem: nVidia Corporation Device 0c11 Flags: bus master, 66MHz, medium devsel, latency 32, IRQ 19 Memory at ec00 (32-bit, non-prefetchable) [size=16M] Memory at f000 (32-bit, prefetchable) [size=128M] Expansion ROM at efff [disabled] [size=64K] Capabilities: access denied Kernel driver in use: nouveau Kernel modules: nouveau, nvidiafb, rivafb I'm using Linux Mint 12 Lisa (GNU/Linux 3.0.0-12-generic i686) -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 60516] New: nouveau driver graphics corrupted in 3.7 kernel for nvidia FX5200 [NV34] hardware
https://bugs.freedesktop.org/show_bug.cgi?id=60516 Priority: medium Bug ID: 60516 Assignee: nouveau@lists.freedesktop.org Summary: nouveau driver graphics corrupted in 3.7 kernel for nvidia FX5200 [NV34] hardware QA Contact: xorg-t...@lists.x.org Severity: normal Classification: Unclassified OS: Linux (All) Reporter: lee_mathe...@hotmail.com Hardware: x86 (IA32) Status: NEW Version: unspecified Component: Driver/nouveau Product: xorg The 3.7 kernel nouveau driver provides a corrupted display when booting to a PC with an older nvidia FX5200 graphic card. This was tested with: * openSUSE-12.3 32-bit beta1 KDE liveCD and 3.7.1 kernel * openSUSE-12.3 32-bit RC1 KDE liveCD and 3.7.6-1.2 kernel * openSUSE-12.2 with the 32-bit Tumbleweed 3.7.2-18 kernel (on an LXDE desktop) * Porteus-1.2 (release candidate version) which has the 3.7.5 kernel (and is slackware based). * Bodhi-2.2.0-32 which has the 3.7.0-7 kernel (and is Ubuntu based) I rolled back the openSUSE-12.2 with the 32-bit Tumbleweed 3.7.2-18 kernel (which I noted had the graphics corruption) to a 3.4.6 kernel (with nouveau) and it works fine on this same PC with both a KDE and an LXDE desktop. I tested a Knoppix-7.0.5 with its 3.6.11 kernel which booted fine to superb graphics with the nouveau driver, to a nice 1680x1050 resolution on this old FX5200 (NV34) hardware (with special desktop effects working nicely). Ergo I believe the 3.7 kernel is at fault. I have raised a bug report on openSUSE here: https://bugzilla.novell.com/show_bug.cgi?id=800686 but I believe the problem to be upstream with the nouveau driver. The graphics look like this: http://www.imagebam.com/image/aaa1db233074551 and that is pretty much the same appearance across all GNU/Linux distribution versions that I have tested with the 3.7.x kernel and the nouveau driver. dmesg of openSUSE-12.3 B1 w/3.7.1 kernel : https://bugzilla.novell.com/attachment.cgi?id=522124 xorg.0.log of openSUSE-12.3 B1 w/3.7.1 kernel: https://bugzilla.novell.com/attachment.cgi?id=522125 /var/log/messages of openSUSE-12.3 B1 w/3.7.1 kernel: https://bugzilla.novell.com/attachment.cgi?id=522126 xsesson errors of openSUSE-12.3 B1 w/3.7.1 kernel: https://bugzilla.novell.com/attachment.cgi?id=522127 I looked at the image of the corruption (with the 3.7 kernel) on NVIDIA GeForce 8400M G graphics card in this bug report https://bugs.freedesktop.org/show_bug.cgi?id=58378 and it looks difference, hence I believe that 'may' be a different problem. -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 60516] nouveau driver graphics corrupted in 3.7 kernel for nvidia FX5200 [NV34] hardware
https://bugs.freedesktop.org/show_bug.cgi?id=60516 --- Comment #1 from Lee Matheson lee_mathe...@hotmail.com --- I note a bug report on Red Hat bugzilla (kernel-PAE-3.7.3-101.fc17.i686) which could be the same: https://bugzilla.redhat.com/show_bug.cgi?id=905631 (and also 3.8.0-0.rc5.git0.2.fc19.i686.PAE in same bug report has possible same problem) -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 60516] nouveau driver graphics corrupted in 3.7 kernel for nvidia FX5200 [NV34] hardware
https://bugs.freedesktop.org/show_bug.cgi?id=60516 --- Comment #2 from Lee Matheson lee_mathe...@hotmail.com --- This bug here may be the same: https://bugs.freedesktop.org/show_bug.cgi?id=58261 -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 57350] [nouveau, linux-3.7-rc] Broken cursor and kernel log swamped with trapped reads/writes from BAR/PFIFO_READ/FB
https://bugs.freedesktop.org/show_bug.cgi?id=57350 --- Comment #11 from Ankur an...@lipidity.com --- I also have this issue on a MacBook5,1 Bottom half of mouse cursor is transparent. There are thousands of trapped read at ... on channel ... BAR/PFIFO_READ/FB reason: PAGE_NOT_PRESENT with occasional trapped writes. All issues resolve after resuming from suspend. Running Arch Linux (kernel 3.7.5 x86_64) xf86-video-nouveau 1.0.6 xorg-server 1.12.2 libdrm 2.4.41 -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
