[Nouveau] [Bug 56340] [Ubuntu 10.04.4 LTS 32-bit] Severe instability of VIA Technologies Apollo MVP3 chipset and NVIDIA RIVA TNT2 M64 graphics
https://bugs.freedesktop.org/show_bug.cgi?id=56340 --- Comment #16 from Robert Hancock hancock...@gmail.com --- It's not really clear that there is a driver issue even though some other models of graphics cards don't have this problem in these motherboards. It's quite possible that there is some issue where the card's AGP bus timing is more marginal, etc. and combined with this motherboard/chipset it causes problems. Given all the known issues with VIA AGP and that the TNT2 M64 boards were really low-end boards even when new, with likely not the greatest components/build quality, it seems a reasonable explanation. -- 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 56340] [Ubuntu 10.04.4 LTS 32-bit] Severe instability of VIA Technologies Apollo MVP3 chipset and NVIDIA RIVA TNT2 M64 graphics
https://bugs.freedesktop.org/show_bug.cgi?id=56340 --- Comment #17 from Ilia Mirkin imir...@alum.mit.edu --- (In reply to comment #15) (In reply to comment #14) Again, since this mainboard is a Socket 7 mainboard, I am not able to run this system on Linux 3.x kernel. For posterity, I'll reply here as well -- that is a complete falsehood. Linux 3.10 should support any 486 or later CPU. -- 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 28152] [NV36] corruption in FVWM window decorations
https://bugs.freedesktop.org/show_bug.cgi?id=28152 --- Comment #10 from Ilia Mirkin imir...@alum.mit.edu --- Naturally I just popped the NV34 out of my system and forgot to test this out. For next time that it goes in... all I have to run is fvwm? Or is it fvmw2? fvwm95? Do I need to set up some sort of theme? Do you have some sort of compositor situation going on? -- 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 66176] nouveau.perflvl kernel parameter doesn't work
https://bugs.freedesktop.org/show_bug.cgi?id=66176 --- Comment #7 from Ilia Mirkin imir...@alum.mit.edu --- Note that a NV40 reclocking fix just went into the nouveau/linux-2.6 tree: http://cgit.freedesktop.org/nouveau/linux-2.6/commit/?id=dde3164f85035787ce7c63b791ce3c565ff3e3ff Can you re-test with this fix in place? -- 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 62870] Steam.sh fails at line 704, possibly relating to mesa stack
https://bugs.freedesktop.org/show_bug.cgi?id=62870 Ilia Mirkin imir...@alum.mit.edu changed: What|Removed |Added Status|NEEDINFO|RESOLVED Resolution|--- |NOTOURBUG --- Comment #2 from Ilia Mirkin imir...@alum.mit.edu --- How did you arrive at this being a nouveau bug? Sounds like a steam issue, or something else. Debug it a little further using the steps that Emil suggested. If it _does_ turn out to be a nouveau bug, feel free to reopen this. -- 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 51579] [NVA8] Xv shows black image on ION chipset
https://bugs.freedesktop.org/show_bug.cgi?id=51579 Ilia Mirkin imir...@alum.mit.edu changed: What|Removed |Added Status|NEEDINFO|NEW Summary|Xv video support is black |[NVA8] Xv shows black image |on NVidia NVa8 Chipset in |on ION chipset |latest git [fixed with | |patch] | -- 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 49786] In xterm, some rectangles are not redrawn when the window is partly covered
https://bugs.freedesktop.org/show_bug.cgi?id=49786 --- Comment #4 from Ilia Mirkin imir...@alum.mit.edu --- Can you confirm that this happens with the latest DDX (1.0.9)? If so, we'll need a bit more information -- please attach both a dmesg + Xorg.0.log for your system. (Even if there are no errors, they contain information that describes your system.) -- 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 61069] [NV17] Crash while displaying large image
https://bugs.freedesktop.org/show_bug.cgi?id=61069 --- Comment #3 from dave.muel...@gmx.ch --- What do you mean by latest kernel? If you mean 3.10, the answer is yes. Is there something in the upcoming 3.11 which may fix this issue? -- 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 51862] Shader optimizer is extremely slow
https://bugs.freedesktop.org/show_bug.cgi?id=51862 Ilia Mirkin imir...@alum.mit.edu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |NOTOURBUG --- Comment #2 from Ilia Mirkin imir...@alum.mit.edu --- Looks like most of the time is being spent in ir_expression/etc -- these are generic mesa glsl facilities. Please retest this with the latest mesa, I suspect that improvements have been made. If you still think it's slow, feel free to file a bug with the core mesa team. I don't see anything nouveau-specific about this issue. Also, please use perf for the measurements, it can see inside the kernel, which may relevant (that 16% chunk inside the kernel seems high). -- 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 61069] [NV17] Crash while displaying large image
https://bugs.freedesktop.org/show_bug.cgi?id=61069 --- Comment #4 from Ilia Mirkin imir...@alum.mit.edu --- I doubt there's anything in 3.11 to fix this, but the fact is that I'm currently running on top of the nouveau/linux-2.6 tree (http://cgit.freedesktop.org/nouveau/linux-2.6/), which is 3.11-rc6 + some more commits. I have a couple of patches applied on top of that, but I don't think any of them would matter for this case. What other differences are there? I'm using 1920x1200, you're on 1600x1200. I did get the pan thing from imagemagick's display command. I assume you would get that too (if it didn't crash)? Do you use a compositor of some sort? I don't. My NV18 has 64M VRAM, reports a 128M GART... how much does your card have? Can you get debug libraries in place so that you get symbol resolution on nouveau_drv.so in the stacktrace printed by X? BTW, if you don't want to constantly kill your regular X session, you can start up a second X session to do your testing in. (Might seem obvious, but it took me a little while before I thought of that.) -- 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 61069] [NV17] Crash while displaying large image
https://bugs.freedesktop.org/show_bug.cgi?id=61069 --- Comment #5 from dave.muel...@gmx.ch --- Perhaps you have to try with a bigger image (e.g. 4096x4096 pixel) to compensate for your larger screen resolution. I didn't played with the compositor so far, just used the standard KDE settings. I don't think that a second X session will do any good, as the system is quite unstable after the crash and needs to be rebooted. My NV17 also has 64MiB VRAM as shown below: nouveau [ DEVICE][:01:00.0] BOOT0 : 0x017200a5 nouveau [ DEVICE][:01:00.0] Chipset: NV17 (NV17) nouveau [ DEVICE][:01:00.0] Family : NV10 nouveau [ VBIOS][:01:00.0] checking PRAMIN for image... nouveau [ VBIOS][:01:00.0] ... appears to be valid nouveau [ VBIOS][:01:00.0] using image from PRAMIN nouveau [ VBIOS][:01:00.0] BMP version 5.15 nouveau [ VBIOS][:01:00.0] version 04.17.00.45.00 nouveau [ PTIMER][:01:00.0] unknown input clock freq nouveau [ PFB][:01:00.0] RAM type: DDR1 nouveau [ PFB][:01:00.0] RAM size: 64 MiB nouveau [ PFB][:01:00.0]ZCOMP: 0 tags nouveau [ DRM] VRAM: 63 MiB nouveau [ DRM] GART: 128 MiB nouveau [ DRM] BMP version 5.21 nouveau [ DRM] DCB version 2.0 nouveau [ DRM] DCB outp 00: 01000100 88b8 nouveau [ DRM] DCB outp 01: 02010111 0003 nouveau [ DRM] DCB outp 02: 02010211 0003 nouveau [ DRM] Merging DCB entries 1 and 2 nouveau [ DRM] Loading NV17 power sequencing microcode nouveau [ DRM] Saving VGA fonts nouveau [ DRM] 1 available performance level(s) nouveau [ DRM] 0: memory 332MHz nouveau [ DRM] c: core 249MHz memory 333MHz nouveau [ DRM] MM: using M2MF for buffer copies nouveau [ DRM] Setting dpms mode 3 on TV encoder (output 1) nouveau [ DRM] allocated 1600x1200 fb: 0x9000, bo f5a0c600 -- 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 31961] [NV4E] [drm:drm_crtc_helper_set_config] *ERROR* failed to set mode on [CRTC:6]
https://bugs.freedesktop.org/show_bug.cgi?id=31961 --- Comment #15 from Salah Coronya salah.coro...@gmail.com --- Yes, it still does (as of 3b56bba6abaa70d629fccdcf8490e087ea3a1ab4 in mouveau-master) it unles the workaround in Comment 12 (set the resolution an mnaully disable the phantom ports on the kernel command line) is applied. There (at least) 2 symptoms - first, the syslog is spammed with [drm:drm_crtc_helper_set_config] *ERROR* failed to set mode on [CRTC:10] message. Second, the framebuffer conole is set with a phyical resolution of 1280x1024 but a virtual resolution of 720x576 - so as a result is only fills part of the screen, and it can't be changed with fbset (ioctl FBIOPUT_VSCREENINFO: Invalid argument) - and attempting to do so generated more syslog spam X11 displays normally, however, (it picks a resolution 1024x768 and fills the screen) - though it still spams the syslog. -- 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 67277] Lockdep splat on kernel 3.10.0
https://bugs.freedesktop.org/show_bug.cgi?id=67277 --- Comment #3 from Salah Coronya salah.coro...@gmail.com --- Created attachment 84371 -- https://bugs.freedesktop.org/attachment.cgi?id=84371action=edit lockep splat 3.11-rc6+ I have the same thing in the current nouveau head ( 3b56bba6abaa70d629fccdcf8490e087ea3a1ab4). Same lock but triggered differently. -- 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 60772] xf86-video-nouveau fails to modprobe nouveau: KMS not enabled
https://bugs.freedesktop.org/show_bug.cgi?id=60772 --- Comment #11 from Honza hkm...@bigfoot.com --- Mirkin: You might've overlooked it, but there IS patch in the message you posted reference to. I don't see what other patch might be needed. Also, the behaviour I'm seeking is behaviour previous versions (like xf86-video-nouveau-0.0.16) had. Versions which already supported KMS. I fail to see why you think it's necessary to change behaviour of xf86-video-nouveau to support less workflows just to force the workflow you prefer. All replies against this patch I saw was on ideological ground, none presented any real reason why it's better this way. But ok. If I'm only one needing this workflow, I can accept the need to patch xf86-video-nouveau myself. Still better than reworking whole setup to workaround your decision. (Note: Problem with modprobing nouveau manually is that I would need to login as root or have other setuid binary for that ... hmmm, ok, maybe sudo would suffice.) -- 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 60772] xf86-video-nouveau fails to modprobe nouveau: KMS not enabled
https://bugs.freedesktop.org/show_bug.cgi?id=60772 --- Comment #12 from Honza hkm...@bigfoot.com --- PS: Oh, and isn't I hate it when things do stuff behind my back argument AGAINST udev? -- 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 49786] In xterm, some rectangles are not redrawn when the window is partly covered
https://bugs.freedesktop.org/show_bug.cgi?id=49786 --- Comment #6 from Vincent Lefevre vincent-...@vinc17.net --- Created attachment 84380 -- https://bugs.freedesktop.org/attachment.cgi?id=84380action=edit Xorg.0.log (2013-08-21) -- 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 49786] In xterm, some rectangles are not redrawn when the window is partly covered
https://bugs.freedesktop.org/show_bug.cgi?id=49786 --- Comment #7 from Vincent Lefevre vincent-...@vinc17.net --- Created attachment 84381 -- https://bugs.freedesktop.org/attachment.cgi?id=84381action=edit Shell script to reproduce the bug (needs xterm and base64) -- 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 49786] In xterm, some rectangles are not redrawn when the window is partly covered
https://bugs.freedesktop.org/show_bug.cgi?id=49786 Vincent Lefevre vincent-...@vinc17.net changed: What|Removed |Added Attachment #84381|0 |1 is obsolete|| --- Comment #8 from Vincent Lefevre vincent-...@vinc17.net --- Created attachment 84383 -- https://bugs.freedesktop.org/attachment.cgi?id=84383action=edit Shell script to reproduce the bug (needs xterm and base64) -- 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 49786] In xterm, some rectangles are not redrawn when the window is partly covered
https://bugs.freedesktop.org/show_bug.cgi?id=49786 --- Comment #9 from Vincent Lefevre vincent-...@vinc17.net --- (In reply to comment #4) Can you confirm that this happens with the latest DDX (1.0.9)? If so, we'll need a bit more information -- please attach both a dmesg + Xorg.0.log for your system. (Even if there are no errors, they contain information that describes your system.) The problem still occurs. I don't know what is the DDX, but Xorg.0.log says: [47.996] (II) Module nouveau: vendor=X.Org Foundation [47.996]compiled for 1.12.4, module version = 1.0.9 [47.996]Module class: X.Org Video Driver [47.996]ABI class: X.Org Video Driver, version 12.1 I've attached both dmesg output and the Xorg.0.log file after rebooting the machine and testing. I've also attached a new shell script to test: it automatically opens the xterm windows at the right place (bitmap fonts may need to be enabled, otherwise I don't know if the bug still occurs). It needs the base64 utility (from the coreutils) to output the data to the first xterm window. Just wait for a few seconds for the second xterm then the text to appear. -- 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 49786] In xterm, some rectangles are not redrawn when the window is partly covered
https://bugs.freedesktop.org/show_bug.cgi?id=49786 Vincent Lefevre vincent-...@vinc17.net changed: What|Removed |Added Attachment #84379|dmesg output (2013-08-21) |dmesg output - DELL description||Latitude E6400 (2013-08-21) -- 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 49786] In xterm, some rectangles are not redrawn when the window is partly covered
https://bugs.freedesktop.org/show_bug.cgi?id=49786 Vincent Lefevre vincent-...@vinc17.net changed: What|Removed |Added Attachment #84380|Xorg.0.log (2013-08-21) |Xorg.0.log - DELL Latitude description||E6400 (2013-08-21) -- 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 49786] In xterm, some rectangles are not redrawn when the window is partly covered
https://bugs.freedesktop.org/show_bug.cgi?id=49786 --- Comment #10 from Vincent Lefevre vincent-...@vinc17.net --- Some other thing: the dmesg and Xorg.0.log I've attached correspond to the DELL Latitude E6400. The bug also occurs on a different machine (not with me here); I'll try to attach information in the next few days. -- 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 60772] xf86-video-nouveau fails to modprobe nouveau: KMS not enabled
https://bugs.freedesktop.org/show_bug.cgi?id=60772 --- Comment #13 from Emil Velikov emil.l.veli...@gmail.com --- To put this in another light (In reply to comment #11) Mirkin: You might've overlooked it, but there IS patch in the message you posted reference to. I don't see what other patch might be needed. No-one is saying there is a need for (other) patch(es) Also, the behaviour I'm seeking is behaviour previous versions (like xf86-video-nouveau-0.0.16) had. Versions which already supported KMS. Yes we made a mistake and forgot to do this when we dropped UMS. Sorry for that, we are not perfect :\ I fail to see why you think it's necessary to change behaviour of xf86-video-nouveau to support less workflows just to force the workflow you prefer. All replies against this patch I saw was on ideological ground, none presented any real reason why it's better this way. Afaics thing will work fine if you use udev/eudev/mdev over linux-hotplug. In the latter of which I cannot see any progress (or changes) over the last few years. Whereas for the ideological ground - I think that the maintainer of the kernel drm subsystem(Dave) would know better. Yes a bit more information would not hurt, but considering the other drivers are doing this I do not see it as a wrong thing/bikeshedding. Btw, I believe he already mentioned that it's racy :) But ok. If I'm only one needing this workflow, I can accept the need to patch xf86-video-nouveau myself. Still better than reworking whole setup to workaround your decision. Whichever works for you :) -- 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 58556] MacBook Pro 5, 1 with nVidia 9400m and 9600m, scrambled screen
https://bugs.freedesktop.org/show_bug.cgi?id=58556 Pierre Moreau pierre.mor...@free.fr changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|DUPLICATE |--- --- Comment #14 from Pierre Moreau pierre.mor...@free.fr --- Hi Ilia, It seems to me bug 27501 is about being unable to boot, which is not the main problem here, but rather having a garbage screen after a successful boot. I'm bisecting it, and it seems it appeared between kernel 3.4 and 3.5-rc7. I'll post the full bisection here as soon as I can. -- 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 49786] In xterm, some rectangles are not redrawn when the window is partly covered
https://bugs.freedesktop.org/show_bug.cgi?id=49786 --- Comment #11 from Ilia Mirkin imir...@alum.mit.edu --- Great repro script! Bug confirmed on my NV96, and disconfirmed on NV18. I see that your card is a NV98, so this is probably a bug in the nv50 exa logic. -- 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 49786] In xterm, some rectangles are not redrawn when the window is partly covered
https://bugs.freedesktop.org/show_bug.cgi?id=49786 --- Comment #12 from Vincent Lefevre vincent-...@vinc17.net --- FYI, the other machine where the bug occurs also has a NV98 chipset. The exact card is the following: NVIDIA Corporation G98 [Quadro NVS 295] (rev a1) according to lspci. The one on the DELL Latitude is: NVIDIA Corporation G98M [Quadro NVS 160M] (rev a1) -- 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 49786] In xterm, some rectangles are not redrawn when the window is partly covered
https://bugs.freedesktop.org/show_bug.cgi?id=49786 --- Comment #13 from Ilia Mirkin imir...@alum.mit.edu --- And as I suspected, if you run a compositor, the issue goes away (e.g. with xcompmgr). -- 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 56474] [NV30 gallium] supertuxkart segfaults on NV46
https://bugs.freedesktop.org/show_bug.cgi?id=56474 Ilia Mirkin imir...@alum.mit.edu changed: What|Removed |Added Summary|3D app segfaults on NV46|[NV30 gallium] supertuxkart ||segfaults on NV46 -- 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 67277] Lockdep splat on kernel 3.10.0
https://bugs.freedesktop.org/show_bug.cgi?id=67277 --- Comment #4 from Ilia Mirkin imir...@alum.mit.edu --- There is a patch available at: http://lists.freedesktop.org/archives/dri-devel/2013-August/043406.html Which should fix the issue. -- 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 64774] nouveau GF108 kernel crash in optimus mode when enabling external display output
https://bugs.freedesktop.org/show_bug.cgi?id=64774 --- Comment #21 from Pasi Kärkkäinen pa...@iki.fi --- Any comments about this issue? The patch (linux-3.9.9-gpu-drm-nouveau-warn-on-node-pages.patch) from comment #9 fixes the reproducible hard kernel crash for me.. should we push this to Linux, or should we dig deeper about why nouveau_vma_getmap() is called with wrong arguments resulting in null pointer crash? -- 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 60007] BUG: nouveau crashes in various ways in 32-bits Fedora 18
https://bugs.freedesktop.org/show_bug.cgi?id=60007 --- Comment #18 from Ilia Mirkin imir...@alum.mit.edu --- @Cornel: Can you check if your NV98 card (that you originally filed the issue about) is fine with the latest kernels? Or does it still require Marcin's patch? If you're having another issue with another card, please file a separate issue for it. -- 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 64774] nouveau GF108 kernel crash in optimus mode when enabling external display output
https://bugs.freedesktop.org/show_bug.cgi?id=64774 --- Comment #22 from Ilia Mirkin imir...@alum.mit.edu --- We should figure out why it's getting stuff that it doesn't expect. I had suggested adding the warn solely to avoid the crash down the line. I guess it's reasonable for the upstream kernel to have that, as if it ever fires, we're going to be in trouble later... I think. Will have to re-check the code. I can post it with my analysis if you like, or you can. Could you retest this with 3.11-rc6 BTW? The whole fb pinning/etc logic was reworked, and your issue may have been fixed by it. -- 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 64774] nouveau GF108 kernel crash in optimus mode when enabling external display output
https://bugs.freedesktop.org/show_bug.cgi?id=64774 --- Comment #23 from Pasi Kärkkäinen pa...@iki.fi --- Feel free to post it with your analysis! You can add my reported-by and tested-by. I'm able to reproduce the crash with Linux 3.8.x, 3.9.x and 3.10.x, so the patch is needed at least on the 3.10.x stable branch to fix the crash there. I'll also test with 3.11-rc. -- 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 68075] nouveau inconsistent changing output connector names in xrandr
https://bugs.freedesktop.org/show_bug.cgi?id=68075 --- Comment #7 from Pasi Kärkkäinen pa...@iki.fi --- Created attachment 84407 -- https://bugs.freedesktop.org/attachment.cgi?id=84407action=edit nouveau debug Xorg logs -- 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 68075] nouveau inconsistent changing output connector names in xrandr
https://bugs.freedesktop.org/show_bug.cgi?id=68075 Pasi Kärkkäinen pa...@iki.fi changed: What|Removed |Added Attachment #84407|text/plain |application/octet-stream mime type|| -- 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 68075] nouveau inconsistent changing output connector names in xrandr
https://bugs.freedesktop.org/show_bug.cgi?id=68075 --- Comment #8 from Pasi Kärkkäinen pa...@iki.fi --- Xorg logs (also with dmesg and xrandr output) attached. Summary about each test-case: 01-dvi-not-connected-at-boot-but-is-connected-later: - DVI monitor is not connected to nouveau at boot time, but I connect the DVI cable later while in Xorg session. - xrandr shows nouveau outputs as DP-1, DP-2 and DP-3. - I am able to successfully enable and disable DVI monitor connected to nouveau adapter. - xrandr shows correct connected/disconnected state for the DVI output. - Graphics on the DVI monitor are corrupted, for example moving xterm around the DVI display leaves trace of the xterm contents behind, but let's not focus on that on this bug :) it kind of works. 02-dvi-connected-at-boot-no-nouveau-outputs-detected-in-xrandr: - DVI cable is connected to nouveau at boot time. - xrandr does *not* show any nouveau outputs, so it's not possible to enable/disable DVI monitor. - DVI monitor shows black/white corrupted pattern, even when it should be all empty/black in this case because it's not in use. - Screenshot of the DVI monitor included in the .tar.gz. 03-dvi-connected-at-boot-nouveau-outputs-detected-as-displayport-in-xrandr: - DVI cable is connected to nouveau at boot time. - xrandr shows nouveau outputs as DisplayPort-0, DisplayPort-1 and DisplayPort-2. - Trying to enable DVI monitor connected to nouveau results in hard kernel crash (but we have the other bug open about the kernel crash issue). -- 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 68402] New: Some elements are only rendered in top-left area
https://bugs.freedesktop.org/show_bug.cgi?id=68402 Priority: medium Bug ID: 68402 Assignee: nouveau@lists.freedesktop.org Summary: Some elements are only rendered in top-left area Severity: normal Classification: Unclassified OS: Linux (All) Reporter: janmlyn...@gmail.com Hardware: All Status: NEW Version: git Component: Drivers/DRI/nouveau Product: Mesa Created attachment 84412 -- https://bugs.freedesktop.org/attachment.cgi?id=84412action=edit dmesg log Ubuntu 13.04 64-bit (affects both x86 and x86_64) Kernel - from nouveau/linux-2.6 repo - HEAD is 3b56bba6abaa70d629fccdcf8490e087ea3a1ab4 X.Org X Server 1.13.4 Mesa version e6013e4bee7ebff6b7bd2f3b95eb16e8949e228c Family: NVC0 Chipset: GF116 (NVCF) (GTX 550 Ti) Some elements are only rendered in top-left area of the window (screenshot to be included). This affects both Portal and Team Fortress 2. I've done a bisection and this is the result: 2149ce41ed6b10f7bff65d7b3f23fd03b89753e3 is the first bad commit commit 2149ce41ed6b10f7bff65d7b3f23fd03b89753e3 Author: Christoph Bumiller e0425...@student.tuwien.ac.at Date: Sun Sep 30 22:59:34 2012 +0200 nv50,nvc0: fix 3d engine blit for nvc0 :04 04 e0f165f869fed658f574a2719d0e841dda95139e 013265106fe6e2f2dab6b20811566fa5ba1106f3 Msrc There is nothing related to this issue in dmesg, but I'll include it anyway. -- 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 68402] Some elements are only rendered in top-left area
https://bugs.freedesktop.org/show_bug.cgi?id=68402 --- Comment #1 from Ján Mlynek janmlyn...@gmail.com --- Created attachment 84413 -- https://bugs.freedesktop.org/attachment.cgi?id=84413action=edit screenshot -- 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 68402] Some elements are only rendered in top-left area
https://bugs.freedesktop.org/show_bug.cgi?id=68402 --- Comment #2 from Emil Velikov emil.l.veli...@gmail.com --- Thanks for the bisect Ján Bit short on hardware atm, so can you confirm hunk of the commit causes the issue? I'm suspecting the last one, although there is a small chance that it's the second to last. Cheers Emil -- 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 68402] Some elements are only rendered in top-left area
https://bugs.freedesktop.org/show_bug.cgi?id=68402 --- Comment #3 from Ján Mlynek janmlyn...@gmail.com --- It's the last hunk that causes the issue: BEGIN_NVC0(push, NVC0_3D(VIEWPORT_HORIZ(0)), 2); PUSH_DATA (push, nvc0-framebuffer.width 16); PUSH_DATA (push, nvc0-framebuffer.height 16); Removing it solved the issue, so I tried to do the same thing in current(master) code. After removing 2 of these hunks (there is another one in commit 443b247878edd6a67adc073b0c36e2941436b9a0), the bug is not present. I have no idea what I've broken in the process, though. :-) -Ján -- 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] [PATCH] drm/nouveau: avoid null deref on bad arguments to nouveau_vma_getmap
The code expects non-VRAM mem nodes to have a pages list. If that's not set, it will do a null deref down the line. Warn on that condition and return an error. See https://bugs.freedesktop.org/show_bug.cgi?id=64774 Reported-by: Pasi Kärkkäinen pa...@iki.fi Tested-by: Pasi Kärkkäinen pa...@iki.fi Signed-off-by: Ilia Mirkin imir...@alum.mit.edu Cc: sta...@vger.kernel.org # 3.8+ --- I don't exactly understand what's going on, but this is just a straightforward way to avoid a null deref that you see happens in the bug. I haven't figured out the root cause of this, but it's getting well into the I have no idea how TTM works space. However this seems like a bit of defensive programming -- nouveau_vm_map_sg will pass node-pages as a list down, which will be dereferenced by nvc0_vm_map_sg. Perhaps the other arguments should make that dereferencing not happen, but it definitely was happening here, as you can see in the bug. Ben/Maarten, I'll let you judge whether this check is appropriate, since like I hope I was able to convey above, I'm just not really sure :) drivers/gpu/drm/nouveau/nouveau_bo.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c b/drivers/gpu/drm/nouveau/nouveau_bo.c index cdc3282..191145d 100644 --- a/drivers/gpu/drm/nouveau/nouveau_bo.c +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c @@ -963,6 +963,12 @@ nouveau_vma_getmap(struct nouveau_channel *chan, struct nouveau_bo *nvbo, struct nouveau_mem *node = mem-mm_node; int ret; + /* If we ever get here for a non-vram mem node that doesn't +* have pages, we will end up doing a null deref in +* nouveau_vm_map_sg. */ + if (WARN_ON(mem-mem_type != TTM_PL_VRAM !node-pages)) + return -EINVAL; + ret = nouveau_vm_get(nv_client(chan-cli)-vm, mem-num_pages PAGE_SHIFT, node-page_shift, NV_MEM_ACCESS_RW, vma); -- 1.8.1.5 ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 67277] Lockdep splat on kernel 3.10.0
https://bugs.freedesktop.org/show_bug.cgi?id=67277 --- Comment #5 from Emil Velikov emil.l.veli...@gmail.com --- and for prenv50 cards you might also need http://cgit.freedesktop.org/nouveau/linux-2.6/commit/?id=3b56bba6abaa70d629fccdcf8490e087ea3a1ab4 -- 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 67382] [nouveau, nv50] linux 3.9.7-3.10.3: Xorg won't be available
https://bugs.freedesktop.org/show_bug.cgi?id=67382 --- Comment #30 from Anonymous Helper anonym...@dodgeit.com --- As the days went by. I'm wondering what I should do. Or what's the case with this report. Is it kind of a problem, that I need to take care myself? E.g. it cannot be patched/removed/altered, because this stabilisation is needed and would harm other cards? I have no problem with waiting, but the uncertainty is killing me :) Best regards -- 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 67382] [nouveau, nv50] linux 3.9.7-3.10.3: Xorg won't be available
https://bugs.freedesktop.org/show_bug.cgi?id=67382 --- Comment #31 from Emil Velikov emil.l.veli...@gmail.com --- (In reply to comment #30) As the days went by. I'm wondering what I should do. Or what's the case with this report. Is it kind of a problem, that I need to take care myself? E.g. it cannot be patched/removed/altered, because this stabilisation is needed and would harm other cards? Point is I've asked a few people and no-one seems to have such issue like you. So I'm suspecting that it's related to the original NV50. With that said the only person I can think of having such a card to test is the nouveau/kernel maintainer. Which is quite busy, but hopefully will have a moment to test. Side effect of using the new fix is causing a regression on almost all other cards, and/or the need to increase the delay to a silly value (as it was before). -- 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
