00:00 Jayhost: Yeah I had wondered that
00:01 Jayhost: But It doesn't happen if no reclock
00:02 Jayhost: I'll throw more data in a sec
00:02 karolherbst: Jayhost: could you apitrace dolphin?
00:02 karolherbst: maybe it always happens in the trace and at the same spot
00:03 Jayhost: http://pastebin.com/t8wZcP1e
00:04 karolherbst: such a EQ stack never helps
00:05 Jayhost: It will happen if I play a different game too
00:05 karolherbst: you should apitrace dolphin and check if replaying the trace also lets the gpu hang
00:05 karolherbst: Jayhost: mhh does it crash for other applications?
00:05 Jayhost: I havn't tested any
00:06 Jayhost: What would be good stress test
00:06 Jayhost: not glxgears I assume
00:06 Jayhost: ha
00:07 Jayhost: version of xserver-xorg is Debian Sid 1:1.0.12-1
00:19 Jayhost: karolherbst pstate says memory is only 800 out of 5400
00:21 karolherbst: yeah
00:21 karolherbst: because there is no memory reclocking for maxwell yet
00:23 Jayhost: glxgears runs fine
00:31 mupuf: karolherbst, hakzsam: I am about to leave for a week end, want me to plug any GPU?
00:31 mupuf: Right now, GK208, GK106
00:32 karolherbst: mupuf: kepler2+ for me
00:34 mupuf: hakzsam mentioned he fixed shared + atomics yesterday on kepler
00:34 mupuf: so, not sure what he would be interested in now
00:34 mupuf: karolherbst: want to have a look at the GM206?
00:35 mupuf: nevermind, he has code he needs to rewrite and it will be hell (so he said)
00:35 mupuf: so, I will leave these two
00:36 mupuf: At some point, I will need a reator2 if you compete that much for its access
00:39 karolherbst: mupuf: doesn't matter, there is something funky with the pmu on kepler2+
00:40 karolherbst: perf_init only partly done, like some instructions executed, some now
00:41 mupuf: lovely
00:41 Jayhost: Pcsx runs fine reclocked
00:47 karolherbst: mupuf: maybe something with the alignment is wrong?
00:47 Jayhost: karolherbst I have to shutdown now. If you have some other instructions I'll read later and keep trying to refine clock tree otherwise.
00:47 karolherbst: mupuf: thing is, the first isntruction in perf_init aren't run
00:47 karolherbst: but later ones...
01:02 Jayhost: and apitrace
01:04 karolherbst: mupuf: any idea why the same fuc code works on kepler1, but not kepler2?
01:08 Jayhost: Also when I nvapoke around I get that uncached memory error
01:23 karolherbst: ....
01:23 karolherbst: yeha lol
01:23 karolherbst: perf isn't included in the kepler2+ fuc code...
01:23 karolherbst: ohh wait, it is
01:23 karolherbst: weird
01:45 mupuf: karolherbst: well, some instructions may have changed
01:45 mupuf: and you may need to find which ones :s
01:45 mupuf: and then fix our assembler
01:46 mupuf: mwk: we have no hwtests for fuc, right?
01:46 mwk: nope
01:46 karolherbst: mupuf: thing is, if I send something to PERF I don't get any reply at all
01:47 mupuf: ok, so you did not start debugging this yet
01:47 mupuf: mwk: thanks for the confirmation
01:47 karolherbst: not really, no
01:48 mupuf: well, I would assume that the bug is in the command submission
01:48 karolherbst: I just noticed it does something else
01:48 mupuf: what does it do?
01:48 karolherbst: something different :D
01:48 karolherbst: mhhh
01:48 karolherbst: wait a sec
01:48 mupuf: nvidia maybe changed a little the interface and we failed to notice
01:48 karolherbst: I think the instruction layout changed completly, because I see some kind of pattern
01:49 karolherbst: you will see it too
01:50 karolherbst: perf_init (configures the pmu counters): https://github.com/karolherbst/nouveau/blob/pmu_counters/drm/nouveau/nvkm/subdev/pmu/fuc/perf.fuc#L153-L219
01:50 karolherbst: actual values: https://gist.github.com/karolherbst/09df5eb979ccfaf98ab1
01:51 karolherbst: c0 is kepler1, c1 is kepler2
01:51 karolherbst: but it should be the same for both
01:52 karolherbst: seems like 0x0010ffff isn't set?
01:53 karolherbst: ohh good idea actually, I could just write 0xffffffff into one reg
01:55 karolherbst: 0xffffffff on gk106 and 0xffae0000 on gk208
01:55 karolherbst: imm32($r14, 0xffffffff); nv_iowr(NV_PPWR_COUNTER_MASK(6), $r14)
02:05 karolherbst: mhh this is odd
02:09 karolherbst: 0xffae is the reg mask
02:09 karolherbst: oxffae3fff
02:10 karolherbst: and using mov works
02:10 karolherbst: maybe just imm32 is broken
02:11 karolherbst: .. now this is scary
02:11 karolherbst: imm32 should be mov on gk208 already...
02:15 karolherbst: ohhh
02:15 karolherbst: the preprocessor messes up
02:15 karolherbst: ....
02:16 mupuf: Ah ah
02:16 karolherbst: it generates "movw $r14 ((0xffffffff) & 0x0000ffff); sethi $r14 ((0xffffffff) & 0xffff0000)" on gk208, allthough imm32 is mov reg (val) for ! #if NV_PPWR_CHIPSET < GK208
02:16 karolherbst: and imm32 is movw, sethi only for NV_PPWR_CHIPSET < GK208
02:16 karolherbst: ...
02:17 karolherbst: .....
02:17 karolherbst: wtf
02:17 karolherbst: the macro is called NVKM_PPWR_CHIPSET
02:18 karolherbst: not NV_PPWR_CHIPSET
02:18 karolherbst: .....
02:18 karolherbst: seriously...
02:18 mupuf: Oh, joy
02:19 karolherbst: mhh vblanks are done through the pmu, right?
02:19 mupuf: wait for vblank? Yeah
02:20 karolherbst: nice, perf_init is now done the right way
02:20 karolherbst: but I think there might be hardcoded movw somewhere in the code
02:21 karolherbst: the pmu requests is still not coming through
02:21 karolherbst: but the regs have the expected values now
02:24 karolherbst: where there some with tearing issues on kepler2+ gpus?
02:27 karolherbst: but why doesn't movw work on gk208
02:28 karolherbst: ohh maybe sethi is the thing that causes problems, because otherwise st/ld should be broken already
02:36 karolherbst: yeah nice
02:36 karolherbst: mupuf: sethi clears the low bits on gk208
02:36 mupuf: ah ah
02:37 karolherbst: so, no sethi then :p
02:37 mupuf: or you sethi first :p
02:38 karolherbst: I bet movw clears the hi bits
02:38 mupuf: but yeah, please document this in fuc's hw doc
02:38 karolherbst: :p
02:38 karolherbst: aha...
02:39 karolherbst: sethi $r14 0xffff0000; movw $r14 0x0000ffff; $r14 is 0x0
02:39 karolherbst: ...
03:05 hakzsam: mupuf, yeah, both kepler is cool
03:10 karolherbst: yay
03:10 karolherbst: the \fffff thing is gone
03:10 karolherbst: now I get "pmu: NTR 52544e03 00000000 00000001 00000000"
03:10 mupuf: which is good or still bad? :D
03:10 karolherbst: well
03:10 karolherbst: still bad
03:11 karolherbst: but \xfffffNTR looked worse
03:11 karolherbst: ahh crap
03:11 karolherbst: there is a bug within nouveau debug messages
03:11 karolherbst: one line: "[ 165.016899] nouveau 0000:05:00.0: pmu: [ 166.015042] nouveau 0000:05:00.0: pmu: wait on reply timed out"
03:12 karolherbst: ohh I bet it gets a \0 and the kernel ignores the \n later
03:13 karolherbst: mhh
03:14 karolherbst: process is either 52544e03 or 52544e00
03:14 karolherbst: which is KER.
03:14 karolherbst: k, so somewhere PROC_KERN gets corrupted
03:14 RSpliet: karolherbst: no, somehow the fifo gets corrupted
03:15 karolherbst: RSpliet: sethi clears low bits on gk208 ;)
03:15 karolherbst: I bet there are other instructions which behave differently
03:16 RSpliet: or something is simply writing out of it's memory bounds
03:16 karolherbst: why does it work on gk106 then?
03:17 RSpliet: different memory layout -> different data gets corrupted? idk, shot in the dark here, but try and cross out simple-to-test explanations before continuing with more difficult ones ;-)
03:19 karolherbst: yeah, but I already confirmed that sethi thing, maybe it is the only instruction which behaves differently, but that bug was also obvious: https://github.com/karolherbst/nouveau/commit/d4b18b2ff52512448fd811d90f94de5bf9b78cf1#diff-f667edc4764ddcb29e54f6b9bda97ef4
03:19 karolherbst: nice, host_recv gets 52544e03
03:21 karolherbst: yeah something is messing with the first byte there
03:28 karolherbst: not even the timer is running on the gk208
03:49 karolherbst: oh man, everything is messed up...
03:51 karolherbst: ohh wait, that's because of the reg mask .. silly me
04:04 karolherbst: mupuf: I think call #symbol is broken, beacuse call(func_name) works....
04:08 karolherbst: it works! \o/
04:11 karolherbst: mhhh
04:11 karolherbst: there are indeed binary differences on gk208 for the call # thing
04:16 karolherbst: was there some mov/movw fix in envytools for gk208?
04:22 mwk: yeah, there's a new mov instruction with 32-bit imm
04:27 karolherbst: mhh
04:27 karolherbst: I am curious, because when I replace movw with mov locally inside ld() and st() I get no binary changes, but this fixes the pmu problems I have on reator with a gk208 :/
04:31 karolherbst: mwk: do you think this is odd? https://github.com/karolherbst/nouveau/commit/73c360a51bb18b082dc151c59f4102d5689bbbd1
04:31 karolherbst: this change only changes stuff for the fuc5 falcons
04:33 mwk: uh, no idea?
04:34 mwk: hmm
04:34 mwk: it changes call to lcall
04:34 mwk: I'd have thought call still works, as long as you don't go over 16-bit range
04:34 karolherbst: ahh now I get the mov, movw change
04:35 karolherbst: and this one: https://github.com/karolherbst/nouveau/commit/e1484141900bc28b221e82bb18357063bdc56e6b
04:35 karolherbst: no changes on non fuc5 falcons
07:20 karolherbst: mhhh " Message body is too big: 115057 bytes with a limit of 100 KB" ...
07:20 karolherbst: yeah well
07:20 karolherbst: big patches need space :D
07:21 hakzsam: split it :)
07:21 karolherbst: I can't
07:21 karolherbst: or I could but it wouldn't make sense
07:21 hakzsam: ok
07:21 karolherbst: though I could update those falcon binaries per target
07:21 karolherbst: ...
07:22 karolherbst: is fdo down or is it just me?
07:22 hakzsam: seems like slow again
07:23 karolherbst: it's slow everytime I try :(
07:23 karolherbst: for 3 days now
07:23 karolherbst: thing is, it just errors for me here :/
07:27 Jayhost: karolherbst I couldn't get dolphin to crash with apitrace but also the reclocking isn't actually working
07:30 karolherbst: Jayhost: memory doesn't reclock yet on maxwell
07:31 Jayhost: yes but it seems to even dip the performance
07:31 Jayhost: 200 - 1300 instead of 400 and less framerate
07:32 hakzsam: computer shaders are mostly done for kepler1 :)
07:59 karolherbst: hakzsam: nice
07:59 karolherbst: Jayhost: yeah well, if we use higher voltages for a clock, you get of course lower clocks
08:08 Jayhost: I see. The performance just wasn't as expected but I got it to work and crash as expected.
08:11 karolherbst: Jayhost: so does it currently crash only in dolphon or also somewhere else?
08:16 Jayhost: only dolphin
08:16 Jayhost: I'm trying to get it to crash with apitrace now
08:17 Jayhost: I don't have any other graphically intense apps
08:26 karolherbst: Jayhost: you could download the unigine heaven benchmark
08:51 pmoreau: gnurou: Still no luck, I guess I made an error somewhere else in the stack
08:52 hakzsam: imirkin, I have fixed this UBOs thing on kepler :)
08:52 hakzsam: imirkin, the series is almost ready
09:38 wyre: hi guys! how could I use video composite output of my graphic card?
09:42 xexaxo: wyre: if you've got one of the few cards where it works - just plugin the cable and check xrandr (or your fav GUI).
09:42 xexaxo: https://nouveau.freedesktop.org/wiki/FeatureMatrix/
09:42 wyre: xexaxo, but then ... should I install mesa and xorg?
09:42 xexaxo: alternatively, get a mmiotrace of the blob and get your hands dirty :)
09:43 xexaxo: wyre: err... you're not using the official/binary driver are you ?
09:43 xexaxo: if so we cannot really help you here. otherwise they should already be installed :)
09:43 wyre: xexaxo, I'm using xf86-video-nouveau
09:44 wyre: but the machine is a server and I manage it remotely by ssh
09:44 xexaxo: wyre: can you pastebin your xorg.log
09:44 wyre: it has not DE or Xorg
09:44 wyre: I've got only installed video driver
09:45 xexaxo: if it doesn't have a xserver then you're not really using xf86-video-nouveau. just have it installed ;-)
09:45 wyre: mmm ok
09:45 wyre: so ... I cannot use TVout to see PC starting? for instance?
09:46 wyre: really I'll use TV output when Xserver are loaded?
09:46 xexaxo: don't think one can manage outputs without xserver (or other solutions like weston).
09:47 wyre: xexaxo, but I mean ... why really I can see the PC startup if I'm using VGA?
09:50 wyre: xexaxo, and shoudl I install mesa?
09:56 xexaxo: wyre: mesa is for 3d graphics
09:56 xexaxo: whereas to the other question - not sure I get what you mean there.
09:56 wyre: xexaxo, when I turn on the PC for example in grub
09:57 wyre: I wont can use composite video?
09:57 wyre: should I wait to xserver turns on?
09:57 wyre: (xrandr says "Can't open display") :(
09:58 xexaxo: "I won't can use composite video" = "I cannot see anything on the device connected to the composite video output" ?
09:59 wyre: yes
09:59 xexaxo: if you boot with the cable plugged, and nothing gets displayed on the TV during bios and/or kernel startup, there's small chance that nouveau will work.
09:59 xexaxo: can you pastebin a the output of dmesg ?
10:00 xexaxo: x randr, as the name suggests requires working x server
10:01 wyre: ok ... wait
10:05 wyre: in startup does work
10:05 wyre: the output
10:05 wyre: but now xrandr says the same
10:05 wyre: Can't open display
10:06 wyre: xexaxo, maybe i need install something else
10:07 karolherbst: xrandr needs a running X server
10:07 xexaxo: wyre: there is no way to manage outputs without xserver (99% sure). the way to do it with xserver is via xrandr or a GUI based on top of it.
10:09 linkmauve1: xexaxo, there kind of is, you could have a program be DRM master, change some properties, then exit.
10:09 linkmauve1: There is also fbset, which I used to use *long* ago, and as the name implies works on fbdev.
10:10 xexaxo: linkmauve1: considering the scenario, I doubt {s,}he's likely to write such an all.
10:10 linkmauve1: Indeed.
10:11 xexaxo: whereas to fbset... sure it works... although it was _very_ hacky solution. it essentially trims it down do your required size
10:11 linkmauve1: I don’t think fbdev has any concept of multiple outputs though.
10:12 karolherbst: well in theory it should be possible to just use the kms API
10:12 karolherbst: I think wayland also uses this for all kinds of stuff?
10:12 xexaxo: karolherbst: that's what linkmauve1 was suggesting. and yes wayland/weston does use it
10:13 linkmauve1: Xorg as well, with the modesetting DDX.
10:13 xexaxo: linkmauve1: it doesn't afaict. that's why you get you output cloned during kernel/module load
10:17 Jayhost: karolherbst http://www.pastebin.ca/3382668 replay doesn't halt gpu.
10:21 karolherbst: Jayhost: mhhh, I doubt that the kernel module is the problem here
10:22 karolherbst: Jayhost: when the screen freezes, are you able to restart X from ssh and continue without issues?
10:26 Jayhost: karolherbst It has never let me do that. I do service lightdm stop. killall Xorg to no effect
10:31 karolherbst: Jayhost: tried with -KILL flag?
10:32 Jayhost: I don't understand
10:34 karolherbst: killall -KILL Xorg, but the process might also have a different name
10:34 karolherbst: try to kill that stuff with htop or look the pid up first
10:35 Jayhost: okay I'll try that and stable packages but I thought the reclocking meant it was exclusive to kernel
10:41 wyre: xexaxo, it's installed
10:41 wyre: (xserver... )
10:42 xexaxo: wyre: sweet. just use xrandr and manage the output to you linking.
10:43 xexaxo: hmm something I implied but, did not mention - you will have to operate with the output (composite video) via xserver.
10:45 xexaxo: if you kill xserver the output will restore it's original (pre x) state.
10:46 wyre: xexaxo, doesn't works
10:46 wyre: xrandr says the same
10:46 wyre: Can't open display
10:47 xexaxo: you need to have X server started and correctly set the DISPLAY variable before starting any applications
10:48 xexaxo: do you have a xorg.log for me ?
10:50 wyre: I think I cannot start xserver from ssh
10:50 wyre: right?
10:53 wyre: xexaxo, maybe could I configure it with "Xorg :0 -configure"?
10:53 wyre: and restart?
10:53 xexaxo: don't do any of that ?
10:54 wyre: I've just installed xorg-server
10:54 xexaxo: just read up on the recommended procedure to start it up on your distro.
10:54 xexaxo: iirc -configure has been busted for KMS drivers for a long time
10:55 wyre: xexaxo, it's xorg.conf generated with startx?
10:55 wyre: (the first time? )
10:57 xexaxo: in 99% of the cases you don't need one.
10:58 xexaxo: xserver has a "built-in" one that pretty much just works.
10:58 xexaxo: I'm off, happy hacking
14:46 Jayhost: karolherbst new notes / errors after trying stable packages. http://pastebin.com/raw/SuY48pYM
14:54 karolherbst: mhhh
14:54 karolherbst: libevdev seems to be really old
14:54 karolherbst: what X server version do you have?
14:54 karolherbst: and what version is mesa?
14:55 karolherbst: Jayhost: usually you should use the newest of everything, especially for maxwell
14:57 Jayhost: It's all stock debian stable this time
14:57 karolherbst: which means old
14:58 karolherbst: and with more bugs than newest stuff (usually)
14:58 Jayhost: Okay I had just done that to see if the info would be useful
14:59 karolherbst: libevdev 2.1.3 is really old
14:59 karolherbst: usually you won't be happy with nouveau on debian, due to the old stuff (even sid is sometimes too old)
15:00 Jayhost: Do you want me to run a benchmarking program. It doesn't look like Heaven benchmark is free software
15:00 karolherbst: and you want to have mesa 11.1
15:00 karolherbst: Jayhost: well I don't know any useable free benchmark though
15:01 Jayhost: Maybe blender3d would do it
15:01 karolherbst: blender is no benchmark
15:01 karolherbst: maybe there are blender based benchmarks, who knows
15:02 Jayhost: Right. I just mean to see if rendering would lock the gpu up
15:02 karolherbst: yeah, but you need a lot of loadä
15:02 karolherbst: just a tiny bit won't do it
15:02 karolherbst: usually
15:03 karolherbst: or not anymore
15:04 Jayhost: Yeah I think I have some scenes for huge loads
15:05 Jayhost: Are all of the devs using Nouveau on Ubuntu primarily.
15:05 karolherbst: mhh
15:05 karolherbst: I think the most nouveau devs are either using arch or gentoo
15:05 karolherbst: mostly arch though I think?
15:07 Jayhost: Out of curiosity. Desktops or Thinkpads? Obv Imirkin uses Mac G5
15:09 karolherbst: no clue
15:23 Jayhost: Blender doesn't detect so I suppose no gpu rendering today
16:45 lanteau_: hey guys. I was wondering if anyone would have any ideas on why if I boot with both monitors plugged into my GeForce 6600, the one monitor (VGA) has 2/3 of the screen black, the other third is working normally
16:45 lanteau_: If I boot with only one monitor connecting, and connect the VGA monitor after logging in, full screen works properly
16:45 lanteau_: one monitor connected*
16:48 lanteau_: Linux 4.4.0, Debian Stretch, it's powerpc.
19:24 Jayhost: karolherbst [ 619.029757] nouveau 0000:01:00.0: gr: TRAP ch 2 [007f9b7000 systemd-logind[555]]
19:24 Jayhost: [ 619.029765] nouveau 0000:01:00.0: gr: GPC0/TPC0/MP trap: global 00000004 [MULTIPLE_WARP_ERRORS] warp 10001 [STACK_MISMATCH]
19:29 imirkin: that's... most likely due to an emission error
19:29 imirkin: or some branch/etc thing doesn't work on maxwell like it works on fermi/kepler
19:29 Jayhost: I was just going to ask you to interupt. How can I look into it further?
19:30 Jayhost: interpret*
19:32 imirkin: if you can track down the shader that's executed when this happens, one could try to analyze it
19:37 Jayhost: Is there a link to where I can read about tracking down shader
19:39 imirkin: search for valgrind-mmt
19:40 Jayhost: Right gotcha thanks
19:44 Jayhost: I had mentioned your mac g5 earlier I don't know if you keep it as collection
19:48 imirkin: i have it right here... i keep meaning to fix it up, but... it's a pain.
19:53 Jayhost: Ahhh ya
20:53 gnurou: pmoreau: yeah at this point that's what I would suspect too - first check that secure boot is run from the kernel (add some printk maybe), then whether your X is using the right Mesa library with GM2 support?