Re: [Nouveau] Debugging INVALID_OPCODE / MULTIPLE_WARP_ERRORS ?
Also, where's the exit op? Perhaps what's happening is that you don't
have an exit and it just goes off executing into the ether?
On Tue, Dec 15, 2015 at 12:00 PM, Ilia Mirkin wrote:
> A few things that stand out:
>
> 0: ld u32 %r219 c0[0x+0x0] (0)
>
> wtf is that 0x0 thing doing there? Was it a %rX which got
> constant-folded into 0? That indirectness should have then been
> removed... that said, the final encoding looks fine.
>
> I believe that kepler has this launch descriptor thing too... is that
> being set correctly? Please generate a mmt trace, and we can see if
> anything stands out compared to a blob trace that also does compute.
>
> Cheers,
>
> -ilia
>
> On Tue, Dec 15, 2015 at 9:15 AM, Hans de Goede wrote:
>> Hi all,
>>
>> As part of my compute work I'm trying to get some TGSI compute
>> code to work. The code from mesa/src/gallium/tests/trivial.c
>> works.
>>
>> So now I'm trying to get a "native" tgsi kernel to run via
>> clover, I'm using Francisco's nbody.c example for this:
>>
>> https://fedorapeople.org/~jwrdegoede/nbody.c
>>
>> Which does not work, at first I thought there was an issue
>> with the setup of the input / output buffers, but that seems to
>> work fine, and moreover I finally got the smart idea to look
>> in dmesg, which says:
>>
>> [ 9920.802435] nouveau :01:00.0: gr: TRAP ch 6 [007f7fa000 nbody[31881]]
>> [ 9920.802449] nouveau :01:00.0: gr: GPC0/TPC0/MP trap: global
>> [] warp 10009 [INVALID_OPCODE]
>> [ 9920.802456] nouveau :01:00.0: gr: GPC0/TPC1/MP trap: global 0004
>> [MULTIPLE_WARP_ERRORS] warp 20009 [INVALID_OPCODE]
>>
>> and repeats that for every "step" in the nobody simulation, this is on a
>> gk107 card.
>>
>> So that seems to be the real problem, since the
>> error says "INVALID_OPCODE", I've put the tgsi code from nbody.c
>> through "nouveau_compiler -a e4" and then run "nvdisasm -b SM30"
>> on it, but the output looks ok. There is a 8 byte sequence which does
>> not get decoded every 64 bytes but AFAIK that is the scheduling info,
>> so that should be fine.
>>
>> One thing which does stand out is that this:
>>
>> 0: ld u32 %r219 c0[0x+0x0] (0)
>> 1: ld u32 %r222 c0[0x4] (0)
>> 2: ld u64 { %r225 %r228 } c0[0x8] (0)
>> 3: ld u32 %r234 c0[0x10] (0)
>>
>> Gets translated into (nvdisasm output) :
>>
>> /*0008*/ LDC R4, c[0x0][0x0];
>> /* 0x140003f11c86 */
>> /*0010*/ MOV R2, c[0x0][0x4];
>> /* 0x2800400010009de4 */
>> /*0018*/ LDC.64 R0, c[0x0][0x8];
>> /* 0x140023f01ca6 */
>> /*0020*/ MOV R3, c[0x0][0x10];
>> /* 0x280040004000dde4 */
>>
>> Where I would expect for LDC instructions, could that be the problem ?
>>
>> If that is not the problem, then hints how to debug this further would be
>> greatly appreciated.
>>
>> Regards,
>>
>> Hans
>> ___
>> Nouveau mailing list
>> Nouveau@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/nouveau
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Debugging INVALID_OPCODE / MULTIPLE_WARP_ERRORS ?
A few things that stand out:
0: ld u32 %r219 c0[0x+0x0] (0)
wtf is that 0x0 thing doing there? Was it a %rX which got
constant-folded into 0? That indirectness should have then been
removed... that said, the final encoding looks fine.
I believe that kepler has this launch descriptor thing too... is that
being set correctly? Please generate a mmt trace, and we can see if
anything stands out compared to a blob trace that also does compute.
Cheers,
-ilia
On Tue, Dec 15, 2015 at 9:15 AM, Hans de Goede wrote:
> Hi all,
>
> As part of my compute work I'm trying to get some TGSI compute
> code to work. The code from mesa/src/gallium/tests/trivial.c
> works.
>
> So now I'm trying to get a "native" tgsi kernel to run via
> clover, I'm using Francisco's nbody.c example for this:
>
> https://fedorapeople.org/~jwrdegoede/nbody.c
>
> Which does not work, at first I thought there was an issue
> with the setup of the input / output buffers, but that seems to
> work fine, and moreover I finally got the smart idea to look
> in dmesg, which says:
>
> [ 9920.802435] nouveau :01:00.0: gr: TRAP ch 6 [007f7fa000 nbody[31881]]
> [ 9920.802449] nouveau :01:00.0: gr: GPC0/TPC0/MP trap: global
> [] warp 10009 [INVALID_OPCODE]
> [ 9920.802456] nouveau :01:00.0: gr: GPC0/TPC1/MP trap: global 0004
> [MULTIPLE_WARP_ERRORS] warp 20009 [INVALID_OPCODE]
>
> and repeats that for every "step" in the nobody simulation, this is on a
> gk107 card.
>
> So that seems to be the real problem, since the
> error says "INVALID_OPCODE", I've put the tgsi code from nbody.c
> through "nouveau_compiler -a e4" and then run "nvdisasm -b SM30"
> on it, but the output looks ok. There is a 8 byte sequence which does
> not get decoded every 64 bytes but AFAIK that is the scheduling info,
> so that should be fine.
>
> One thing which does stand out is that this:
>
> 0: ld u32 %r219 c0[0x+0x0] (0)
> 1: ld u32 %r222 c0[0x4] (0)
> 2: ld u64 { %r225 %r228 } c0[0x8] (0)
> 3: ld u32 %r234 c0[0x10] (0)
>
> Gets translated into (nvdisasm output) :
>
> /*0008*/ LDC R4, c[0x0][0x0];
> /* 0x140003f11c86 */
> /*0010*/ MOV R2, c[0x0][0x4];
> /* 0x2800400010009de4 */
> /*0018*/ LDC.64 R0, c[0x0][0x8];
> /* 0x140023f01ca6 */
> /*0020*/ MOV R3, c[0x0][0x10];
> /* 0x280040004000dde4 */
>
> Where I would expect for LDC instructions, could that be the problem ?
>
> If that is not the problem, then hints how to debug this further would be
> greatly appreciated.
>
> Regards,
>
> Hans
> ___
> Nouveau mailing list
> Nouveau@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/nouveau
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH] drm/nouveau: Fix pre-nv50 pageflip events (v4)
On Tue, Dec 15, 2015 at 03:17:21PM +, Emil Velikov wrote: > On 15 December 2015 at 15:01, poma wrote: > > On 15.12.2015 12:21, Emil Velikov wrote: > >> On 15 December 2015 at 11:11, poma wrote: > >> > >>> > >>> Apparently not reached @stable (stable: 4.3.3 2015-12-15), > >>> so here's one more time. > >>> > >> It has reached 4.4-rcX and will get picked by the stable maintainer > >> (Greg?) in due time. Meanwhile you can ask your distro maintainers to > >> apply it locally until we get an official release that includes it. > >> > >> -Emil > >> > > > > It is all but unknown ;) > > https://bugzilla.redhat.com/show_bug.cgi?id=1281368 > > > > Emil, the point is - if it has -not- reached sta...@vger.kernel.org, how > > can it be applied, in the first place. > > > The same way many others do ? I'd imagine there is a tool/script which > parses through the development tree, which would explain why (many?) > people explicitly suppress git from sending an email yet things still > work. There is extra information in the documentation [1] if you're > interested. Yes, this is in the queue, along with 276 other patches that I need to apply as well. The backlog is large this time of year, sorry. greg k-h ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 92307] G98/GM206: WARNING: ... at include/drm/drm_crtc.h:1577 drm_helper_choose_encoder_dpms+0x8a/0x90 [drm_kms_helper]()
https://bugs.freedesktop.org/show_bug.cgi?id=92307 --- Comment #26 from poma --- When engaged, Xfwm4 GL compositor with XPresent VSync $ XFWM4_USE_PRESENT=1 xfwm4 xrandr related problemos(--off/--auto/--rotate) start with this particular commita "enable dri3 support without glamor" http://cgit.freedesktop.org/nouveau/xf86-video-nouveau/commit/?id=241e728 With the former commita, which works OK http://cgit.freedesktop.org/nouveau/xf86-video-nouveau/commit/?id=762b22f while "xrandr-ing", there is no warning in the kernel ring buffer, whatsoever. Still, SEGV catches xfdesktop. Yet with commita 762b22f, while S3 RESUME, warnings are still occurring, very persistent, aye. :) In contrast, when engaged, Xfwm4 GL compositor with default VSync, xrandr related problemos(--off/--auto/--rotate) are "all the way", at least I have tested from xf86-video-nouveau-1.0.3 up to the latest, xf86-video-nouveau-1.0.12. So there is no love there at all. I wonder whether this problemo is comparable to one occurs with the clutter/mutter/gnome-shell https://bugzilla.gnome.org/buglist.cgi?quicksearch=meta_monitor_manager_xrandr_handle_xevent https://bugzilla.redhat.com/buglist.cgi?quicksearch=meta_monitor_manager_xrandr_handle_xevent -- 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 59069] nouveau E[ DRM] fail ttm_validate
https://bugs.freedesktop.org/show_bug.cgi?id=59069 peter swain changed: What|Removed |Added CC||sw...@pobox.com --- Comment #32 from peter swain --- Created attachment 120530 --> https://bugs.freedesktop.org/attachment.cgi?id=120530&action=edit kern.log from 4.2.0-19-generic ubuntu-15.10 with dual-head NV44 Working nicely until woken from overnight screen blanking, then the classic ttm_validate issue. This is with ppa.launchpad.net/graphics-drivers/'s xserver-xorg-video-nouveau amd64 1:1.0.11-1ubuntu3 -- 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] drm/nouveau: Fix pre-nv50 pageflip events (v4)
On 15 December 2015 at 15:01, poma wrote: > On 15.12.2015 12:21, Emil Velikov wrote: >> On 15 December 2015 at 11:11, poma wrote: >> >>> >>> Apparently not reached @stable (stable: 4.3.3 2015-12-15), >>> so here's one more time. >>> >> It has reached 4.4-rcX and will get picked by the stable maintainer >> (Greg?) in due time. Meanwhile you can ask your distro maintainers to >> apply it locally until we get an official release that includes it. >> >> -Emil >> > > It is all but unknown ;) > https://bugzilla.redhat.com/show_bug.cgi?id=1281368 > > Emil, the point is - if it has -not- reached sta...@vger.kernel.org, how can > it be applied, in the first place. > The same way many others do ? I'd imagine there is a tool/script which parses through the development tree, which would explain why (many?) people explicitly suppress git from sending an email yet things still work. There is extra information in the documentation [1] if you're interested. -Emil [1] https://www.kernel.org/doc/Documentation/stable_kernel_rules.txt ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH] drm/nouveau: Fix pre-nv50 pageflip events (v4)
On 15.12.2015 12:21, Emil Velikov wrote: > On 15 December 2015 at 11:11, poma wrote: > >> >> Apparently not reached @stable (stable: 4.3.3 2015-12-15), >> so here's one more time. >> > It has reached 4.4-rcX and will get picked by the stable maintainer > (Greg?) in due time. Meanwhile you can ask your distro maintainers to > apply it locally until we get an official release that includes it. > > -Emil > It is all but unknown ;) https://bugzilla.redhat.com/show_bug.cgi?id=1281368 Emil, the point is - if it has -not- reached sta...@vger.kernel.org, how can it be applied, in the first place. Aye ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] Debugging INVALID_OPCODE / MULTIPLE_WARP_ERRORS ?
Hi all,
As part of my compute work I'm trying to get some TGSI compute
code to work. The code from mesa/src/gallium/tests/trivial.c
works.
So now I'm trying to get a "native" tgsi kernel to run via
clover, I'm using Francisco's nbody.c example for this:
https://fedorapeople.org/~jwrdegoede/nbody.c
Which does not work, at first I thought there was an issue
with the setup of the input / output buffers, but that seems to
work fine, and moreover I finally got the smart idea to look
in dmesg, which says:
[ 9920.802435] nouveau :01:00.0: gr: TRAP ch 6 [007f7fa000 nbody[31881]]
[ 9920.802449] nouveau :01:00.0: gr: GPC0/TPC0/MP trap: global []
warp 10009 [INVALID_OPCODE]
[ 9920.802456] nouveau :01:00.0: gr: GPC0/TPC1/MP trap: global 0004
[MULTIPLE_WARP_ERRORS] warp 20009 [INVALID_OPCODE]
and repeats that for every "step" in the nobody simulation, this is on a
gk107 card.
So that seems to be the real problem, since the
error says "INVALID_OPCODE", I've put the tgsi code from nbody.c
through "nouveau_compiler -a e4" and then run "nvdisasm -b SM30"
on it, but the output looks ok. There is a 8 byte sequence which does
not get decoded every 64 bytes but AFAIK that is the scheduling info,
so that should be fine.
One thing which does stand out is that this:
0: ld u32 %r219 c0[0x+0x0] (0)
1: ld u32 %r222 c0[0x4] (0)
2: ld u64 { %r225 %r228 } c0[0x8] (0)
3: ld u32 %r234 c0[0x10] (0)
Gets translated into (nvdisasm output) :
/*0008*/ LDC R4, c[0x0][0x0];
/* 0x140003f11c86 */
/*0010*/ MOV R2, c[0x0][0x4];
/* 0x2800400010009de4 */
/*0018*/ LDC.64 R0, c[0x0][0x8];
/* 0x140023f01ca6 */
/*0020*/ MOV R3, c[0x0][0x10];
/* 0x280040004000dde4 */
Where I would expect for LDC instructions, could that be the problem ?
If that is not the problem, then hints how to debug this further would be
greatly appreciated.
Regards,
Hans
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] Same bug
This is the same bug keeping me at FC22 ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 93385] Dual head issues with xrandr
https://bugs.freedesktop.org/show_bug.cgi?id=93385 --- Comment #2 from Deuchnord --- Created attachment 120525 --> https://bugs.freedesktop.org/attachment.cgi?id=120525&action=edit Older version of Xorg.0.log -- 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 93385] Dual head issues with xrandr
https://bugs.freedesktop.org/show_bug.cgi?id=93385 --- Comment #1 from Deuchnord --- Created attachment 120524 --> https://bugs.freedesktop.org/attachment.cgi?id=120524&action=edit Xorg.0.log -- 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 93385] New: Dual head issues with xrandr
https://bugs.freedesktop.org/show_bug.cgi?id=93385 Bug ID: 93385 Summary: Dual head issues with xrandr 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: astrofac...@gmail.com QA Contact: xorg-t...@lists.x.org Created attachment 120523 --> https://bugs.freedesktop.org/attachment.cgi?id=120523&action=edit config-xrandr script For some reasons I wrote a script that configures my dual screen with Xrandr and Nouveau, that I manually launch with the command line (see attached "config-xrandr" file). All this worked perfectly until an update of Xorg and Nouveau, when it totally fails to configure my dual screen and the display is completely broken, as you can see on this photo: http://i.imgur.com/yyAqHZI.jpg I took a screenshot: http://i.imgur.com/WkbXCPC.png and saw that the size of the left screen (the external) and the position of the right screen (the internal) were not correct. -- 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] drm/nouveau: Fix pre-nv50 pageflip events (v4)
On 15 December 2015 at 11:11, poma wrote: > > Apparently not reached @stable (stable: 4.3.3 2015-12-15), > so here's one more time. > It has reached 4.4-rcX and will get picked by the stable maintainer (Greg?) in due time. Meanwhile you can ask your distro maintainers to apply it locally until we get an official release that includes it. -Emil ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH] drm/nouveau: Fix pre-nv50 pageflip events (v4)
On 10.11.2015 17:41, Thierry Reding wrote: > On Tue, Nov 10, 2015 at 05:37:31PM +0100, Thierry Reding wrote: >> From: Daniel Vetter >> >> Apparently pre-nv50 pageflip events happen before the actual vblank >> period. Therefore that functionality got semi-disabled in >> >> commit af4870e406126b7ac0ae7c7ce5751f25ebe60f28 >> Author: Mario Kleiner >> Date: Tue May 13 00:42:08 2014 +0200 >> >> drm/nouveau/kms/nv04-nv40: fix pageflip events via special case. >> >> Unfortunately that hack got uprooted in >> >> commit cc1ef118fc099295ae6aabbacc8af94d8d8885eb >> Author: Thierry Reding >> Date: Wed Aug 12 17:00:31 2015 +0200 >> >> drm/irq: Make pipe unsigned and name consistent >> >> Triggering a warning when trying to sample the vblank timestamp for a >> non-existing pipe. There's a few ways to fix this: >> >> - Open-code the old behaviour, which just enshrines this slight >> breakage of the userspace ABI. >> >> - Revert Mario's commit and again inflict broken timestamps, again not >> pretty. >> >> - Fix this for real by delaying the pageflip TS until the next vblank >> interrupt, thereby making it accurate. >> >> This patch implements the third option. Since having a page flip >> interrupt that happens when the pageflip gets armed and not when it >> completes in the next vblank seems to be fairly common (older i915 hw >> works very similarly) create a new helper to arm vblank events for >> such drivers. >> >> v2 (Mario Kleiner): >> - Fix function prototypes in drmP.h >> - Add missing vblank_put() for pageflip completion without >> pageflip event. >> - Initialize sequence number for queued pageflip event to avoid >> trouble in drm_handle_vblank_events(). >> - Remove dead code and spelling fix. >> >> v3 (Mario Kleiner): >> - Add a signed-off-by and cc stable tag per Ilja's advice. >> >> v4 (Thierry Reding): >> - Fix kerneldoc typo, discovered by Michel Dänzer >> - Rearrange tags and changelog >> >> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=106431 >> Cc: Thierry Reding >> Cc: Mario Kleiner >> Cc: Ben Skeggs >> Cc: Ilia Mirkin >> Signed-off-by: Daniel Vetter >> Reviewed-by: Mario Kleiner >> Cc: sta...@vger.kernel.org # v4.3 >> Signed-off-by: Mario Kleiner >> Signed-off-by: Thierry Reding >> --- >> drivers/gpu/drm/drm_irq.c | 54 >> ++- >> drivers/gpu/drm/nouveau/nouveau_display.c | 19 ++- >> include/drm/drmP.h| 4 +++ >> 3 files changed, 68 insertions(+), 9 deletions(-) > > Hi Dave, > > It'd be great if you could queue this up for fixes, since it gets rid of > a WARN_ON() that is triggered on a number of cards in v4.3. I realize > that this is a tad big for stable, but it's the right way to fix this. > If you'd prefer something smaller, I think we can fix the regression > using a one-line band-aid and then apply this one on top for v4.4. > > Thierry > Apparently not reached @stable (stable: 4.3.3 2015-12-15), so here's one more time. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
