00:12 orbea: imirkin: any idea if this could be resolved in 4.7 or 4.8? I might have to find a new network device...
00:13 imirkin: dunno
00:19 mooch: okay, i have miraculously implemented pfifo in most of its glory
00:20 mooch: what pgraph object classes for nv4 should i implement first?
00:20 mooch: keep in mind, i want to use this mainly on nt4
06:15 mupuf: well, that is embarassing... That is also weird that my second gpu (which had no LED), did not complain about this...
06:15 mupuf: I still need to protect against the division by 0 thpough
06:15 mupuf: Will do so tonight
06:16 mupuf: and the lack of the GPIO subsystem
07:19 karolherbst: orbea: isn't r8618 part of the kernel and r8619 the out of tree module?
07:19 karolherbst: or was it the other way around
07:20 karolherbst: mupuf: well on my system it just happen when I put my entire system into suspend (maybe gpu suspend would also trigger that, but I usually have runpm=0 set)
07:21 mupuf: karolherbst: I see
07:22 mupuf: yeah, thanks a lot!
07:37 karolherbst: Tuesday was funny, I was like "huh XDC is like next week" :D
07:45 karolherbst: still need to finish up my slides, guess I will do the fancy stuff today...
07:49 mupuf: hehe, yeah, time flies!
07:53 masterzorag: hi guys, trying to cool down GPU on laptop, some info: https://da.gd/6v17E
07:56 masterzorag: Function not implemented on echo 20 > /sys/kernel/debug/dri/0/pstate, any comment?
07:58 karolherbst: masterzorag: is your gpu passively cooled?
07:58 masterzorag: there is only one fan into laptop (samsung Q70), I'm thinking about yes, passivelyù
07:59 karolherbst: uhhh
08:01 masterzorag: karolherbst: how can I set the "slower" pstate profile? since it's powered by AC, so it's going to maximize performance...
08:03 masterzorag: I can succesfully echo some lower value at /sys about critical/emergency thresholds, and emergency works triggering a shutdown... but fan seems not enough to go under 90C...
08:07 masterzorag: this is the heatspreading piece: http://www.gscomputer.it/images/nq70.jpg
08:09 masterzorag: this is the fan: http://g01.a.alicdn.com/kf/HTB1l8khJXXXXXbBXXXXq6xXFXXXd/Commercio-all-39-ingrosso-di-new-cpu-del-computer-portatile-ventola-di-raffreddamento-per-samsung-q45.jpg
08:13 karolherbst: masterzorag: I don't know if we support switching the clocks on a g86 yet, let me check
08:14 mupuf: karolherbst: would be stupid, that was the first GPU to ever be reclocked on nouveau :D
08:14 mupuf: but yeah, it is possible it never lande
08:14 karolherbst: mupuf: https://github.com/karolherbst/nouveau/blob/master_4.7/drm/nouveau/nvkm/subdev/clk/g84.c#L46-L47 :p
08:14 mupuf: well, that's it then :)
08:14 karolherbst: no idea if it would work in theory
08:15 karolherbst: maybe engine works but memory is a mess?
08:15 karolherbst: no idea though
08:15 mupuf: it should, the GPU was so forgiving
08:15 karolherbst: k
08:15 karolherbst: then I suppose memory was the non forgiving part
08:15 mupuf:brought back this laptop from France and plans on using it for CI
08:16 karolherbst: masterzorag: if you don't mind compiling your own kernel/nouveau module, you could replace the "(device->chipset >= 0x94)" part with true in the file I linked
08:16 karolherbst: and boot with nouveau.config=NvMemExec=0
08:17 karolherbst: mupuf: I guess that is one reason more to just enable engine reclocking if it works well enough, even without support for memory
08:18 mupuf: yeah, well, let's plug the gpu to the world and see what we can do with it
08:18 mupuf:will have to hack something to be able to control the laptop though
08:20 karolherbst: hihi :D
08:20 mupuf: as you say :D
08:20 mupuf: but hey, the laptop has no value nowadays
08:20 mupuf: and I got it for free 7 years ago
08:21 mupuf: it got me started in nouveau though
08:21 masterzorag: to me it gets me started with OpenCL
08:21 mupuf: masterzorag: :)
08:22 masterzorag: so, karolherbst: I need to recompile patched module and use bootparm
08:34 karolherbst: mupuf: I still plan to convert my laptop to a desktop, but power supply is a big concern, cause I just got 250W in total :/
08:36 karolherbst: mupuf: https://www.techinferno.com/index.php?/forums/topic/8249-mxm-to-pci-e-x16-extension-project-complete-some-kinks-to-iron-out/ :D
08:36 karolherbst: that's what I need
08:40 karolherbst: masterzorag: yeah
08:41 masterzorag: karolherbst: thank you for now, actually I'm looking at the fan due seems only to start and stop, but don't change speed...
08:42 karolherbst: mupuf: http://www.pcidv.com/en/products.asp?id=628 !
08:43 karolherbst: I am sure it will not work cause those MXM cards are soo not built after the specs
08:46 karolherbst: uhh, for mxm 3.0 to pcie: http://www.liantec.com/product/TBM-1630.htm
08:46 karolherbst: ohh wait
08:47 karolherbst: that is something else
08:51 karolherbst: uhh awesome, my laptop indeed follows the mxm 3.0 specs :) good
08:53 karolherbst: uhh 200W max, that's quite a lot
10:49 Weaselweb_: Using kernel 4.7.x (gentoo-sources-4.7.2 in current case) results in a BUG(). dmesg from journalctl: http://pastebin.com/HWgRqR5T
10:49 Weaselweb_: any idea? more information required?
10:50 Weaselweb_: the situation is that the KDE screen locker is active and the display is turned off
10:52 karolherbst: Weaselweb_: k, so suspending the display triggers that bug?
10:53 Weaselweb_: karolherbst: well, AFAIR in each case this bug was triggered the KDE screen locker was active and the displays (dual screen) were suspended
10:53 Weaselweb_: but not in every case the screen goes blank this bug is raised
10:53 Weaselweb_: but it started using kernel 4.7.0
11:02 karolherbst: well, if you have time you could bisect the kernel and check what is causing it
11:03 karolherbst: but it might be the coherent patch again
11:03 karolherbst: ohh wait
11:03 karolherbst: maybe not
11:03 karolherbst: who knows
11:42 karolherbst: skeggsb: mind reverting this commit + CC stable to 4.7 and 4.8? https://github.com/skeggsb/nouveau/commit/20ba864fafb61a08c2de42b65e3467a8cd9b2a69
11:42 karolherbst: it causes breakage at random locations within userspace, usually whenever a nvc50_screen object is getting destroyed
11:43 karolherbst: gnurou gave his okay for that
12:02 Weaselweb_: karolherbst: I can do, but it might take at least one day per testing step for the problem to occur. and for the good case how should I judge that it doesn't happen?
12:06 karolherbst: ohh so it only happens sometimes?
12:06 mupuf: Weaselweb_: ah, hte best kind of bugs!
12:06 karolherbst: ugh
12:06 Weaselweb_: karolherbst: yep, unfortunately yes
12:07 karolherbst: Weaselweb_: try to identify the amount of locks where you can say it with a confidence of 99% or so and go from there
12:07 karolherbst: if you can say: 5 locks and dead, it is good enough
12:07 Weaselweb_: my uneducated guess: it is not the lock but rather the display blank
12:07 karolherbst: even if you git bisected once this way and don't directly find the issue, you still have a faint idea how old the issue is
12:08 Weaselweb_: but yes, I try to count that
12:08 karolherbst: Weaselweb_: yeah, would say that too
12:08 karolherbst: well you can do it from cli somehow
12:09 karolherbst: I know it is messy, but I doubt there is any other way :/
12:09 karolherbst: best thing is, you could trigger other bugs as well, cause the suspend code isn't really race condition free as well....
12:45 Weaselweb_: karolherbst: AFAICT in obj (RAX in kernel bug) has some bugs value in line https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/gf100.c#n183
12:47 karolherbst: yeah, no idea
12:48 karolherbst: It could be the usual race condition though
12:49 karolherbst: at some point I will try to fix them for my system
12:51 karolherbst: I've created a trello task for that: https://trello.com/c/5MebvrKN/163-race-conditions-on-suspend-or-unload
13:58 Weaselweb_: karolherbst: I blanked screen about 10x. Nothing special. But after locking KDE screen and blanking display twice the system crashed afterwards. So I guess I have a possibility to provoke that error \o/
13:59 Weaselweb_: qdbus org.freedesktop.ScreenSaver /ScreenSaver Lock; sleep 1; xset dpms force off
14:04 karolherbst: Weaselweb_: nice
14:09 karolherbst: Weaselweb_: make it 5 to be sure though
14:10 karolherbst: Weaselweb_: also, call sync!
14:10 karolherbst: before doing those qdbus calls
14:12 Weaselweb_: karolherbst: why would I need sync?
14:14 karolherbst: doesn't your kernel crash?
14:14 karolherbst: especially if you use btrfs, you _want_ to sync before crashing your kernel
14:14 karolherbst: otherwise you may get fs fun
18:08 orbea: about that ttm/nouveau crash I mentioned yesterday, it seems to be caused how in GLideN64 (nintendo 64 gfx plugin) handles dumping the cache for some games which seem to generate endless textures. Could someone take a look at this issue? Maybe you guys have some insights on how to better handle the issue? perhaps it can be all fixed in the program rather than kernel? :)
18:08 orbea: https://github.com/loganmc10/GLupeN64/issues/56
18:09 imirkin_: orbea: yeah, that's consistent with the error you got
18:10 imirkin_: which was some error while swapping stuff out of vram
18:10 imirkin_: (or swapping it back in? not sure)
18:19 orbea: I guess if there is a problem in how GLideN64 clears the cache, it would be here https://github.com/loganmc10/GLupeN64/blob/master/GLideN64/src/Textures.cpp#L1370
18:21 orbea: the cache could get pretty big, 500M or 128,000 textures
18:26 imirkin_: 500M isn't a ton though... you have like 3 or 6 GB of vram right?
18:27 orbea: i forget, might of been 8, proababl at least 6
18:35 orbea: guess accordig to dmesg its less, 3GB
19:48 orbea: imirkin_: seems it is the size of the textures cache, as a test I reduced the size by 75% in the GLideN64 code and no more slow downs or crashes.
19:49 imirkin_: ok
19:49 imirkin_: i'm guessing they way they're counting the 500MB is ... inaccurate.
19:50 orbea: could be, will ask
19:50 imirkin_: there's no way it can be accurate
19:50 imirkin_: but there are different levels of assumptions one could be making about stuff
19:51 karolherbst: "uhh sorry for asking, but can you count?" :p
19:51 karolherbst: maybe nouveau allocates too much memory though
19:51 imirkin_: for all i know, nouveau is allocating each texture into a 128KB "large" page
19:51 imirkin_: skeggsb would know
19:51 karolherbst: orbea: is there some kind of texture count?
19:52 orbea: supposodely it counts to 500MB or 128000 textures before clearing the cache, but I dont really understand how it works. Just found the values and made them smaller by 75% :P
19:53 karolherbst: 128000 textures you say
19:53 imirkin_: at 128K per texture, that'd be 16GB of textures
19:53 karolherbst: yep
19:53 karolherbst: but still 4GB after the 75% reduction
19:53 orbea: the values are here https://github.com/loganmc10/GLupeN64/blob/master/GLideN64/src/Textures.cpp#L524
19:54 karolherbst: orbea: try setting the count to 12800
19:54 karolherbst: maybe it makes the thing even better
19:54 imirkin_: orbea: try limiting the number of textures to 16384 (2GB at 128K a piece)
19:55 orbea: will try, takes a bit for the game to allocate enough to show it
20:25 orbea: imirkin_: that works, so if I understand this its hitting the texture limit which seems to end up at 2GB and not the supposed 500MB limit
20:25 orbea: which might indicate teh math for 500M is wrong...
20:25 imirkin_: well
20:25 imirkin_: they have no way of telling how much space a texture takes up
20:26 karolherbst: it is a silly concept anyway
20:27 orbea: yea
20:27 karolherbst: why can't they just check how much vram is "free" on the device? not that it helps with nouveau though
20:27 imirkin_: we don't expose that ext :)
20:27 karolherbst: we should though
20:29 karolherbst: well the bits are there within mesa already afaik
20:34 karolherbst: imirkin_: any idea what needs to be implemented for that? or would that be we expose some nouveau ioctl calls and implement the needed bits in mesa to just call those?
20:36 imirkin_: yeah, something like that
20:36 karolherbst: I am wondering why that isn't part of some basic drm interfac...
20:37 karolherbst: *interface
20:37 imirkin_: questions i try not to ask myself.
20:37 karolherbst: couldn't ttm tell somehow?
20:38 karolherbst: though I have no idea what ttm does anyway
20:39 imirkin_: i'm insufficiently interested. feel free to investigate.
22:11 mupuf: got the patches to solve the LED class problems we identified
22:11 mupuf: but no way I will send them now, waaaayyy too tired
22:11 mupuf:wants to avoid more stupid emails
22:19 imirkin: the harder you try to avoid it, the more likely it is to happen =/