[Nouveau] [Bug 89664] Nouveau fails to enter KMS with the Gigabyte G1 Gaming GTX970
https://bugs.freedesktop.org/show_bug.cgi?id=89664 --- Comment #28 from Ben Skeggs --- (In reply to Mikołaj Świątek from comment #27) > (In reply to Ben Skeggs from comment #25) > > (In reply to Mikołaj Świątek from comment #24) > > > (In reply to Ilia Mirkin from comment #23) > > > > Have a look at bug #100676. Is it the same issue? (Please test the > > > > patches > > > > that were provided there.) > > > > > > I don't *think* it's the exact same issue. The screen photo in that report > > > is similar to what I see, though my text output is completely > > > unintelligible, rather than just slightly corrupted. The reason I thought > > > it > > > was this bug was that the log messages about unknown connectors and > > > failing > > > to create encoders are identical with Omar's in my case. > > > > > > In any event, I've built the kernel module from Ben's tree and it didn't > > > change anything at all, same behaviour. > > > > Can I see your kernel log output from that please? Bonus points if you boot > > with "log_buf_len=8M nouveau.debug=trace". > > Tried to do it that way, but it somehow resulted in so much output that I > couldn't even see the boot log with journalctl. I guess the kernel ring > buffer fills up and the beginning gets overwritten before journald can read > it? Not an expert at debugging kernel modules by any stretch, so let me know > if I'm missing something obvious here. > > In the meantime, uploaded a run with nouveau.debug=debug. I can't tell 100% for sure from that, but, there's *strong* evidence there to suggest that yes, you are indeed seeing the bug Ilia mentioned. You can probably work around it in the meantime by plugging one of your displays into another connector, or by trying the tree suggested in the other bug. -- 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] [Bug 101191] [NVC3] Vsync stops working after mode changes in nouveau DDX
https://bugs.freedesktop.org/show_bug.cgi?id=101191 --- Comment #3 from z...@omaera.org --- Created attachment 131515 --> https://bugs.freedesktop.org/attachment.cgi?id=131515&action=edit xorg log -- 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] [Bug 101191] [NVC3] Vsync stops working after mode changes in nouveau DDX
https://bugs.freedesktop.org/show_bug.cgi?id=101191 --- Comment #2 from z...@omaera.org --- Created attachment 131514 --> https://bugs.freedesktop.org/attachment.cgi?id=131514&action=edit Terminal logs of 4 situations -- 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] [Bug 101191] [NVC3] Vsync stops working after mode changes in nouveau DDX
https://bugs.freedesktop.org/show_bug.cgi?id=101191 --- Comment #1 from z...@omaera.org --- Created attachment 131513 --> https://bugs.freedesktop.org/attachment.cgi?id=131513&action=edit dmesg -- 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] [Bug 101191] New: [NVC3] Vsync stops working after mode changes in nouveau DDX
https://bugs.freedesktop.org/show_bug.cgi?id=101191 Bug ID: 101191 Summary: [NVC3] Vsync stops working after mode changes in nouveau DDX Product: xorg Version: 7.7 (2012.06) Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Driver/nouveau Assignee: nouveau@lists.freedesktop.org Reporter: z...@omaera.org QA Contact: xorg-t...@lists.x.org Hello, I've encountered this weird issue where Vsync suddenly stops working after I manipulate modes on the fly in some situations. I could reproduce it in 4 different situations, and I've attached logs respectively: (1) Only 1 monitor connected to DVI. Any mode change (resolution or refresh rate) will trigger the issue. (term_1.txt / xorg_1.txt) (2) 2 monitors connected (DVI+HDMI TV). Turning off the DVI monitor will immediately trigger the issue. (term_2.txt / xorg_2.txt) (3) 2 monitors connected (DVI+HDMI TV). Mode changes in DVI monitor won't trigger the issue anymore. But after turning off the HDMI monitor, mode changes in the DVI one will start triggering the issue again. (term_3.txt / xorg_3.txt) (4) 2 monitors connected (DVI+HDMI TV). Mode changes in HDMI monitor immediately trigger the issue. Note how Vsync is still working in the DVI one, though. (term_4.txt / xorg_4.txt) Needless to say, this will cause issues (for example) in mpv video player, where it'll suffer tearing and complain about inconsistent timing, both in opengl and vdpau modes. Distribution Debian Sid Linux 4.9.25 xorg 7.7 (server 1.19.3) xf86-video-nouveau 1.0.15 libdrm 2.4.74 This only happens with the nouveau DDX driver, as this issue doesn't occur with the modesetting one, therefore I assume it's a nouveau DDX bug (rather than mesa). -- 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
Re: [Nouveau] GTX 1080 Ti (NV132/GP102)
> Another issue is that in Google Chrome I seem have no hardware acceleration > for anything other than "Multiple Raster Threads". See attached. Two things: you are using nomodeset, and hardware acceleration for Pascal cards was only merged in 4.12 (which has not been released yet), as pointed out by Ilia. Pierre ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] GTX 1080 Ti (NV132/GP102)
On Thu, May 25, 2017 at 12:08 PM, Shahar Or wrote: > Thanks for the info. Two issues: > > If I don't set `nomodeset` in the Linux args I get a freeze at boot. Know > anything about that? "nomodeset" is another way of saying "disable all graphics stuff". Since "graphics stuff" is what you're trying to achieve, this isn't a viable workaround. Would have to see the logs to see why you're getting a freeze on boot when nouveau actually tries to load. ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] GTX 1080 Ti (NV132/GP102)
Thanks for the info. Two issues: If I don't set `nomodeset` in the Linux args I get a freeze at boot. Know anything about that? Another issue is that in Google Chrome I seem have no hardware acceleration for anything other than "Multiple Raster Threads". See attached. If my kernel/libs are too old, please just tell me to fluff off. But I am on the development branch of Ubuntu... On Wed, May 24, 2017 at 7:06 PM Ilia Mirkin wrote: > https://nouveau.freedesktop.org/wiki/ > > Linux Kernel 4.8 for modesetting (although there were important fixes > later on, so at least 4.10 is probably good), and Linux Kernel 4.12 > for GPU acceleration (for which you'll also need Mesa 17.1.x). > > Cheers, > > -ilia > > On Wed, May 24, 2017 at 11:21 AM, Shahar Or > wrote: > > "should be supported" sounds promising. Do you know since what version of > > what things it "should be supported", please? > > > > On Wed, May 24, 2017 at 6:04 PM Ilia Mirkin > wrote: > >> > >> GP102 should be supported. Depending on what you're looking for to be > >> supported, your distribution may not be shipping the required versions > >> of various software. > >> > >> On Wed, May 24, 2017 at 5:52 AM, Shahar Or > > >> wrote: > >> > Hey, I am experiencing some issues in Ubuntu 17.10 with this card. > >> > > >> > Before I add any info, perhaps this is not at all supported? I don't > see > >> > this card in the feature matrix: > >> > https://nouveau.freedesktop.org/wiki/FeatureMatrix/ > >> > > >> > > >> > > >> > ___ > >> > Nouveau mailing list > >> > Nouveau@lists.freedesktop.org > >> > https://lists.freedesktop.org/mailman/listinfo/nouveau > >> > > Graphics Feature Status Canvas: Software only, hardware acceleration unavailableFlash: Software only, hardware acceleration unavailableFlash Stage3D: Software only, hardware acceleration unavailableFlash Stage3D Baseline profile: Software only, hardware acceleration unavailableCompositing: Software only, hardware acceleration unavailableMultiple Raster Threads: EnabledNative GpuMemoryBuffers: Software only. Hardware acceleration disabledRasterization: Software only, hardware acceleration unavailableVideo Decode: Software only, hardware acceleration unavailableVideo Encode: Software only, hardware acceleration unavailableVPx Video Decode: Software only, hardware acceleration unavailableWebGL: Hardware accelerated but at reduced performanceWebGL2: Unavailable Driver Bug Workarounds clear_uniforms_before_first_program_usecount_all_in_varyings_packingdecode_encode_srgb_for_generatemipmapdisable_framebuffer_cmaadisable_post_sub_buffers_for_onscreen_surfacesremove_invariant_and_centroid_for_essl3scalarize_vec_and_mat_constructor_args Problems Detected Accelerated video decode is unavailable on Linux: 137247Disabled Features: accelerated_video_decodeOnly enable WebGL for the Mesa Gallium llvmpipe driver: 571899Disabled Features: gpu_rasterization, flash_3d, flash_stage3d_baseline, gpu_compositing, accelerated_2d_canvas, accelerated_video_decode, flash_stage3d, webgl2, accelerated_vpx_decode, panel_fitting, accelerated_video_encodeClear uniforms before first program use on all platforms: 124764, 349137Applied Workarounds: clear_uniforms_before_first_program_useMesa drivers in Linux handle varyings without static use incorrectly: 333885Applied Workarounds: count_all_in_varyings_packingAlways rewrite vec/mat constructors to be consistent: 398694Applied Workarounds: scalarize_vec_and_mat_constructor_argsNVIDIA drivers before 346 lack features in NV_path_rendering and related extensions to implement driver level path rendering.: 344330Limited enabling of Chromium GL_INTEL_framebuffer_CMAA: 535198Applied Workarounds: disable_framebuffer_cmaaDisable partial swaps on Mesa drivers (detected with GL_VERSION): 339493Applied Workarounds: disable_post_sub_buffers_for_onscreen_surfacesDecode and encode before generateMipmap for srgb format textures on os except macosx: 634519Applied Workarounds: decode_encode_srgb_for_generatemipmapMesa driver GL 3.3 requires invariant and centroid to match between shaders: 639760, 641129Applied Workarounds: remove_invariant_and_centroid_for_essl3Disable KHR_blend_equation_advanced until cc shaders are updated: 661715Native GpuMemoryBuffers have been disabled, either via about:flags or command line.Disabled Features: native_gpu_memory_buffers Version Information Data exported 5/25/2017, 7:05:20 PM Chrome version Chrome/58.0.3029.110 Operating system Linux 4.10.0-21-generic
[Nouveau] [Bug 101184] [bisected] Panic on boot with GK106
https://bugs.freedesktop.org/show_bug.cgi?id=101184 --- Comment #1 from S. Gilles --- Created attachment 131504 --> https://bugs.freedesktop.org/attachment.cgi?id=131504&action=edit output of `lspci -nnn -v' -- 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] [Bug 101184] New: [bisected] Panic on boot with GK106
https://bugs.freedesktop.org/show_bug.cgi?id=101184 Bug ID: 101184 Summary: [bisected] Panic on boot with GK106 Product: xorg Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: major Priority: medium Component: Driver/nouveau Assignee: nouveau@lists.freedesktop.org Reporter: sgil...@math.umd.edu QA Contact: xorg-t...@lists.x.org Created attachment 131503 --> https://bugs.freedesktop.org/attachment.cgi?id=131503&action=edit Transcription of kernel panic Since e4311ee51d1e2676001b2d8fcefd92bdd79aad85 "drm/nouveau/therm: remove ineffective workarounds for alarm bugs", my machine with a GTX 650 panics on boot. I will attach lspci output and a transcription of the panic, and I can provide more information or test patches as needed. -- 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] [Bug 89664] Nouveau fails to enter KMS with the Gigabyte G1 Gaming GTX970
https://bugs.freedesktop.org/show_bug.cgi?id=89664 --- Comment #27 from Mikołaj Świątek --- (In reply to Ben Skeggs from comment #25) > (In reply to Mikołaj Świątek from comment #24) > > (In reply to Ilia Mirkin from comment #23) > > > Have a look at bug #100676. Is it the same issue? (Please test the patches > > > that were provided there.) > > > > I don't *think* it's the exact same issue. The screen photo in that report > > is similar to what I see, though my text output is completely > > unintelligible, rather than just slightly corrupted. The reason I thought it > > was this bug was that the log messages about unknown connectors and failing > > to create encoders are identical with Omar's in my case. > > > > In any event, I've built the kernel module from Ben's tree and it didn't > > change anything at all, same behaviour. > > Can I see your kernel log output from that please? Bonus points if you boot > with "log_buf_len=8M nouveau.debug=trace". Tried to do it that way, but it somehow resulted in so much output that I couldn't even see the boot log with journalctl. I guess the kernel ring buffer fills up and the beginning gets overwritten before journald can read it? Not an expert at debugging kernel modules by any stretch, so let me know if I'm missing something obvious here. In the meantime, uploaded a run with nouveau.debug=debug. -- 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] [Bug 89664] Nouveau fails to enter KMS with the Gigabyte G1 Gaming GTX970
https://bugs.freedesktop.org/show_bug.cgi?id=89664 --- Comment #26 from Mikołaj Świątek --- Created attachment 131502 --> https://bugs.freedesktop.org/attachment.cgi?id=131502&action=edit Kernel module built from master, nouveau.debug=debug nouveau.debug=trace resulted in too much spam for journald to handle... -- 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
