Re: [Nouveau] [PATCH] fix a wrong use of a logical operator in drmmode_output_dpms()
On 05/21/2015 06:40 AM, Dave Airlie wrote: On 21 May 2015 at 03:26, Samuel Pitoiset samuel.pitoi...@gmail.com wrote: On 05/20/2015 07:13 PM, Ilia Mirkin wrote: This is obviously a bug, but one that has been there for some time. Please figure out what this is guarding, and confirm that the feature continues to work. Sure, but do you have any ideas how to test this part of the DDX ? It's the first time I play with it... It's fine, the code just avoids going into the name checks if the type isn't a enum, it won't break anything actually fixing it. The fix is Reviewed-by: Dave Airlie airl...@redhat.com Okay, thanks Dave. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 89730] NV50: LightDM GTK+ Greeter Background - inconsistent display
https://bugs.freedesktop.org/show_bug.cgi?id=89730 --- Comment #19 from andrew p. pan.pav@gmail.com --- Hi, it's me again. I'm not familiar with all this nouveau stuff, so can you tell what is the current status of the bug? I received bug reports that look very similar to this. Is there any fix or maybe workaround? https://bugs.launchpad.net/ubuntu/+source/lightdm-gtk-greeter/+bug/1459079 -- 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 89730] NV50: LightDM GTK+ Greeter Background - inconsistent display
https://bugs.freedesktop.org/show_bug.cgi?id=89730 --- Comment #20 from Ilia Mirkin imir...@alum.mit.edu --- (In reply to andrew p. from comment #19) Hi, it's me again. I'm not familiar with all this nouveau stuff, so can you tell what is the current status of the bug? I received bug reports that look very similar to this. Is there any fix or maybe workaround? https://bugs.launchpad.net/ubuntu/+source/lightdm-gtk-greeter/+bug/1459079 The status is that it doesn't work :) I've been looking at the overall logic in nouveau's EXA implementation, and it looks extremely dodgy wrt CPU access -- I think that PrepareAccess should do an unconditional PUSH_KICK(push) before the nouveau_bo_wait. That'd be good to test out. -- 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 89730] NV50: LightDM GTK+ Greeter Background - inconsistent display
https://bugs.freedesktop.org/show_bug.cgi?id=89730 --- Comment #21 from Ilia Mirkin imir...@alum.mit.edu --- Created attachment 116090 -- https://bugs.freedesktop.org/attachment.cgi?id=116090action=edit kick pushbuf before mapping bo This is the patch I had in mind... totally untested, but seems like it could be the right thing to do. -- 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] [RFC PATCH 00/11] Implement ARB_cull_distance
On 27.05.2015 18:28, Marek Olšák wrote: Another thing to consider is linking shaders that occur before the rasterizer (e.g. any two shaders from VS-TCS-TES-GS). The maximum number of written distances is still 8, but what happens if VS writes 1x clip and 7x cull and GS reads 8x clip and no cull? i think this should be rejected anyway (in the glsl?!), constraining vs output to be the same as gs input where the last definition is the valid one In this case it's basically a generic varying. How is linking separate shaders supposed to work with one combined clip-or-cull array? It doesn't seem to be possible. Marek On Mon, May 25, 2015 at 5:07 PM, Ilia Mirkin imir...@alum.mit.edu wrote: On Mon, May 25, 2015 at 9:40 AM, Tobias Klausmann tobias.johannes.klausm...@mni.thm.de wrote: On 25.05.2015 07:17, Dave Airlie wrote: On 25 May 2015 at 08:11, Marek Olšák mar...@gmail.com wrote: It's the same on Radeon. There are 2x ClipOrCullDistance output vectors and a mask saying it should clip or cull or do nothing. Marek My thinking was gallium should have a single semantic and a mask in the shader definition maybe. though it doesn't solve the does nvidia do the right thing with cull[0] and clip[0], and what is the right thing. Dave. I'm still convinced that both clip[0] and cull[0] should be possible. Plus i have written a shader_test for this a while ago which you pushed to piglit (fs-cull-and-clip-distance-different.shader_test). If i remember right nvidia passed that test just fine. Ah btw, if we follow Brian Paul, overlapping indexes are fine! (and it is way more intuitive to use for a shader developer) My take (and note that I last read the extension many months ago) is that you're supposed to figure out the max gl_ClipDistance[] written, and then write all your cull distances above that. So if you, e.g., have something like gl_ClipDistance[5] = 1; gl_CullDistance[0] = 1; Then it would decide that there are 6 clip distances (or if there's an explicit out float gl_ClipDistance[n], then use that), and 1 cull distance. In the TGSI, I'm thinking this might look approximately like PROPERTY CULL_MASK (16) DCL OUT[0], CLIPDIST[0] DCL OUT[1], CLIPDIST[1] MOV OUT[1].y, 1 (clip distance[5]) MOV OUT[1].z, 1 (cull distance[0]) Then basically you'd have (rast-clip_enable shader-actual_clip_writes_mask) | cull_mask = the enabled distances cull_mask = cull mask This would work *very* well for nouveau, not sure how suitable it is for other hardware. Cheers, -ilia ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 90435] [NV46] moving 3D objects drawn static
https://bugs.freedesktop.org/show_bug.cgi?id=90435 --- Comment #13 from Hans de Goede jwrdego...@fedoraproject.org --- (In reply to Ilya from comment #12) (In reply to Hans de Goede from comment #11) Hi all, I've been looking into this toay, it seems that with the latest xf86-video-nouveau + latest mesa (both git master) I can reproduce the problem and work around it by starting glxgears like this: vblank_mode=0 glxgears I need this workaround on both mesa-10.0 and mesa-git-master, so it seems that whatever problem Ilya was original seeing has been fixed in mesa-git-master. Ilya can you please try mesa-git-master and if that does not work (the vblank issue may be specific to my card), try it with: vblank_mode=0 glxgears ? I have not already tested git-version, but the mesa 10.5.5 from Arch the vblank_mode=0 works good for me. glxgears, lugaru, sauerbraten work fine (slow, but, it wokrs). Great, thanks for testing, then it seems you've the same issue. I'll try to investigate this further Friday (tomorrow I've some other items I need to look into). -- 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 90682] [NVE6] failed to idle channel 0xcccc0001 + crash
https://bugs.freedesktop.org/show_bug.cgi?id=90682 --- Comment #2 from Thomas Stewart tho...@stewarts.org.uk --- I do mention DP-MST! I have a ThinkPad Ultra Dock 40A2: http://shop.lenovo.com/us/en/itemdetails/40A20090US/460/6D501EE899104FF9A362D739642CFC27 http://support.lenovo.com/us/en/documents/pd029622 It's got a variety of connectors: VGA, DVI, 2xDP, HDMI. It has a standard and advanced mode that is selectable from the BIOS. I have read that in standard mode only one port is usable but in advanced any ports are. I have mine set to standard. I drive a pair of 2880x1620 displays with a DVI and a DP from the dock. I think the laptop and the dock use MST in order to use more than one display. Before using Linux 4.0 I had to drive one monitor with the dock and one with the VGA connector on the laptop itself. I don't know if nouveau is used for anything, 2880x1620 is mentioned next to intel and nouveau lines in the Xorg.0.log. In the past I did blacklist nouveau.ko once to diagnose the crashing and found that the crashing stopped but I could only get outout on the laptop display. So it seems to be involved somewhere. How does one find out which screen is driven by which card, etc? Thanks for the info regarding runpm, I have removed that option and am running with nouveau.noaccel=1 now. It seems to be stable as it's up about 40 min so far. I have not used any reverse-prime stuff. $ xrandr Screen 0: minimum 8 x 8, current 3840 x 1200, maximum 32767 x 32767 eDP2 connected (normal left inverted right x axis y axis) 2880x1620 59.96 + 50.00 2048x1536 60.00 1920x1440 60.00 1856x1392 60.01 1792x1344 60.01 1920x1200 59.95 1920x1080 59.93 1600x1200 60.00 1680x1050 59.9559.88 1600x1024 60.17 1400x1050 59.98 1280x1024 60.02 1440x900 59.89 1280x960 60.00 1360x768 59.8059.96 1152x864 60.00 1024x768 60.00 800x600 60.3256.25 640x480 59.94 DP1 disconnected (normal left inverted right x axis y axis) DP2 disconnected (normal left inverted right x axis y axis) DP2-1 connected primary 1920x1200+0+0 (normal left inverted right x axis y axis) 518mm x 324mm 1920x1200 59.95*+ 1920x1080 59.9960.0050.0050.0050.0059.94 1600x1200 60.00 1680x1050 59.95 1280x1024 75.0272.0560.02 1440x900 74.9859.89 1280x720 60.0050.0059.94 1024x768 75.0870.0760.00 800x600 72.1975.0060.32 720x576 50.00 720x480 60.0059.94 640x480 75.0072.8166.0360.0059.94 720x400 70.08 DP2-2 connected 1920x1200+1920+0 (normal left inverted right x axis y axis) 518mm x 324mm 1920x1200 59.95*+ 1920x1080 59.99 1600x1200 60.00 1680x1050 59.88 1280x1024 75.0272.0560.02 1440x900 74.9859.90 1024x768 75.0870.0760.00 800x600 72.1975.0060.32 640x480 75.0072.8166.0360.00 720x400 70.08 DP2-3 disconnected (normal left inverted right x axis y axis) HDMI1 disconnected (normal left inverted right x axis y axis) HDMI2 disconnected (normal left inverted right x axis y axis) VGA1 disconnected (normal left inverted right x axis y axis) VIRTUAL1 disconnected (normal left inverted right x axis y axis) $ $ xrandr --listproviders Providers: number : 2 Provider 0: id: 0x73 cap: 0xb, Source Output, Sink Output, Sink Offload crtcs: 4 outputs: 10 associated providers: 0 name:Intel Provider 1: id: 0x45 cap: 0x7, Source Output, Sink Output, Source Offload crtcs: 4 outputs: 2 associated providers: 0 name:nouveau $ -- 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 90682] [NVE6] failed to idle channel 0xcccc0001 + crash
https://bugs.freedesktop.org/show_bug.cgi?id=90682 --- Comment #5 from Ilia Mirkin imir...@alum.mit.edu --- All of those screens are attached to intel. I can't think of a reason why you would have lost your DP screens. However it seems like your eDP panel is actively attached to *both* the intel *and* the nvidia adapters. Yeah, *that*'ll work great. Ugh. There also appears to be a DVI-D output, which may or may not be real. I wonder if that's the cause of the trouble. It seems like intel is allocating its outputs second, so the first eDP screen goes to nouveau. But presumably nouveau is card1 while intel is card0. Double-check with grep . /sys/class/drm/card*-*/status I bet that there's a eDP-1 and eDP-2, and that eDP-2 is on the card that all the other useful ones are on. In that case, try booting with video=eDP-1:d -- 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 90567] Display freeze when starting League of Legends (Wine)
https://bugs.freedesktop.org/show_bug.cgi?id=90567 --- Comment #22 from Samuel Pitoiset samuel.pitoi...@gmail.com --- What version of apitrace do you use? If you use the archlinux package, you should perhaps try to build your own apitrace from the repo. -- 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 90435] [NV46] moving 3D objects drawn static
https://bugs.freedesktop.org/show_bug.cgi?id=90435 --- Comment #12 from Ilya dikiy_ev...@web.de --- (In reply to Hans de Goede from comment #11) Hi all, I've been looking into this toay, it seems that with the latest xf86-video-nouveau + latest mesa (both git master) I can reproduce the problem and work around it by starting glxgears like this: vblank_mode=0 glxgears I need this workaround on both mesa-10.0 and mesa-git-master, so it seems that whatever problem Ilya was original seeing has been fixed in mesa-git-master. Ilya can you please try mesa-git-master and if that does not work (the vblank issue may be specific to my card), try it with: vblank_mode=0 glxgears ? I have not already tested git-version, but the mesa 10.5.5 from Arch the vblank_mode=0 works good for me. glxgears, lugaru, sauerbraten work fine (slow, but, it wokrs). -- 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 90682] [NVE6] failed to idle channel 0xcccc0001 + crash
https://bugs.freedesktop.org/show_bug.cgi?id=90682 --- Comment #3 from Thomas Stewart tho...@stewarts.org.uk --- Created attachment 116086 -- https://bugs.freedesktop.org/attachment.cgi?id=116086action=edit Xorg.0.log with nouveau.noaccel=1 -- 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] [RFC PATCH 00/11] Implement ARB_cull_distance
Another thing to consider is linking shaders that occur before the rasterizer (e.g. any two shaders from VS-TCS-TES-GS). The maximum number of written distances is still 8, but what happens if VS writes 1x clip and 7x cull and GS reads 8x clip and no cull? In this case it's basically a generic varying. How is linking separate shaders supposed to work with one combined clip-or-cull array? It doesn't seem to be possible. Marek On Mon, May 25, 2015 at 5:07 PM, Ilia Mirkin imir...@alum.mit.edu wrote: On Mon, May 25, 2015 at 9:40 AM, Tobias Klausmann tobias.johannes.klausm...@mni.thm.de wrote: On 25.05.2015 07:17, Dave Airlie wrote: On 25 May 2015 at 08:11, Marek Olšák mar...@gmail.com wrote: It's the same on Radeon. There are 2x ClipOrCullDistance output vectors and a mask saying it should clip or cull or do nothing. Marek My thinking was gallium should have a single semantic and a mask in the shader definition maybe. though it doesn't solve the does nvidia do the right thing with cull[0] and clip[0], and what is the right thing. Dave. I'm still convinced that both clip[0] and cull[0] should be possible. Plus i have written a shader_test for this a while ago which you pushed to piglit (fs-cull-and-clip-distance-different.shader_test). If i remember right nvidia passed that test just fine. My take (and note that I last read the extension many months ago) is that you're supposed to figure out the max gl_ClipDistance[] written, and then write all your cull distances above that. So if you, e.g., have something like gl_ClipDistance[5] = 1; gl_CullDistance[0] = 1; Then it would decide that there are 6 clip distances (or if there's an explicit out float gl_ClipDistance[n], then use that), and 1 cull distance. In the TGSI, I'm thinking this might look approximately like PROPERTY CULL_MASK (16) DCL OUT[0], CLIPDIST[0] DCL OUT[1], CLIPDIST[1] MOV OUT[1].y, 1 (clip distance[5]) MOV OUT[1].z, 1 (cull distance[0]) Then basically you'd have (rast-clip_enable shader-actual_clip_writes_mask) | cull_mask = the enabled distances cull_mask = cull mask This would work *very* well for nouveau, not sure how suitable it is for other hardware. Cheers, -ilia ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 90682] [NVE6] failed to idle channel 0xcccc0001 + crash
https://bugs.freedesktop.org/show_bug.cgi?id=90682 --- Comment #4 from Thomas Stewart tho...@stewarts.org.uk --- Apologies, I copy and pasted the wrong resolutions. The external monitors are 1920x1200. -- 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 90682] failed to idle channel 0xcccc0001 then crash
https://bugs.freedesktop.org/show_bug.cgi?id=90682 --- Comment #1 from Ilia Mirkin imir...@alum.mit.edu --- I think that some things are being confused here... you mention multi-stream, presumably in reference to DP-MST, but that doesn't work on nouveau, only intel and radeon. Are you actually using nouveau for anything? Can you attach an xorg log and xrandr output, that should make things a bit clearer. runpm is a very crude form of power management -- it'll turn the GPU off when the driver decides it hasn't been used for ~5s or so (maybe 10? I forget). It can do this using ACPI calls. It will then wake the GPU back up when it wants to use something. Now you have a Lenovo + GK106 combo, which is well known to have lots of trouble bringing up acceleration. In fact, your logs show [4.472623] nouveau E[ PGR][:01:00.0] grctx template channel unload timeout which means that PGRAPH doesn't come up. You could save nouveau some trouble and just use nouveau.noaccel=1. You should still be able to use reverse-prime in this case. Now, none of that has to do with you seeing the crash, just trying to help you achieve a working system. We shouldn't be crashing even when PGRAPH fails to come up. [ 52.772499] nouveau E[ DRM] failed to idle channel 0x [DRM] [ 52.788584] pci_pm_runtime_suspend(): nouveau_pmops_runtime_suspend+0x0/0xf0 [nouveau] returns -16 OK, so it tries to suspend but it can't shut down the main DRM channel. Because PGRAPH is dead to begin with. Although it begs the question of why it even tries to idle the channel, that means there's an active fence on it. I'm guessing that the remaining messages are due to improper cleanup of a failed runtime suspend. If the above is in the vicinity of correct, nouveau.noaccel=1 should fix it, I think. -- 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 90682] New: failed to idle channel 0xcccc0001 then crash
https://bugs.freedesktop.org/show_bug.cgi?id=90682 Bug ID: 90682 Summary: failed to idle channel 0x0001 then crash Product: xorg Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Driver/nouveau Assignee: nouveau@lists.freedesktop.org Reporter: tho...@stewarts.org.uk QA Contact: xorg-t...@lists.x.org Created attachment 116084 -- https://bugs.freedesktop.org/attachment.cgi?id=116084action=edit dmesg captured with kdump Hi, My Lenovo W540 started crashing when I upgraded from Linux 3.14 to 3.16 in Sept 2014. I continued to use 3.14 and I did nothing till last week when I tried Linux 4.0 (from sid) which kept crashing soon after logging in to GNOME 3. I EFI boot to grub and use GRUB_GFXPAYLOAD_LINUX=keep. Then use KMS and Plymouth till GDM, X.Org and GNOME3. When it crashed the mouse and keyboard no longer did anything (ie Ctrl-Alt-F1 did not work) and the laptop appeared to drop off the network. When I boot with Linux 4.0 and login to GNOME 3, it would crash within minutes, but sometimes an hour. I manually compiled 3.15, 3.16, 3.17, 3.18, 3.19 and 4.0 which all had various issues: the external monitor resolution was broken on 3.15, 3.16 seemed ok, but 3.17, 3.18, 3.19 and 4.0 all seemed to crash soon after boot. I used kdump to capture a dump and dmesg and there was a message about nouveau: [ 76.792370] nouveau E[ DRM] failed to idle channel 0x0001 [DRM] Then 60 microseconds later a BUG: [ 76.792430] BUG: unable to handle kernel paging request at 8805660b7ffc [ 76.792455] IP: [a0406bf3] evo_wait+0x53/0x120 [nouveau] After a little googling I found out about the nouveau.runpm=0 parameter. Once I added this parameter and rebooted my laptop has worked fine with Linux 4.0. However I have not tried that parameter in any previous kernels so am unsure which release this workaround started working. I'm now happy that I have a working system with working lcd screen brightness controls and multi-stream transport monitors that work. However I don't want to kill the laptops battery by permanently disabling the power management. I could try bisecting, but with so many revisions I'm not sure what to mark good and bad or if I should use runpm at all. Anyway here are some Debian package versions and info: linux-image-4.0.0-1-amd64 4.0.2-1 libdrm-nouveau2 2.4.60-3 libgl1-mesa-glx 10.5.5-1 xserver-xorg-video-nouveau 1:1.0.11-1+b1 $ lspci | grep -i VGA 00:02.0 VGA compatible controller: Intel Corporation 4th Gen Core Processor Integrated Graphics Controller (rev 06) 01:00.0 VGA compatible controller: NVIDIA Corporation GK106GLM [Quadro K2100M] (rev a1) $ Kind Regards -- Tom -- 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 90682] [NVE6] failed to idle channel 0xcccc0001 + crash
https://bugs.freedesktop.org/show_bug.cgi?id=90682 Tobias Klausmann tobias.klausm...@mni.thm.de changed: What|Removed |Added Summary|failed to idle channel |[NVE6] failed to idle |0x0001 then crash |channel 0x0001 + 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 90567] Display freeze when starting League of Legends (Wine)
https://bugs.freedesktop.org/show_bug.cgi?id=90567 --- Comment #21 from Detlev Casanova detlev.casan...@gmail.com --- I haven't been able to reproduce the issue with a trace, I tried multiple ones. I realized that when retracing, with verbose output, I get this in the end: 451252 @0 glEnable(cap = GL_BLEND) // incomplete 453956 @1 glFenceSync(condition = GL_SYNC_GPU_COMMANDS_COMPLETE, flags = 0) // incomplete apitrace: warning: caught signal 11 453956: error: caught an unhandled exception glretrace+0x2a637c /usr/lib/libpthread.so.0+0x1065f glretrace+0x217db2 glretrace+0xf363 glretrace+0xb2d5 glretrace+0xb8eb /usr/lib/libpthread.so.0+0x7353 /usr/lib/libc.so.6: clone+0x6c ? apitrace: info: taking default action for signal 11 Erreur de segmentation (core dumped) The last 2 calls seem incomplete (not completely traced by apitrace ?) and then, glretrace crashes. Is there a way to end apitrace32 to properly generate the end of the trace ? -- 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 90682] [NVE6] failed to idle channel 0xcccc0001 + crash
https://bugs.freedesktop.org/show_bug.cgi?id=90682 --- Comment #7 from Thomas Stewart tho...@stewarts.org.uk --- Created attachment 116087 -- https://bugs.freedesktop.org/attachment.cgi?id=116087action=edit dmesg captured with kdump with video=eDP-1:d -- 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 90682] [NVE6] failed to idle channel 0xcccc0001 + crash
https://bugs.freedesktop.org/show_bug.cgi?id=90682 --- Comment #9 from Thomas Stewart tho...@stewarts.org.uk --- Created attachment 116089 -- https://bugs.freedesktop.org/attachment.cgi?id=116089action=edit Xorg.0.log with nouveau.noaccel=1 video=eDP-1:d -- 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 90682] [NVE6] failed to idle channel 0xcccc0001 + crash
https://bugs.freedesktop.org/show_bug.cgi?id=90682 --- Comment #6 from Thomas Stewart tho...@stewarts.org.uk --- Here is the status: $ grep . /sys/class/drm/card*-*/status /sys/class/drm/card0-DVI-D-1/status:disconnected /sys/class/drm/card0-eDP-1/status:disconnected /sys/class/drm/card1-DP-1/status:disconnected /sys/class/drm/card1-DP-2/status:disconnected /sys/class/drm/card1-DP-3/status:connected /sys/class/drm/card1-DP-4/status:connected /sys/class/drm/card1-DP-5/status:disconnected /sys/class/drm/card1-eDP-2/status:connected /sys/class/drm/card1-HDMI-A-1/status:disconnected /sys/class/drm/card1-HDMI-A-2/status:disconnected /sys/class/drm/card1-VGA-1/status:disconnected $ I'm not sure about the DVI-D, I do have a thunderbolt socket on the laptop that I have never used. I'm not sure if the card order has always been the same, but it looks like card0 is nouveau and card1 is intel: $ ls -l /sys/class/drm/card?/device/driver lrwxrwxrwx 1 root root 0 May 27 17:36 /sys/class/drm/card0/device/driver - ../../../../bus/pci/drivers/nouveau lrwxrwxrwx 1 root root 0 May 27 17:35 /sys/class/drm/card1/device/driver - ../../../bus/pci/drivers/i915 $ I rebooted without nouveau.noaccel=1 and with video=eDP-1:d but it crashed again in nv50_display_init(). I then rebooted with nouveau.noaccel=1 video=eDP-1:d and it seems stable but I'm not sure that has actually done anything as dmesg and Xorg.0.log seem very similar. -- 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 90682] [NVE6] failed to idle channel 0xcccc0001 + crash
https://bugs.freedesktop.org/show_bug.cgi?id=90682 --- Comment #8 from Thomas Stewart tho...@stewarts.org.uk --- Created attachment 116088 -- https://bugs.freedesktop.org/attachment.cgi?id=116088action=edit dmesg with nouveau.noaccel=1 video=eDP-1:d -- 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 90567] Display freeze when starting League of Legends (Wine)
https://bugs.freedesktop.org/show_bug.cgi?id=90567 --- Comment #23 from Detlev Casanova detlev.casan...@gmail.com --- Archlinux ships apitrace version 6.1. With the latest git version, it doesn't seem to segfault but the kernel errors are not reproducible... I don't know what else I can do :/ -- 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 90567] Display freeze when starting League of Legends (Wine)
https://bugs.freedesktop.org/show_bug.cgi?id=90567 --- Comment #24 from Ilia Mirkin imir...@alum.mit.edu --- Quick update. I didn't get to this last night, and won't be able to look at it until mid to late June. (Doesn't mean someone else can't look at it though.) -- 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 89730] NV50: LightDM GTK+ Greeter Background - inconsistent display
https://bugs.freedesktop.org/show_bug.cgi?id=89730 --- Comment #22 from Ilia Mirkin imir...@alum.mit.edu --- (In reply to Ilia Mirkin from comment #21) Created attachment 116090 [details] [review] kick pushbuf before mapping bo This is the patch I had in mind... totally untested, but seems like it could be the right thing to do. Ben tells me that nouveau_bo_wait (called by nouveau_bo_map) ends up doing this anyways. Oh well. -- 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] [PATCH 5/8] acpi: Check returned object type by Optimus _DSM locally
On 26 May 2015 at 18:26, Pierre Moreau pierre.mor...@free.fr wrote:
On 26 May 2015, at 07:17, Ilia Mirkin imir...@alum.mit.edu wrote:
On Tue, May 26, 2015 at 1:10 AM, Pierre Moreau pierre.mor...@free.fr wrote:
On 26 May 2015, at 00:39, Ilia Mirkin imir...@alum.mit.edu wrote:
On Mon, May 25, 2015 at 6:22 PM, Pierre Moreau pierre.mor...@free.fr
wrote:
Most _DSM will return an integer val
ue of 0x8002 when given an unknown
UUID, revision ID or function ID. Checking locally allows us to
differentiate
that case from other ACPI errors, and to not report a failed to evaluate
_DSM
if 0x8002 is returned which was confusing.
Signed-off-by: Pierre Moreau pierre.mor...@free.fr
---
drm/nouveau/nouveau_acpi.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/drm/nouveau/nouveau_acpi.c b/drm/nouveau/nouveau_acpi.c
index 073f7d7..7aeaf7d 100644
--- a/drm/nouveau/nouveau_acpi.c
+++ b/drm/nouveau/nouveau_acpi.c
@@ -88,12 +88,12 @@ static int nouveau_evaluate_optimus_dsm(acpi_handle
handle, int func, int arg, u
for (i = 0; i 4; i++)
args_buff[i] = (arg i * 8) 0xFF;
- obj = acpi_evaluate_dsm_typed(handle, nouveau_op_dsm_muid,
nouveau_op_dsm_rid,
- func, argv4, ACPI_TYPE_BUFFER);
+ obj = acpi_evaluate_dsm(handle, nouveau_op_dsm_muid,
nouveau_op_dsm_rid,
+ func, argv4);
if (!obj) {
acpi_handle_info(handle, failed to evaluate _DSM\n);
return AE_ERROR;
- } else {
+ } else if (obj-type == ACPI_TYPE_BUFFER) {
if (!result obj-buffer.length == 4) {
*result = obj-buffer.pointer[0];
*result |= (obj-buffer.pointer[1] 8);
@@ -101,6 +101,15 @@ static int nouveau_evaluate_optimus_dsm(acpi_handle
handle, int func, int arg, u
*result |= (obj-buffer.pointer[3] 24);
}
ACPI_FREE(obj);
+ } else if (obj-type == ACPI_TYPE_INTEGER
+ obj-integer.value == 0x8002) {
+ acpi_handle_debug(handle, failed to query Optimus
_DSM\n);
+ ACPI_FREE(obj);
+ return -ENODEV;
should this be AE_ERROR?
I would say no, because ACPI was parsed correctly, just that we didn't it
give the correct arguments, or rather, the _DSM we tested isn't an Optimus
one, but it could a mux or gmux. And I used ENODEV as it is the value
returned by nouveau_evaluate_mux_dsm in the same context.
Hm ok. It just seemed odd to be returning AE_* in one context, and
-ENODEV in another context -- they're different types of errors.
However if the caller handles it, I guess it's OK... I haven't looked
at the API in depth.
The caller doesn’t care about the returned error and just check wether
it’s non-zero (and sometimes it doesn’t even check).
That's no reason to make it inconsistent, you should probably return
-EINVAL for the AE_ERROR case.
Dave.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 2/8] acpi: Add evaluate to functons evaluating _DSM
On 26 May 2015 at 18:01, Samuel Pitoiset samuel.pitoi...@gmail.com wrote: s/functons/functions in the commit message. On 05/26/2015 12:22 AM, Pierre Moreau wrote: This makes it clearer when reading the function name, as well as following the names of the related ACPI function. Apart from Samuel's suggested fix, Reviewed-by: Dave Airlie airl...@redhat.com ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 1/8] acpi: Rename v1 DSM to mux to avoid ambiguity
On 26 May 2015 at 08:22, Pierre Moreau pierre.mor...@free.fr wrote: This is especially true when variables or functions are just called dsm without precising the v1. Signed-off-by: Pierre Moreau pierre.mor...@free.fr Seeems reasonable, Reviewed-by: Dave Airlie airl...@redhat.com ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 3/8] acpi: Define static variables for revision ids
On 26 May 2015 at 08:22, Pierre Moreau pierre.mor...@free.fr wrote: Signed-off-by: Pierre Moreau pierre.mor...@free.fr Reviewed-by: Dave Airlie airl...@redhat.com ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [RFC PATCH 00/11] Implement ARB_cull_distance
On Wed, May 27, 2015 at 9:05 PM, Tobias Klausmann tobias.johannes.klausm...@mni.thm.de wrote: On 27.05.2015 18:28, Marek Olšák wrote: Another thing to consider is linking shaders that occur before the rasterizer (e.g. any two shaders from VS-TCS-TES-GS). The maximum number of written distances is still 8, but what happens if VS writes 1x clip and 7x cull and GS reads 8x clip and no cull? i think this should be rejected anyway (in the glsl?!), constraining vs output to be the same as gs input where the last definition is the valid one No, it can't be rejected with separate shader objects. Marek ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [RFC PATCH 00/11] Implement ARB_cull_distance
On Wed, May 27, 2015 at 6:51 PM, Marek Olšák mar...@gmail.com wrote: On Wed, May 27, 2015 at 9:05 PM, Tobias Klausmann tobias.johannes.klausm...@mni.thm.de wrote: On 27.05.2015 18:28, Marek Olšák wrote: Another thing to consider is linking shaders that occur before the rasterizer (e.g. any two shaders from VS-TCS-TES-GS). The maximum number of written distances is still 8, but what happens if VS writes 1x clip and 7x cull and GS reads 8x clip and no cull? i think this should be rejected anyway (in the glsl?!), constraining vs output to be the same as gs input where the last definition is the valid one No, it can't be rejected with separate shader objects. Tangentially, I wonder if it makes sense to have an sso mode for shader runner, either toggleable from the shader config or maybe even on the cmdline. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
