Re: [Nouveau] GeForce FX5200 dual DVI Samsung 204b
Pekka Paalanen p...@iki.fi writes: On Tue, 28 Sep 2010 18:17:25 +0200 Grzesiek Sójka p...@pfu.pl wrote: I'm completely lost at the moment so let me start from the beginning. First thing is that everything works fine with Nvidia binary drivers, which means that hardware is rather OK. After loading of the nouveau.ko the monitor connected to DVI-I-1 goes to the standby mode. I do not know if the head is turned of or maybe some kind of rates are too high/low. I was trying to play with video=DVI-I-1: with different modes and switches (M/R/D/e) and nothing. At the some time (after loading nouveau.ko) the monitor connected with the DVI-I-2 starts to blink. And again I was playing with the video=DVI-I-2:??? and nothing. I thought that maybe after starting the xorg I will get the proper image at both monitor. Unfortunately - no success. According to the Xorg log file (Option ModeDebug true) all the refresh rates are ok. Moreover I was trying to use different ModeLines and nothing. The X server claims that there are two monitor connected and working but the first one is in standby mode and the second is blinking. Any ideas?? If you need some more information please let me know. Yes, the complete kernel and X logs, like I have requested twice before. That is the minimum before anyone will seriously start looking into it. Before doing that, can you try latest git again? I pushed a patch yesterday that may help with it. Preferrably, use the simplest setup that fails: - only one monitor physically connected - the following xorg.conf: And use drm.debug=4 in your kernel command line, that should tell you what timings are being used exactly. Section Device Identifier n Driver nouveau Option ModeDebug true EndSection Thanks. pgpwI3BIFYzzl.pgp Description: PGP signature ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 30387] Fade out when asking for permissions crashes X
https://bugs.freedesktop.org/show_bug.cgi?id=30387 --- Comment #3 from Francisco Jerez curroje...@riseup.net 2010-09-30 04:28:51 PDT --- (In reply to comment #0) To reproduce just open something that will ask for permissions. I choose synaptic. It crashes on the fadeout to ask for a password. It doesn't look like it's crashing in nouveau. You could get debug symbols for your X server and try to reproduce the crash with gdb attached, that would get you a more meaningful backtrace. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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
Re: [Nouveau] GeForce FX5200 dual DVI Samsung 204b
I did download new sources and applied the amd-agp patch but no change. I get the some problems. Here is the dmesg without modeset: http://yen.ipipan.waw.pl/~gs159090/tmp/txt.gz Then I added following modeline to the file drm_edid_modes.h /* 1600x1...@50hz */ { DRM_MODE(1600x1200, DRM_MODE_TYPE_DRIVER, 135000, 1600, 1664, 1856, 2160, 0, 1200, 1201, 1204, 1250, 0, DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC) }, and tried to force the mode by setting video=DVI-I-[12]:1600x1200...@50. No luck, here you have the dmesg: http://yen.ipipan.waw.pl/~gs159090/tmp/txt2.gz I also did some test with the xorg: http://yen.ipipan.waw.pl/~gs159090/tmp/Xorg.0.log.gz http://yen.ipipan.waw.pl/~gs159090/tmp/xorg.conf.gz The interesting thing is that according to the dmesg the xorgs tries to set the mode: Modeline 58:1600x1200_def 0 144000 1600 1628 1788 1920 1200 1201 1204 1250 0x0 0x0 but just after the mode is used: Modeline 75:1600x1200 0 162000 1600 1664 1856 2160 1200 1201 1204 1250 0x48 0x5 Here is the xrandr --verbose output: http://yen.ipipan.waw.pl/~gs159090/tmp/xrandr.nouveau.gz Just in case I also recorded the xrandr output in the case of the Nvidia binary driver: http://yen.ipipan.waw.pl/~gs159090/tmp/xrandr.nvidia.gz I was really surprised because the xrandr claims that the refresh rate is 50Hz but at the OSD there is an information that the refresh rate is 60Hz. What to think?? Next thing is that the refresh rate of 50Hz is out of the monitor range: VertRefresh 56 - 75. So the Xserver should not to set it to 50. All the time (when using nouveau.ko) the monitor #1 is switched off and #2 is blinking. It does not mater if Xserver is running or not. Please let me know if you need any more data. Thanks for any help in advance. Regards ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] GeForce FX5200 dual DVI Samsung 204b
Grzesiek Sójka p...@pfu.pl writes: I did download new sources and applied the amd-agp patch but no change. I get the some problems. Here is the dmesg without modeset: http://yen.ipipan.waw.pl/~gs159090/tmp/txt.gz Then I added following modeline to the file drm_edid_modes.h /* 1600x1...@50hz */ { DRM_MODE(1600x1200, DRM_MODE_TYPE_DRIVER, 135000, 1600, 1664, 1856, 2160, 0, 1200, 1201, 1204, 1250, 0, DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC) }, and tried to force the mode by setting video=DVI-I-[12]:1600x1200...@50. No luck, here you have the dmesg: http://yen.ipipan.waw.pl/~gs159090/tmp/txt2.gz I also did some test with the xorg: http://yen.ipipan.waw.pl/~gs159090/tmp/Xorg.0.log.gz http://yen.ipipan.waw.pl/~gs159090/tmp/xorg.conf.gz The interesting thing is that according to the dmesg the xorgs tries to set the mode: Modeline 58:1600x1200_def 0 144000 1600 1628 1788 1920 1200 1201 1204 1250 0x0 0x0 but just after the mode is used: Modeline 75:1600x1200 0 162000 1600 1664 1856 2160 1200 1201 1204 1250 0x48 0x5 Here is the xrandr --verbose output: http://yen.ipipan.waw.pl/~gs159090/tmp/xrandr.nouveau.gz Does the following command help? $ xrandr --output DVI-I-2 --set scaling mode None Just in case I also recorded the xrandr output in the case of the Nvidia binary driver: http://yen.ipipan.waw.pl/~gs159090/tmp/xrandr.nvidia.gz I was really surprised because the xrandr claims that the refresh rate is 50Hz but at the OSD there is an information that the refresh rate is 60Hz. What to think?? Next thing is that the refresh rate of 50Hz is out of the monitor range: VertRefresh 56 - 75. So the Xserver should not to set it to 50. Don't worry about that, IIRC it's just a hack nvidia did to differentiate between meta-modes with the same resolution but a different set of enabled outputs, instead of switching to RandR12. All the time (when using nouveau.ko) the monitor #1 is switched off and #2 is blinking. It does not mater if Xserver is running or not. Please let me know if you need any more data. Thanks for any help in advance. Regards pgpyOgvSpsQlp.pgp Description: PGP signature ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Add pause/unpause methods for PFIFO PGRAPH. Use them to get stable clock changes
Hi, Here is an updated set of patches (in regards on comments got on IRC and an handling error when using several channels). These updated patch allow me to run 5 glxgears at the same time and reclock the card almost 100 times per second without crashing. Don't panic if you get theses in your logs: PGRAPH: wait for idle fail: 0103! PGRAPH: PGRAPH paused while running a ctxprog, NV40_PGRAPH_CTXCTL_0310 = 0x11 It means that we tried to reclock during a context switch. It would be safe to continue as when the program is at 0x11, it means it waits for another process (which is stopped because we stopped PFIFO before). I could allow to get this value (ie continue and clock), but if someone changes the ctxprog, he would have to update it here. For the moment, I don't mind if from time to time, setting the clocks fail. Waiting for your comments. Regards, Martin From a219259d5ea46fb18f8e36c6c5a2f9e9e63fe53e Mon Sep 17 00:00:00 2001 From: Martin Peres martin.pe...@ensi-bourges.fr Date: Wed, 29 Sep 2010 14:56:37 +0200 Subject: [PATCH 1/3] Add pause/unpause methods to the PFIFO engine --- drivers/gpu/drm/nouveau/nouveau_drv.h |8 drivers/gpu/drm/nouveau/nouveau_reg.h |1 + drivers/gpu/drm/nouveau/nouveau_state.c | 14 ++ drivers/gpu/drm/nouveau/nv50_fifo.c | 18 ++ 4 files changed, 41 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.h b/drivers/gpu/drm/nouveau/nouveau_drv.h index 591254e..c256c0a 100644 --- a/drivers/gpu/drm/nouveau/nouveau_drv.h +++ b/drivers/gpu/drm/nouveau/nouveau_drv.h @@ -304,6 +304,9 @@ struct nouveau_fifo_engine { void (*destroy_context)(struct nouveau_channel *); int (*load_context)(struct nouveau_channel *); int (*unload_context)(struct drm_device *); + + int (*pause)(struct drm_device *); + int (*unpause)(struct drm_device *); }; struct nouveau_pgraph_object_method { @@ -339,6 +342,9 @@ struct nouveau_pgraph_engine { void (*set_region_tiling)(struct drm_device *dev, int i, uint32_t addr, uint32_t size, uint32_t pitch); + + int (*pause)(struct drm_device *); + int (*unpause)(struct drm_device *); }; struct nouveau_display_engine { @@ -1036,6 +1042,8 @@ extern int nv50_fifo_create_context(struct nouveau_channel *); extern void nv50_fifo_destroy_context(struct nouveau_channel *); extern int nv50_fifo_load_context(struct nouveau_channel *); extern int nv50_fifo_unload_context(struct drm_device *); +extern int nv50_fifo_pause(struct drm_device *); +extern int nv50_fifo_unpause(struct drm_device *); /* nvc0_fifo.c */ extern int nvc0_fifo_init(struct drm_device *); diff --git a/drivers/gpu/drm/nouveau/nouveau_reg.h b/drivers/gpu/drm/nouveau/nouveau_reg.h index 1b42541..ee6dae1 100644 --- a/drivers/gpu/drm/nouveau/nouveau_reg.h +++ b/drivers/gpu/drm/nouveau/nouveau_reg.h @@ -701,6 +701,7 @@ #define NV50_PGRAPH 0x0040 #define NV50_PGRAPH__LEN 0x1 #define NV50_PGRAPH__ESIZE 0x1 +#define NV50_PFIFO_FREEZE 0x2504 #define NV50_PDISPLAY0x0061 #define NV50_PDISPLAY_OBJECTS0x00610010 diff --git a/drivers/gpu/drm/nouveau/nouveau_state.c b/drivers/gpu/drm/nouveau/nouveau_state.c index 75bce91..cfc34f5 100644 --- a/drivers/gpu/drm/nouveau/nouveau_state.c +++ b/drivers/gpu/drm/nouveau/nouveau_state.c @@ -86,6 +86,8 @@ static int nouveau_init_engine_ptrs(struct drm_device *dev) engine-fifo.destroy_context = nv04_fifo_destroy_context; engine-fifo.load_context = nv04_fifo_load_context; engine-fifo.unload_context = nv04_fifo_unload_context; + engine-fifo.pause = NULL; + engine-fifo.unpause = NULL; engine-display.early_init = nv04_display_early_init; engine-display.late_takedown = nv04_display_late_takedown; engine-display.create = nv04_display_create; @@ -140,6 +142,8 @@ static int nouveau_init_engine_ptrs(struct drm_device *dev) engine-fifo.destroy_context = nv10_fifo_destroy_context; engine-fifo.load_context = nv10_fifo_load_context; engine-fifo.unload_context = nv10_fifo_unload_context; + engine-fifo.pause = NULL; + engine-fifo.unpause = NULL; engine-display.early_init = nv04_display_early_init; engine-display.late_takedown = nv04_display_late_takedown; engine-display.create = nv04_display_create; @@ -194,6 +198,8 @@ static int nouveau_init_engine_ptrs(struct drm_device *dev) engine-fifo.destroy_context = nv10_fifo_destroy_context; engine-fifo.load_context = nv10_fifo_load_context; engine-fifo.unload_context = nv10_fifo_unload_context; + engine-fifo.pause = NULL; + engine-fifo.unpause = NULL; engine-display.early_init = nv04_display_early_init; engine-display.late_takedown = nv04_display_late_takedown;
[Nouveau] [Bug 29714] Corrupted image (running stripes) on Quadro NVS 3100M with embedded DisplayPort (HP EliteBook 8440p)
https://bugs.freedesktop.org/show_bug.cgi?id=29714 Yuriy Khomchik hom...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #21 from Yuriy Khomchik hom...@gmail.com 2010-09-30 12:37:56 PDT --- Commit http://cgit.freedesktop.org/nouveau/linux-2.6/commit/?id=2aa335a9b84e5403c3d0be3a35237c6c695d812e fixes this bug. Ben, thank you very much. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 29171] Garbled console on Macbook 13 (6, 1 9400M]) when using EFI
https://bugs.freedesktop.org/show_bug.cgi?id=29171 --- Comment #24 from Yuriy Khomchik hom...@gmail.com 2010-09-30 12:41:47 PDT --- Commit http://cgit.freedesktop.org/nouveau/linux-2.6/commit/?id=2aa335a9b84e5403c3d0be3a35237c6c695d812e fixes similar bug 29714. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 30375] (NV34) X server using 100% cpu with latest nouveau.git and xf86-video-nouveau.git
https://bugs.freedesktop.org/show_bug.cgi?id=30375 --- Comment #3 from walt w41...@gmail.com 2010-09-30 15:40:27 PDT --- Oh dear, I spoke much too soon. I just discovered that the bug disappeared only because I forgot to change xorg.conf from nv back to nouveau :-( Now that I really *am* using nouveau, the CPU is still pegged at 99% by Xorg when viewing the npr.org website with the latest nightly build of firefox. One new observation that I didn't notice earlier is that minimizing the firefox window completely eliminates the cpu overload. When I restore the firefox window, the cpu overload resumes exactly as before. I hope this may give you some clue about the cause of the problem. Again, I've looked closely at my amd64 builds of firefox and nouveau-related packages and there is no sign of this cpu overload problem. Just on i686. I'd be more than happy to build profiling versions of X/nouveau if such versions exist, but I'll need some hints to get started. Many thanks. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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
Re: [Nouveau] GeForce FX5200 dual DVI Samsung 204b
Grzesiek Sójka p...@pfu.pl writes: On 09/30/10 18:05, Francisco Jerez wrote: Does the following command help? $ xrandr --output DVI-I-2 --set scaling mode None Yes! Now I have: xrandr --output DVI-I-1 --set scaling mode None xrandr --output DVI-I-2 --set scaling mode None in xinitrc. Both displays work fine when Xserver is running. But after I go back to the console the display #1 switches off and #2 starts to blink again. Is it possible to fix the console?? Do you need to tell the binary driver to do anything special to get it working on those monitors? (e.g. manually specified timings or EDID) Regards. pgpHWYtDixNuB.pgp Description: PGP signature ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau