05:54nfk: This is probably a DRM or even Tomoyo issue but could someone take a look at this and point me in the right direction (or just tell me that it's no biggie): https://paste.kde.org/paeznxtaq/i2abrm
05:55nfk: actually, unlikely to be tomoyo, so drm or something
06:41nfk: time for midsummer (even though we had the real one on sunday), i'll be back sometime tonight or tomorrow
06:41imirkin: nfk: glanced at it, don't see how it can happen
06:42nfk: so i'm gettinga ghost message?
06:42imirkin: nfk: might be memory corruption, dunno
06:42nfk: anyway, it doesn't seem to actually affect anything
06:42imirkin: nfk: but at the top of nouveau_drm_init, we set set_busid :)
06:42nfk: it has never happened before
06:43nfk: which file? maybe my kernel does not have it?
06:43imirkin: i checked in v4.1
06:43nfk: driver_pci.set_busid = drm_pci_set_busid;
06:43nfk: driver_platform.set_busid = drm_platform_set_busid;
06:44nfk: that's all i grepped there for busid
06:44nfk: actually, i get those two lines even for the 4.0
06:45nfk: + case MAXWELL_CHANNEL_GPFIFO_A: // the only change between 4.0.5-gentoo and 4.1.0-gentoo for that file
06:45nfk: anyway, shower
07:19nfk: imirkin, thanks for answering, i'll leave the box running memtest86+ to make sure it's not a physical error despite how unlikely that is
07:21imirkin: very unlikely if it's reproducible.
07:21imirkin: when i said memory corruption i meant more actively by the kernel, not with background radiation :)
07:43mogorva: Hi! i need help with apitrace and with this particular bug: https://bugs.freedesktop.org/show_bug.cgi?id=91056
07:43mogorva: I created a trace file and loaded into qapitrace with & without optimization enabled. Without optimization objects in the game are rendered correctly, that's what is shown in the left-side image here: http://i.imgur.com/B3OxJTT.png
07:44mogorva: I selected frame #399 because the difference is clearly visible there. What function should I look for in that frame in qapitrace??
07:52imirkin: mogorva: find a specific draw call rather than a frame number
07:52imirkin: mogorva: you're looking for a function like glDraw* (glDrawArrays, glDrawElements, and there are a few other variants, all starting with glDraw)
07:52imirkin: you only need a single trace... the trace won't change with opt enabled/disabled btw
07:52imirkin: er, single apitrace
07:53imirkin: once you identify the specific draw call
07:53imirkin: grab valgrind-mmt, and run 'glretrace -D $drawcall' under it, both with and without optimizations
07:53imirkin: then we can compare the resulting mmt logs (using demmt, found in envytools)
07:54imirkin: which should show us what exact shader was being used on that last draw call
07:55mogorva: there are several glDrawElements calls and only one glDrawArray in that specified frame. which one should I select?
07:56imirkin: mogorva: try all of them :) if you double-click on it in qapitrace, it'll run the drawing up to and including that call, but no further
07:56imirkin: you should then be able to compare the results with and without opts
07:56imirkin: (or just run it with opts and look to see if it has the corruption you're expecting)
07:57mogorva: that specified frame is fully corrupted because the game renders only a brownish polygon in that frame, nothing else can be seen
07:58imirkin: maybe. or maybe that brownish polygon is just "added" at the very end of the frame. who knows.
07:59imirkin: or it could just be the clear color, and none of the draws end up doing anything with opts
07:59imirkin: mogorva: btw, it might help if you could also upload that trace somewhere (perhaps you already have?)
08:00mogorva: imirkin: apitrace link is already in the bugreport, but I created a much smaller trace, i will upload it asap
08:00imirkin: mogorva: wait, the rhs and lhs frames before 399 seem wrong too
08:01imirkin: you should identify the *first* broken frame... errors in earlier frames can propagate down to later ones
08:08mogorva: i can't tell exactly which is the first broken frame, because the game starts with a black screen (between frame#190 and #260) and the screen becomes brighter gradually when the main menu appears (where the problem is already there)
08:09mogorva: currently i'm working with this trace file: https://drive.google.com/open?id=0B-tTbLKBl-tOemdrREFHbWdOZXM&authuser=0
08:13imirkin: mogorva: with glretrace, you can tell it to dump every frame as a png, and you can then diff the png's
08:43mogorva: what is the exact syntax for valgrind? will something like this do: valgrind --tool=mmt --log-file=file-bin.log glretrace -D $26270 BardTale.trace
08:46imirkin: look at the valgrind-mmt wiki page. it takes like 100 args.
08:46imirkin: just copy & paste :)
08:47mogorva: should be '--mmt-trace-nouveau-ioctls' an additional option?
08:47imirkin: that sounds right
08:47imirkin: alias mmt='~/valgrind/bin/valgrind --tool=mmt --mmt-trace-file=/dev/nvidia0 --mmt-trace-file=/dev/nvidiactl --mmt-trace-file=/dev/dri/card0 --mmt-trace-file=/dev/dri/card1 --mmt-trace-nvidia-ioctls --mmt-trace-nouveau-ioctls
08:47imirkin: that's what i have
08:48imirkin: but note that this is an old command... i think it adds the trace-file's automatically now
08:48imirkin: and then i run 'mmt --log-file=foo bla-command'
08:48imirkin: also the $ was there php-style... glretrace -D 26270 :)
08:48imirkin: (or bash-style)
09:12mogorva: i've got a log file generated by valgrind, how does this 'demmt' thing work?
09:13imirkin: demmt -l the-file
09:16mogorva: it does nothing for me :(
09:17imirkin: how big is the file?
09:17mogorva: 179 MB
09:17imirkin: hm, that sounds right
09:17imirkin: or at least not wrong :)'
09:18imirkin: you did build demmt, right? :)
09:18mogorva: yep, from envytools
09:18mogorva: i used this command to generate the log file with valgrind: '~/valgrind-mmt/bin/valgrind --tool=mmt --mmt-trace-nouveau-ioctls --log-file=26270_opt.log glretrace -D 26270 BardTale.trace'
09:19imirkin: well, xz -9 both the opt and no-opt mmt traces and make them available
09:19imirkin: yeah that seems right
09:33mogorva: imirkin: mmt traces without optimization: https://drive.google.com/open?id=0B-tTbLKBl-tOQUZVdEJTQ1puVW8&authuser=0
09:33mogorva: imirkin: with optimization: https://drive.google.com/open?id=0B-tTbLKBl-tOeFpHTDByZWRFYkk&authuser=0
09:36imirkin: i probably won't have time to look at it for at least a few days
09:37imirkin: and i can be forgetful, so if you don't hear anything from me before this weekend, ping me again :)
09:38mogorva: imirkin: thanks for the help getting me so far...
09:40imirkin: np. always nice to have a bug reporter who's interested in helping arrive at a fix.
09:41mogorva: imirkin: but it's just one of the glDrawElements call from that frame, should I repeat the same procedure with all of the glDraw... calls from that frame?
09:41imirkin: mogorva: well... heh. the idea was to isolate the shader that gets optimized "wrong"
09:42imirkin: coz staring at ALL the shaders can take ... quite some time
09:42imirkin: and there's no *really* easy way to see the generated shader for a particular draw outside of the trace... nouveau can dump shaders on compile, but a shader is compiled once and then reused often
09:42imirkin: anyhoo, gtg
10:04mogorva: is anyone here who managed to attach/inject apitrace native (Linux) to a Steam game that runs in Wine? The command I used + terminal output (I received only a useless ~400 kB trace file): http://pastebin.com/WduVxwXE
10:05mogorva: Steam starts the game and the game crashes somewhere in nouveau, but apitrace isn't injected properly.
10:29mlankhorst: wine re-executes itself
10:30mlankhorst: and forks
10:32mogorva: mlankhorst: is anything that could be done to overcome the problem?
10:33mlankhorst: I forgot how steam spawns processes
10:33mlankhorst: but if you have a binary that can run without steam WINELOADERNOEXEC=1 LD_PRELOAD=i386.so probably
10:36mogorva: unfortunately all the games that show this kind of crash won't start without steam
10:40prg_: have steam running in the background and apitrace the game exe
10:40mlankhorst: is it because of the overlay?
10:40mogorva: i have gameoverlayrenderer.dll disabled
10:45mogorva: prg_: also tried that method but no trace file was generated
10:47prg_: but tracing wine games without steam works?
10:47mogorva: prg_: yes, that works
10:49prg_: huh, nfi then
12:18imirkin_: ftr, the trick is to run steam separately and the game binary separately. but he's gone. oh well.
12:19imirkin_: yusukesuzuki: mmm... i'd sorta prefer to do it the same way that the blob does it. i think the sw methods have a lot more overhead.
12:20imirkin_: yusukesuzuki: and it would ensure that mesa can work with both nvidia and nouveau firmware
12:49nanga: Hey guys! Is it possible to enable tripple buffering on a NVIDIA GT220?
12:50imirkin_: you might be able to set GLXVblank to 2 instead of 1
12:50imirkin_: not 100% sure if that enables triple-buffering
12:50imirkin_: er... make that SwapLimit
12:51imirkin_: (see 'man nouveau')
15:14nfk: imirkin, at least physical memory errors can be rulled out
15:14nfk: also, on this boot i'm still getting those messages in dmesg
16:46yusukesuzuki: imirkin_: hi!
16:47yusukesuzuki: imirkin_: I tried to use SW object's method. Made sure that SW's handler is called when pushing commands into SW's subchannel, but trap handler doesn't work well.
16:48yusukesuzuki: imirkin_: the caused error is the same to the case when I set value through MMIO. so timing issue is not solved by SW object...
17:33briocalter_: kernel: nouveau E[ PFIFO][0000:02:00.0] read fault at 0x0017bc0000 [PTE] from CE2/GR_CE on channel 0x007f698000 [unknown]
17:33briocalter_: trying to run CS:GO on mesa git
17:46nfk: briocalter, just don't run away, someone who can help you will show up sooner or later though i have to say that line alone might not be overly helpful
17:49briocalter: that's the only output on dmesg tho, could apitrace if needed
20:05imirkin: briocalter: if you can construct an apitrace that triggers that error, it's a million times likelier that the problem will get fixed
20:06briocalter: the PC hangs, but I'll try
20:06imirkin: briocalter: right, so the problem is that the error you get is *highly* disconnected from specific actions that the mesa driver performs
20:07imirkin: briocalter: that said i did commit a fix that could fix some phantom PTE read type errors earlier today, but it's *highly* unlikely to actually affect anything
20:08briocalter: lemme revert and update
20:09imirkin: basically the only time it can matter is if you have multiple TF result buffers and you update the settings for some but not others. or something along those lines.
20:09imirkin: i'm not even sure it's triggerable with OpenGL :)
20:09imirkin: but the code looked funny so i fixed it
20:14briocalter: is it on master already?
20:14briocalter: git log is funny
20:16imirkin: briocalter: yea...
20:55briocalter: odd, the .trace is nowhere to be found
20:55briocalter: LD_LIBRARY_PATH=/usr/local/lib steam DEBUGGER="apitrace trace" steam steam://rungameid/730
20:56briocalter: no idea what's wrong
20:57briocalter: oh, I see now