search for: gf110

https://bugs.freedesktop.org/show_bug.cgi?id=92971 Ilia Mirkin <imirkin at alum.mit.edu> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|[GF100] KDE plasma locks |[GF110] KDE plasma locks |randomly due to crash of |randomly due to crash of |nouveau driver |nouveau driver -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. -------------- next part ------...

...eau/commit/?id=4179b15c6e9fcfb253e811e5477debe46c84c395 are the ones that'd apply for your GPU. Don't think they'll have an effect though, but it's something to try (you appear to be comfortable building kernels). It is also worth noting that at some point in the past, people with GF110's (NVC8) have had various issues with nouveau's context switching firmware. We believe we fixed those, but... who knows. You could try using blob pgraph firmware. See http://nouveau.freedesktop.org/wiki/VideoAcceleration/#firmware for how to extract it, and boot with nouveau.config=NvGrUseF...

NVIDIA provided the documentation for mp error 0x10, INVALID_ADDR_SPACE, which apparently happens when trying to use an atomic operation on local or shared memory (instead of global memory). Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- drm/nouveau/nvkm/engine/gr/gf100.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drm/nouveau/nvkm/engine/gr/gf100.c

https://bugs.freedesktop.org/show_bug.cgi?id=92971 --- Comment #4 from Ilia Mirkin <imirkin at alum.mit.edu> --- Nov 14 19:06:12 hpprol2 kernel: nouveau 0000:0a:00.0: fifo: PBDMA0: 80000000 [] ch 30 [007e6ab000 kscreenlocker_g[4257]] subc 6 mthd 2878 data a0c02020 A few things wrong with this picture... first off, nouveau never uses subchannel 6. Method 2878 is: lookup -a c8 -d SUBCHAN --

https://bugs.freedesktop.org/show_bug.cgi?id=92971 --- Comment #6 from Philippe Condé <conde.philippe at skynet.be> --- Hello, I tested with the non Xen kernel vmlinux-4.3.0-1-default. The crash exists also with this kernel here the journalctl output with a crash when loading a page in the browser: The screen was totally corrupted but I succeeded to go the the console CTRL Alt F1 and

https://bugs.freedesktop.org/show_bug.cgi?id=92971 Philippe Condé <conde.philippe at skynet.be> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from Philippe Condé

...ens (2): drm/nouveau: activate dual link TMDS links only when possible drm/nouveau: increase max pixel clock to 225 MHZ for HDMI drivers/gpu/drm/nouveau/nouveau_connector.c | 6 ++++-- drivers/gpu/drm/nouveau/nv50_display.c | 8 ++++---- drivers/gpu/drm/nouveau/nvkm/engine/disp/gf110.c | 2 +- drivers/gpu/drm/nouveau/nvkm/engine/disp/nv50.c | 2 +- 4 files changed, 10 insertions(+), 8 deletions(-) -- 2.1.4

https://bugs.freedesktop.org/show_bug.cgi?id=92971 --- Comment #5 from Philippe Condé <conde.philippe at skynet.be> --- hello, it is kde5 (KF5). With opensuse Tumbleweed we do a global update (snapshot). Difficult to see thereafter if this is due to KDE or the kernel. Three examples from journalctl: the very first error after the boot message: the lock occurred during reactivation of

https://bugs.freedesktop.org/show_bug.cgi?id=92971 --- Comment #8 from Philippe Condé <conde.philippe at skynet.be> --- Hello, I desactivated kscreenlocker which resolve the reactivate problem. But the problem of corrupt screen when starting different programs remains and is worst since the last zypper dup. I found this error still related to nouveau when the two screen got corrupted ov

...or 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 chips, >> > as I understand it. >> >> According to our driver source, GF100, GF104, GF110, GF114, and GF116 >> all have it. [So GF106, GF108, GF117, GF119 don't have it.] We've only >> had problems reported against GF116... and only for some people. > > Hmm, some of our internal documentation is inconsistent about whether it > applies to GF100, but otherwise...

...t;>>>> part of performing the copy. It has a variety of limitations (e.g., >>>>> cannot handle blocklinear format), and was only in a few Fermi chips, >>>>> as I understand it. >>>> >>>> According to our driver source, GF100, GF104, GF110, GF114, and GF116 >>>> all have it. [So GF106, GF108, GF117, GF119 don't have it.] We've only >>>> had problems reported against GF116... and only for some people. >>> >>> Hmm, some of our internal documentation is inconsistent about whether it >...

...liar > 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 chips, > as I understand it. According to our driver source, GF100, GF104, GF110, GF114, and GF116 all have it. [So GF106, GF108, GF117, GF119 don't have it.] We've only had problems reported against GF116... and only for some people. > > It is probably easiest to just ignore it. You can distinguish this > decompress engine from normal copy engine by looking...

--- man/nouveau.man | 9 ++++++++- src/nv_driver.c | 8 ++++++-- 2 files changed, 14 insertions(+), 3 deletions(-) diff --git a/man/nouveau.man b/man/nouveau.man index 07d53c8..4878f24 100644 --- a/man/nouveau.man +++ b/man/nouveau.man @@ -63,7 +63,14 @@ GF100, GF104, GF106, GF108, GF110, GF114, GF116, GF117, GF119 GK104, GK106, GK107, GK110, GK208 .TP 22 .B GeForce GTX 750 -GM107 +GM107, GM108 +.TP 22 +.B GeForce GTX 9XX +GM200, GM204, GM206 +.TP 22 +.B GeForce GTX 10XX +GP102, GP104, GP106, GP107, GP108 + .SH CONFIGURATION DETAILS Please refer to __xconfigfile__(__filemans...

...ession 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 chips, > >> > as I understand it. > >> > >> According to our driver source, GF100, GF104, GF110, GF114, and GF116 > >> all have it. [So GF106, GF108, GF117, GF119 don't have it.] We've only > >> had problems reported against GF116... and only for some people. > > > > Hmm, some of our internal documentation is inconsistent about whether it > > applie...

On Fri, Aug 3, 2018 at 8:19 AM, Karol Herbst <kherbst at redhat.com> wrote: > v2: clean up left over comments > don't overwrite hdmimhz parameter > cap to 297MHz > > Signed-off-by: Karol Herbst <kherbst at redhat.com> > --- > drm/nouveau/dispnv50/disp.c | 5 +++++ > drm/nouveau/nouveau_connector.c | 15 ++++++++++----- >

https://bugs.freedesktop.org/show_bug.cgi?id=75761 --- Comment #16 from Lubosz Sarnecki <lubosz at gmail.com> --- Chipset: GF110 (NVC8) -- You are receiving this mail because: You are the assignee for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/nouveau/attachments/20140410/3e3ea7e7/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=75761 --- Comment #17 from Ilia Mirkin <imirkin at alum.mit.edu> --- (In reply to comment #16) > Chipset: GF110 (NVC8) There are known issues with NVC8 that go away with blob pgraph fw, perhaps worth trying with that. (See bug #54437.) -- You are receiving this mail because: You are the assignee for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.f...

..., NV43, NV44, NV45, C51, MCP61 .TP 22 .B GeForce 7XXX -G70, G71, G72, G73 +G70, G71, G72, G73, MCP67, MCP68, MCP73 +.TP 22 +.B GeForce 8XXX, 9XXX, 2XX, 3XX +G80, G84, G86, G92, G94, G96, G98, G200, GT215, GT216, GT218, MCP77, +MCP79, MCP89 +.TP 22 +.B GeForce 4XX, 5XX +GF100, GF104, GF106, GF108, GF110, GF114, GF116, GF117, GF119 +.TP 22 +.B GeForce 6XX, 7XX +GK104, GK106, GK107, GK110, GK208 +.TP 22 +.B GeForce GTX 750 +GM107 .SH CONFIGURATION DETAILS Please refer to __xconfigfile__(__filemansuffix__) for general configuration @@ -67,6 +80,10 @@ are supported: .BI "Option \*qHWCursor\*...

...: limit dp capabilities as per dcb git bisect bad fc243d7f92d95d961186126efaad36197f133ab1 # bad: [88e98d49a1b3e0f8103cdd4fd80d576ec33133ab] drm/gf100-/gr: split ppc state into its subunits git bisect bad 88e98d49a1b3e0f8103cdd4fd80d576ec33133ab # bad: [e21bfd171a192dfba4a8907f2fcc41acac0f685f] drm/gf110/gr: fixup gpc/tpc initvals lists git bisect bad e21bfd171a192dfba4a8907f2fcc41acac0f685f # bad: [eeb0558e074215656ae11a170059a5f2ce29963f] drm/gf104/gr: rename gf104 (nvc4), it came before gf106 (nvc3) git bisect bad eeb0558e074215656ae11a170059a5f2ce29963f # bad: [6acc09b99d5d8f276a4f9bffc32f0bb0f...

Due to popular demand, I have finally found time to write this up. I had to rush it a little, but hopefully you get the gist. http://www.altechnative.net/2013/11/25/virtualized-gaming-nvidia-cards-part-3-how-to-modify-a-fermi-based-geforce-into-a-quadro-geforce-gts450gtx470gtx480-to-quadro-200050006000/ Any questions, please ask away, and I''ll update the article to expand on those