00:27ratherDIfficult: does anyone know if mmiotrace, can log read writes to registers that of shader instructions?
00:33ratherDIfficult: interesting comma
00:34karolherbst: ratherDIfficult: use mmt for doing that
00:40ratherDIfficult: karolherbst: well ok, but the question is with a reason, cause i want to trace the rasterizer alu accesses in the end, so can you answer if mmiotrace without poking in dma pushbufs with valgrind-mmt, can dump shader reg read writes?
00:41ratherDIfficult: or kmmio for instance, i could try someday, but i thought it's just easier to ask
00:51ratherDIfficult: https://bugs.freedesktop.org/attachment.cgi?id=84289&action=edit this one does dump all the stuff, but i dunno how it works, does shader-mmt.demmio parse mmiotrace logs?
00:52karolherbst: a mmt trace traces communication between the nvidia software and the nvidia kernel module. mmiotraces are tracing read/writes from the module to the device
00:53karolherbst: how to actual retrieve information out of it, is the task of other tools, but usually everything should have been captured by the traces
00:53karolherbst: if a tool is missing support for anything, either there should be a new one or the old one improved
00:54karolherbst: but with demmt you should be able to retrieve the binaries the gpu cores are running
00:54karolherbst: so there also should be reg read/writes
00:57ratherDIfficult: so again, does mmiotrace without mmt is capable of capturing shader alu writes to registers?:) i just want the regs to be shown
00:59ratherDIfficult: the question is because, the fixed function rasterizer unit never sends the alus it performs via pusbhuf or whatever you call it a command buffer, as its fixed function , but it accesses alus of simd units that are shared with it, i wonder if mmiotrace can capture accesses to those alus?
01:04ratherDIfficult: i belive the answer is no, or i am afraid it is, because hakzam writes something about fifo methods internal to the gpu, that won't communicate over pcie or mmio
01:18karolherbst: ratherDIfficult: everything which is done inside the gpu can't be traced
01:23pmoreau: RSpliet: Well, in case of fire in your box / appartment, just call the G94! ;)
01:26pmoreau: RSpliet: I don't remember being that loud though. Is it while reclocking or even at default perflvl?
01:26pmoreau: s/remember/remember it
01:29ratherDIfficult: karolherbst: of course they can be traced if you underclock the gpu to 1hz, and just read all the alu regs manually, that mmt has learned, it is just rather complex and painful
01:34ratherDIfficult: ignore that it was stupid idea, how to read them than, well karolherbst: is it that gpu can not write to mmio registers at all, but only reads them?
01:37karolherbst: ratherDIfficult: ? maybe you should read up about what mmio is?
01:37ratherDIfficult: its a memory mapped register
01:39ratherDIfficult: it can be programmed via dma to the gpu
01:39karolherbst: read up about mmio please
01:39ratherDIfficult: ouh come on dude!
01:40karolherbst: who does say it is a register?
01:40karolherbst: it is more generic than that
01:41karolherbst: basically mmio handles all I/O between a cpu and a device
01:41ratherDIfficult: ouh right
01:42karolherbst: and the devices can somehow decide what they return on a read, or what they do on a write
01:42karolherbst: nobody guarantees you, that a write will write a value into the adress you are writing too
01:42karolherbst: the value can be differe with a read, or the value doesn't change at all
01:44karolherbst: so it's not like you can just read "registeres" out. If there are no mmio adress ranges to do that, you are out of luck
01:45karolherbst: and then there are several types of "registers" do you mean core registers? Or what you would call registers on embedded devices? Or entire different type of registers?
01:47ratherDIfficult: not quite sure, some sort of flip-flops or what were they, gpu internal registers i meant, but i see what you mean, yeah out of luck infact indeed, its better to redesign the rasterizer from scratch
01:47karolherbst: it depends on what you can access
01:48karolherbst: you can check the rnndb stuff what each mmio "reg" is for, but I somehow doubt that you can just read the internal state out of the gpu
01:48karolherbst: usually the gpu has high control about what you can actually read out through mmio
01:48karolherbst: and mmio "reg" just means a address you can read/write from
01:51ratherDIfficult: yeah i doubt too, it's perhaps you know better if it is possible to halt or pause the gpu, i dunno playing with some interrupts or whatever, i dunno myself
01:53karolherbst: ratherDIfficult: a gpu isn't as low level as a tiny arm board or what so ever
01:54karolherbst: but maybe it is possible and maybe it is not, I don't know what we can do with a nvidia gpu, so maybe, maybe not
01:56karolherbst: there should be a way to pause at least some parts of the gpu
01:56karolherbst: like if you want to do memory recklocking you have to pause the fb parts for some time at least
01:57karolherbst: and you can put the gpu into an error state witch doing some wrong mmio writes
01:57karolherbst: where all reads just become 0xff
02:03ratherDIfficult: ok, very thoughtful, with a scheduler stuff could be preempted, ok do you know what does nvapeek?
02:21ratherDIfficult: karolherbst: well complicated, its more like 50 50 if the rasterizer will preempt too, but, messing with the command buffer to halt the execution should be reasonably slow compared to how fast rasterizer progresses forward, when finally halted, it might had reused some registers allready, and info is lost, shader though should be able to read the state back
02:26karolherbst: ratherDIfficult: nvapeek does read mmio addresses
02:30ratherDIfficult: karolherbst: ok, but according to your theory, it seems there is no possibility to know what arithmetic operations rasterizer performed imo, cause it seems like alu regs are just some fixed regs
02:31karolherbst: with mmio you can't look into inner state
02:32karolherbst: you only know what you put into the device and what you can read out
02:32karolherbst: so if there is a way to read that out, you can
02:32karolherbst: if the way is unknown to use, you can figure it out how to read it out
02:33karolherbst: every address has it's own purpose, some are easier to figure out, some harder
02:34ratherDIfficult: yeah but i can read the the register what rasterizer filled in with a shader code that was preempted with a scheduler, i.e real gpu registers, but dunno how to get alus identified
02:35ratherDIfficult: it performs (rasterizer) some min max and arithmetics, i belive they work just so that they do not go through the instruction decoder evern, and just even probably on shaders i dunno how they are used, probably a reg that never changes like const
02:51ratherDIfficult: http://devblogs.nvidia.com/parallelforall/cuda-7-5-pinpoint-performance-problems-instruction-level-profiling/ hmm, they expose that themselves it seems:)
02:52ratherDIfficult: says maxwell and newer, however maybe there is something like instruction register or IR, not sure if it can be read back by default on earlier gpus, i doubt really
03:07ratherDIfficult: https://github.com/polachok/envytools/blob/master/hwdocs/fuc-isa.txt hmm allright, now i understand a bit better
03:08mwk: ratherDIfficult: that link is to a rather outdated fork of envytools
03:09mwk: the current URL for that doc is http://envytools.readthedocs.org/en/latest/hw/falcon/isa.html
03:09mwk: and uh, not sure what you're talking about, I came in mid-discussion
03:10mwk: but fuc/falcon is *not* the main processing power of the GPU, what you're looking for is the CUDA ISA, which is an entirely different thing
03:16karolherbst: mwk: I think he wants to read some core regs after "pausing2 execution somehow
03:16karolherbst: but I somehow doubt this is possible through mmio or executing other shaders at all :/
03:27ratherDIfficult: karolherbst: well i mean just sending some bogus bit to the hw context perhaps instead of bogus mmio value, dunno what it does still, it perhaps freezes the gpu, but anyways i do not find regs where the instructions are held, those are fixed it seems, but i understand them following the docs though
03:28karolherbst: ratherDIfficult: gpus are usually a lot more complicated than CPUs
03:28karolherbst: newest GPUs have over 1k of cores
03:28karolherbst: and 65k regs
03:28karolherbst: and a bunch of hardware to do parallelism in an effective way
03:29karolherbst: it is not like you can just read those regs out
03:29karolherbst: like you can on a CPU
03:30ratherDIfficult: noh, well i can read regs, according to what i read from nouveau driver, but i doubt that i can read opcodes what rasterizer use, so touring machine or mealy fsm:=
03:32ratherDIfficult: karolherbst; there are 124 regs for varyings per thread launch on rasterizer, those would be fairly easily read back
03:33karolherbst: I don't think it is always 124 on each chipset though :/ or is it? I don't know
03:34karolherbst: ohh so you want to start threads and just read the regs out?
03:34karolherbst: and by doing so you want to get stuff, that was written there by "older" threads?
03:35ratherDIfficult: mvc0 comments are such, or something was there in source code commented by calim
03:36ratherDIfficult: but all in all, no alus no fun, but i totally misunderstand how were you able to come so far with the project if you have no such methods to debug
03:39karolherbst: a lot of trying stuff out?
03:39karolherbst: but some mmio regs are really easy to figure out though
03:40karolherbst: so I guess it is mostly starting with the easier bits and going to the more complicated areas later after you gavered some clues
03:40karolherbst: mupuf: there?
03:41karolherbst: I've got some nice graphs for ya
03:54ratherDIfficult: it seems that only way is to read back some pc reg periodically
04:00AndrewR: imirkin_, trace generated ..around 3Mb xz compressed. To where it can be uploaded?
04:00ratherDIfficult: actually holy crap, god knows to which regs the rasterizer would be wired to
04:01koz_: I was looking through the feature matrix, and found only Tegra K1 and Tegra X1. What's the deal with Tegra 4?
04:02glennk: koz_, older tegras are a completely different gpu than any of the other nvidia chips
04:03koz_: glennk: So I'm guessing that Nouveau isn't the driver for them?
04:05ratherDIfficult: hmm actually what about a stack pointer, what this one does?
04:06koz_: glennk: Is there a free software driver for the Tegra 4 if it's not Nouveau?
04:07karolherbst: ratherDIfficult: don't confuse GPUs with CPUs
04:08karolherbst: I don't even know if there is a per thread stack pointer at all?
04:23ratherDIfficult: me neither, confusing info over internet, i doubt that rasterizer uses this sp for threads, data segments for it, but it'd be wonderful if it does...:P:D
04:26AndrewR: imirkin_, https://bugs.freedesktop.org/show_bug.cgi?id=92072
04:33glennk: koz_, "grate" but i have no idea how far that project got
04:33glennk: long obsolete gpu by mobile standards though
04:39ratherDIfficult: karolherbst: perhaps mwk knows if rasterizer launches threads with data segment, I don't have hw yet, and babe is waiting for me
04:58ratherDIfficult: 03:12 < mwk> there are also: MPC <-> MP (processor controller and the actual processor), MPC <-> TEX (texturing unit), MPC <-> CCACHE (code & const cache), MPC <-> ROP (raster output & general data segment read/write access)
05:01ratherDIfficult: karolherbst: really weird, you see the arrows are all of the sudden both ways
05:01ratherDIfficult: as if raster output unit really would consume data segment
05:02pq: hmm, smells like joss...
05:10ratherDIfficult: who's joss?:P
05:22Unei_: Hi man, can any one help with nouveau reclocking?
05:23mlankhorst: wonder why I didn't notice before
05:23ratherDIfficult: ouh heck the ROP is not rasterizer
05:23ratherDIfficult: seems to run after the fragment shader
05:27pmoreau: Unei_: Do you mean by contributing or how to use it / debug some issue with it?
05:27Unei_: I have system with arch linux and intel+nvidia (gtx670mx) i mean how to use
05:29pmoreau: You have to boot with nouveau.pstate=1 to enable the file controlling reclocking
05:29Unei_: Yes i do
05:30pmoreau: Ok, then I need to remember where the file is...
05:30Unei_: The try cat and echo but fails
05:31pmoreau: Are you doing it as root?
05:32pmoreau: There is a file named pstate in /sys/class/drm/card1/device, right?
05:33Unei_: When i use cat to this dir i see posdible freg
05:34pmoreau: What error do you get with echo then?
05:34pmoreau: Mind pasting the result of the cat, as well as the echo command?
05:35ratherDIfficult: pq: why is that you love that joss that much, and who is he, some intelligent man?
05:35Unei_: No error - when try as root but system start to lag
05:36pmoreau: When uplocking, downclocking or both?
05:36pmoreau: And could you please paste the output of dmesg on some webpage and share the link, after doing at least one reclocking?
05:38Unei_: Sory cant now, after work will try again(not at home now)
05:39pmoreau: But did your system lag after a downclock or an upclock?
05:41Unei_: As i know by defoult nouveu use low clock
05:41Unei_: Then upclock
05:42pmoreau: By default, Nouveau uses the clock at which the card boots.
05:43pmoreau: So it depends on generations: Tesla cards boot on mid to high clocks, whereas, you're right, Kepler+ (maybe Fermi) boots on low to lowest clocks
05:46Unei_: When i use echo with root it look like the this command not complite
05:47pmoreau: Oh wait, is it a GDDR5 card?
05:48Unei_: Some problem with gddr5?
05:48pmoreau: Ask karolherbst about his branch, it should fix most issues about reclocking GDDR5 memory (on Kepler at least iirc)
05:48pmoreau: But, almost solved
05:49karolherbst: Unei_: https://github.com/karolherbst/nouveau/commits/gddr5
05:49karolherbst: please test and report back :)
05:52Unei_: Ok will try. Cant now but when come home test it.
07:43qq[IrcCity]: hello. what mean “nouveau 0000:01:00.0: whatever[pid]: failed to idle channel 0xcccc000n [whatever[pid]]” messages?
07:44xexaxo: qq[IrcCity]: gpu lockup (in most of the cases)
07:44qq[IrcCity]: it followed by heating and hitting de-clocking threshold.
07:44qq[IrcCity]: (I set it at 85°C)
07:45qq[IrcCity]: why doesn’t the driver reset it?
07:45qq[IrcCity]: or it tries but fails?
07:45imirkin: AndrewR: thanks, will take a look
07:45imirkin: qq[IrcCity]: there is no "declocking"
07:46imirkin: qq[IrcCity]: nouveau *sucks* at dealing with gpu hangs
07:47qq[IrcCity]: imirkin: whaaat? is hwmon/temp1_max a lie?
07:48imirkin: qq[IrcCity]: it's not a lie, but perhaps you made assumptions about what it does
07:49xexaxo: this cake is a lie!!!
07:49qq[IrcCity]: imirkin: I made assumptions that GPU’s clock is switched to a lower frequency.
07:50imirkin: qq[IrcCity]: there is no reclocking.
07:50qq[IrcCity]: Sep 22 17:34:54 duk kernel: [ 8998.767880] nouveau 0000:01:00.0: therm: temperature (86 C) hit the 'downclock' threshold
07:50imirkin: qq[IrcCity]: that's right... it hit the downclock threshold ;)
07:51imirkin: did it say anything about actually downclocking?
07:51qq[IrcCity]: but the temperature stopped to rise.
07:52qq[IrcCity]: temp1_max = temp1_input = 85000
07:53qq[IrcCity]: although console is dead anyway ☹
07:55qq[IrcCity]: imirkin> qq[IrcCity]: nouveau *sucks* at dealing with gpu hangs // OK, why is it? CPU hasn’t actually necessary levers?
07:55karolherbst: qq[IrcCity]: what gpu do you have?
07:56qq[IrcCity]: I have GeForce 8600 GTS (rev a1).
07:56imirkin: qq[IrcCity]: because it's hard to debug, we don't have the proper docs, and generally a giant pain to work on
07:56karolherbst: qq[IrcCity]: the temp will stop to raise at some point anyway
07:56imirkin: qq[IrcCity]: so not exactly a lot of volunteers
07:57karolherbst: I think I really will implemet overclocking. Card running +85MHz overcklocked and still at 65°C :/
07:58karolherbst: imirkin: anyway I think downclocking isn't that hard on cards with cstate
07:58karolherbst: we just need to clock to a cstate with a lower voltage
07:58karolherbst: and if it's not better 1 or 2 seconds later we drop again a little
07:59karolherbst: I noticed something
07:59qq[IrcCity]: imirkin, what happens to the card when device is reset (e.g. via /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/reset)?
07:59karolherbst: imirkin: do you know these +3/+5 values in sensors?
07:59imirkin: qq[IrcCity]: try it.
08:00qq[IrcCity]: I did. nouveau doesn’t recover from it,
08:00qq[IrcCity]: but the box still runs.
08:00imirkin: qq[IrcCity]: so now you know :)
08:00qq[IrcCity]: why nouveau doesn’t recover from a reset GPU?
08:02karolherbst: maybe nobody really knows how to implement it for every chipset, wanna help?
08:02pmoreau: qq[IrcCity]: You reset the card state while the driver is doing stuff
08:02karolherbst: pmoreau: is this reset on a bus level?
08:03pmoreau: It doesn't go through Nouveau for sure
08:03qq[IrcCity]: pmoreau, so?
08:03karolherbst: okay, that's a bit brutal then
08:03karolherbst: qq[IrcCity]: nouveau doesn't know
08:04qq[IrcCity]: why don’t implement certain “nouveau_reset” that would tristate the driver, do the bus reset, and then activate the driver anew?
08:04karolherbst: qq[IrcCity]: wanna help?
08:05qq[IrcCity]: karolherbst: yes, I do. should I go to github or?
08:05pmoreau: qq[IrcCity]: You could manually do that with a script: exit X, unload Nouveau, PCI reset the card, reload Nouveau, restart X
08:06karolherbst: qq[IrcCity]: then I think the blob has to be traced for that, because it's not that trivial to recover from an error state without messing up X and what so ever
08:06qq[IrcCity]: I can’t unload a driver in use by fbdev (at very least).
08:06karolherbst: qq[IrcCity]: unbind vtconsole
08:06qq[IrcCity]: moreover, Xorg fails to exit while GPU is locked up.
08:07karolherbst: usually you need to wait a moment
08:07pmoreau: Don't ask him nicely ;)
08:07qq[IrcCity]: it’s possibly a sort of solution, but it requires restarting software.
08:07pmoreau: But. yeah, would be so much better if you wouldn't need to reset the card. :-)
08:07qq[IrcCity]: anyway I’m going to test it.
08:08karolherbst: the thing is, nobody really knows how the blob does it (or does anybody?)
08:08karolherbst: so it will require a lot of blob RE
08:08mwk: karolherbst: basically a lot of violence
08:08karolherbst: mwk: :)
08:08pmoreau: There are some patches from sooda_ (iirc?) on improving the situation a bit
08:08karolherbst: undervolting the card while on full load should help? :D
08:09karolherbst: would be the easiest way to trigger the card into an error state
08:09sooda_: huh wat
08:09karolherbst: at least for me this is one mmio write
08:10karolherbst: anybody familiar with the temp sensors? Maybe I will do some work for my gpu for this
08:11qq[IrcCity]: karolherbst, https://www.kernel.org/doc/Documentation/thermal/nouveau_thermal
08:11pmoreau: sooda_: Your patch serie about pushbuf error handling
08:11sooda_: ah yes
08:12qq[IrcCity]: karolherbst> qq[IrcCity]: unbind vtconsole // do what?
08:12sooda_: recovery is also being worked on, not by me tho
08:12pmoreau: Nice :-) Any idea when we might see some patches?
08:12sooda_: it is a really complex procedure indeed
08:13qq[IrcCity]: sooda_, in which scenario should this new recovery help?
08:13sooda_: cant say for sure :/
08:13pmoreau: How is your serie going on btw?
08:13karolherbst: qq[IrcCity]: /sys/class/vtconsole/vtcon0/bind
08:13karolherbst: I think 0 means bind and 1 unbind?
08:13karolherbst: anyway, this has to be flipped
08:13sooda_: qq[IrcCity]: it's more detection thab handling unfortunately
08:13pmoreau: karolherbst: I think you echo 1 to bind, 0 to unbind
08:14karolherbst: my intel is 0
08:14karolherbst: orr wait
08:14karolherbst: don't know, it has to be the other value anyway
08:14sooda_: pmoreau: hm, i think it was left as-is for a while, when i answered some ben's questions. should rebase on the newest reworked stuff
08:16sooda_: off ->
08:16pmoreau: Okay, thanks for the update!
08:19sooda_: (i've polished those a bit internally, and tested for some cases)
08:20qq[IrcCity]: /sys/class/vtconsole/vtcon0/bind = 0 and apparently no Xorg process, but still “nouveau 1462272 1”. any idea?
08:21mlankhorst: lsof /dev/dri/* ? killall pulseaudio?
08:23qq[IrcCity]: mlankhorst, no processes bound to /dev/dri/ and no pulseaudio.
08:23karolherbst: ohh mybe vton1
08:24pmoreau: And probably need to modprobe -r or rmmode drm and i2c before removing nouveau
08:24mlankhorst: can't do that
08:25pmoreau: is it the other way round?
08:26qq[IrcCity]: karolherbst, now 0, thanks.
08:34qq[IrcCity]: nouveau reloaded, but vtcon1 and /dev/fb0 both disappeared and «echo 1 |sudo tee /sys/class/vtconsole/vtcon0/bind» has no visible effect anyway.
08:35qq[IrcCity]: I forgot which modules must be activated for the console (accidentally flushed lsmod’s output from the terminal).
08:41qq[IrcCity]: and now without /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/hwmon, damn! it parent exists, but no “hwmon”.
08:43ratherDIfficult: ouh i went to see a babe, so what is the most convenient way to see what instructions rasterizer uses on nvidia gpu?:):):)
08:45ratherDIfficult: ou read the pc register to and bang the metal with interrupts, but i want regs to in that case
08:52ratherDIfficult: but first of all let's find out if possibly program counter aka instruction counter (i dunno why two names) holds the instruction with operands?
08:57ratherDIfficult: so the issue is anyways to know the instruction opcode, some engine must read it somewhere into pc reg, and it might as well still be in vram where it reads it
08:59qq[IrcCity]: oops: Sep 22 18:29:04 duk kernel: [12245.983237] nouveau: probe of 0000:01:00.0 failed with error -16
08:59qq[IrcCity]: it failed to find the hardware. what to do?
09:03imirkin: 16 = EBUSY
09:03imirkin: probably some nv_wait timed out
09:05qq[IrcCity]: imirkin: retried « rmmod nouveau; modprobe nouveau », with the same outcome.
09:05qq[IrcCity]: it really waits several seconds.
09:06imirkin: yeah, probably waits for the GPU to be idle, and then gives up
09:06qq[IrcCity]: i.e. the bus reset doesn’t do the job?
09:07qq[IrcCity]: how can UEFI do it, indeed?
09:09imirkin: runs the option rom
09:09imirkin: i bet if you load nouveau with config=NvForcePost=1 it'll work
09:10qq[IrcCity]: imirkin, yes.
09:11ratherDIfficult: or lets put it in another way, what rasterizer instructions pc instruction holds, those from command buffer that i allready know from code, or those other fixed function underlying functionality instructions?
09:12qq[IrcCity]: interesting: the console recovered (but fonts).
09:14qq[IrcCity]: not actually recovered, but there is a signal.
09:17qq[IrcCity]: ultimately, a crash. possibly I was confused with these vtcon0/vtcon1 binding, and created an unviable configuration.
09:23qq[IrcCity]: karolherbst, the experiment demonstrated that driver reload manupuations are error-prone, dangerous, and disrupt userland software. what about doing it with a working driver?
09:26pmoreau: It would need a ton of RE, and I guess developers prefer to work on some missing features like reclocking, fixing bugs, supporting newer versions of OpenGL, etc.
09:27qq[IrcCity]: pmoreau, a ton of what?
09:27pmoreau: And well, if Nvidia is going to improve driver recovery, why would someone want to work on it. :-)
09:27pmoreau: RE = Reverse Engineering
09:28qq[IrcCity]: again, I saw a signal after resetting and loading with config=NvForcePost=1, but virtual console driver was confused due to unbinding.
09:29pmoreau: mupuf has a script for reloading Nouveau, let me find it now that I'm at home.
09:29qq[IrcCity]: we should do just what I did, but without messing with over-lying drivers.
09:33pmoreau: qq[IrcCity]: I think this should be the one: https://phabricator.pmoreau.org/P22
09:34pmoreau: Anyone using Reator or can I reboot it?
09:34karolherbst: qq[IrcCity]: I usually poweroff the card before loading the driver again
09:35karolherbst: pmoreau: I think the maxwell card prevents shutdown
09:35karolherbst: or something else
09:35karolherbst: anyway, after "halt" with the current gpus it doesn't seem to work always
09:35pmoreau: Can you ssh Reator or does it only timeout for me?
09:36karolherbst: if somebody did halt then ssh times out
09:36qq[IrcCity]: karolherbst, hitting /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/reset was enough. in my case.
09:36karolherbst: qq[IrcCity]: yeah it depends on how messed up the card is
09:36qq[IrcCity]: possibly even that wasn’t necessary.
09:37karolherbst: I always turn off the card when switching to/from the blob
09:37karolherbst: pmoreau: I think you need to hard reset
09:38karolherbst: maybe check the log and check what happend
09:38karolherbst: journalctl --boot -1 | tail ;)
09:38soreau: pmoreau: what do you mean by driver recovery?
09:40pmoreau: soreau: If the GPU lockups, throws some exceptions, rather than hanging the whole computer, try to reset some parts of the card or "solve" the interrupt
09:41pmoreau: karolherbst: Maybe it was just **OFF**... --"
09:42karolherbst: pmoreau: mhhh
09:42karolherbst: did you check on the page?
09:43soreau:wonders if nvidia will ever make a habit of releasing hw specs
09:43pmoreau: I wouldn't be against!
09:48pmoreau: skeggsb: Ping http://lists.freedesktop.org/archives/nouveau/2015-September/022308.html It should be a more acceptable patch than PCI-resetting the card. :-)
09:48qq[IrcCity]: are here Linux architecture experts? a potential problem: fbdev (or else) tries to access “nouveau” during reset, and such requests must be postponed until driver was ready. does a ready-to use mechanism for it exist in the kernel space?
09:49pmoreau: mwk: ping Would you prefere me to rebase everything and get proper commits before a final review?
09:49qq[IrcCity]: of course the reset can be done synchronously and lock all the system up, but it would be mauvais ton.
10:21Unei: Hello again, now i try again nouveau reclock it work, but AC: core 324 MHz memory 2800 MHz
10:22pmoreau: Are you using karolherbst's branch?
10:22pmoreau: But well, if defaults work
10:23Unei: just try again when second adapter on
10:23Unei: if it turn of i stuck
10:24karolherbst: 2800 MHz doesn't sound like kepler gddr5 anyway
10:24Unei: i whant to try karolherbst's branch but have little experiens in bulding pacage
10:25karolherbst: that's a pretty slow one :/
10:25karolherbst: usually I thought gddr5 clocks are aroung 3500+
10:26karolherbst: well okay, seems like it si really gddr5
10:26RSpliet: I'm more surprised about the core clock myself
10:26karolherbst: but my patch also fixes stuff for clocks above 2400, so it should be fine
10:26karolherbst: Unei: do you have voltage error in dmesg?
10:26karolherbst: something with -22?
10:26Unei: how to check?
10:26RSpliet: karolherbst: laptop cards clock lower though, that makes sense
10:27karolherbst: RSpliet: mine is at 4000
10:27karolherbst: and it "just" a 770M
10:27karolherbst: and GK106
10:27RSpliet: I didn't say it makes a lot of sense
10:27RSpliet: but it makes sense nonetheless
10:27karolherbst: yeah I am just a little bit suprised
10:27Unei: [ 254.179693] nouveau E[ CLK][0000:01:00.0] failed to raise voltage: -22 [ 254.179701] nouveau E[ CLK][0000:01:00.0] error setting pstate 2: -22
10:27karolherbst: yeah as I thought
10:27karolherbst: a lot of kepler cards have troubles there
10:27karolherbst: with 0a it is fine
10:28karolherbst: but higher pstates
10:28karolherbst: not so much luck
10:28karolherbst: Unei: try to go to 0a first
10:28karolherbst: then 0f
10:28karolherbst: core clock should be higher that way
10:28karolherbst: RSpliet: basically nouveau doesn't generate enough values for the voltage table
10:29karolherbst: and for 0f voltages above the upper bound are sometimes requested
10:29karolherbst: so it just fails, because it doesn't find a value in this table
10:30Unei: 07: core 270-405 MHz memory 648 MHz 0a: core 270-601 MHz memory 1600 MHz 0f: core 270-614 MHz memory 2800 MHz AC DC * AC: core 600 MHz memory 2800 MHz
10:30karolherbst: yeah as I thought
10:30Unei: ths its work
10:30karolherbst: the 14 MHz are pretty unimportant for you, so you are a bit lucky
10:30karolherbst: Unei: so you compiled my branch and are using the module now?
10:30Unei: sory now i not do it
10:31karolherbst: it could be, that for your clock it may be fine
10:31karolherbst: Unei: or is 0f sometimes unstable for you?
10:32karolherbst: while actual using the card I mean
10:32imirkin_: mwk: do you remember having to do anything special to get gmem to work? esp redops?
10:32imirkin_: mwk: i'm failing on both fermi and kepler
10:32imirkin_: getting mp error 0x10
10:34Unei_: have big lag
10:34Unei_: somthing fails
10:36karolherbst: Unei_: which kernel are you running?
10:37Unei_: 4.2.0-4 arch
10:37karolherbst: ohh okay, that should be fine
10:37karolherbst: I will give you instructions when your machine is up again
10:39ratherDIfficult: http://www.google.ne/patents/US8325184 in this patent alu instruction from rasterizer are decoded , so they go through program counter
10:42karolherbst: ratherDIfficult: what do you want to achive anyway?
10:43Unei: yes it happen when i try to 0a > 0f
10:44karolherbst: that makes somehow sense
10:45Unei: now i am up
10:46karolherbst: Unei: k
10:47karolherbst: git clone -b gddr5 https://github.com/karolherbst/nouveau.git
10:47karolherbst: and then go into the directory
10:47karolherbst: and verify with git log, that the commit on top is pll/gk104: fix PLL instability due to bad configuration with gddr5
10:50Unei: sory how can i verify it?
10:50karolherbst: "git log"
10:54ratherDIfficult: karolherbst: was reading it through, not a goot match of a patent, well i wanted to dump all the rasterizing logic of nvidia gpu to some buffer, so that it would include also the alu operations performed on the vertices/edges
10:54Unei: haven't this command somthing not installed
10:54karolherbst: Unei: did the git clone worked?
10:55karolherbst: mhh seems like we hve to start at 0
10:55karolherbst: okay, that's fine usually
10:55Unei: yes it work
10:56karolherbst: ohh okay
10:56karolherbst: did you do "cd nouveau" ?
10:56Unei: no done
10:56Unei: pll/gk104: fix PLL instability due to bad configuration with gddr5
10:56karolherbst: so this is at the top? nice
10:56karolherbst: then we can move forward
10:56ratherDIfficult: karolherbst: this maybe impossible, though mwk has not said anything yet
10:57karolherbst: cd drm; make -j 8
10:59Unei: *** No rule to make target 'modules'. Stop.
10:59karolherbst: ohhh, mhhh
11:00karolherbst: Unei: complete output?
11:00Unei: make: Entering directory '/usr/lib/modules/4.2.0-4-ARCH/build' make: *** No rule to make target 'modules'. Stop. make: Leaving directory '/usr/lib/modules/4.2.0-4-ARCH/build' Makefile:18: recipe for target 'modules' failed
11:01Unei: something wrong with my cernel
11:01ratherDIfficult: karolherbst: i read a little bit more from internet, this patent is not clear enough, it states that both ways are possible to be precise..
11:01karolherbst: does ARCH have seperated source packages?
11:01karolherbst: if so, you need to install the kernel dev package
11:01ratherDIfficult: ouh right, then chech it out from aru
11:02Unei: then it was 4.3
11:02karolherbst: Unei: you should be able to install the dev package to your current kernel though
11:04qq[IrcCity]: is «nouveau 0000:01:00.0: fb: trapped read at 0020014100 on channel 1 [0fcae000 DRM] engine 0c [SEMAPHORE_BG] client 08 [PFIFO_READ] subclient 00  reason 0000000f [DMAOBJ_LIMIT]» dangerous? I have a lot of such things, sometimes several in three seconds.
11:06Unei: https://aur.archlinux.org/packages/linux-mainline/ this?
11:07karolherbst: Unei: please do "ls -k /usr/lib/modules/4.2.0-4-ARCH/build"
11:08pmoreau: Unei: pacman -S linux-headers should do it
11:08karolherbst: I meant -l, but okay
11:08pmoreau: I was wondering what this k flag was for ls :D
11:08karolherbst: but this is strange
11:09mwk: pmoreau: would be nice, yes
11:09Unei: installing headers
11:10pmoreau: Ok, will do that in an hour or so.
11:10pmoreau: mwk: Do I try to push force on the existing requests or open new ones?
11:11mwk: pmoreau: push force
11:12Unei: fatal error: soc/tegra/pmc.h: No such file or directory
11:15Unei: mb need reboot after install headers
11:15karolherbst: don't think so
11:15karolherbst: something is just messed up
11:16karolherbst: kernel-headers isn't everything
11:16karolherbst: you actually need the kernel sources, too
11:17Unei: ok will try kernel form aur
11:18karolherbst: Unei: I don't think you have to
11:19karolherbst: Unei: please do uname -a
11:20Unei: Linux gt60 4.2.0-4-ARCH #1 SMP PREEMPT Fri Sep 11 11:39:32 CEST 2015 x86_64 GNU/Linux
11:20karolherbst: Unei: what is the version of your installed "linux" package?
11:20karolherbst: I bet your package just got updated and removed the old stuff
11:21karolherbst: so you just need to boot into the new kernel
11:21Unei: i have utdated linux package
11:22karolherbst: which version is installed?
11:22karolherbst: if the isntalled version doesn't match your running version, you can't compile modules
11:23Unei: dont know how to see what wer now but can now update it
11:24Unei: just about 2 mounth on linux dont know many things...
11:27karolherbst: you will get used to it eventually
11:28pmoreau: linux-headers should be enough to compile Nouveau, I don't have any other packages installed that could bring headers or sources, and I can still compile Nouveau
11:29karolherbst: from whom can I add tested-by for the gddr5 patch? :D
11:29karolherbst: pmoreau: his modules/$kernel/module symlink pointed to something stupid
11:29karolherbst: there was just vmlinux in
11:33karolherbst: Unei: so, what does uname -a say? :D
11:33ratherDIfficult: i dunno if i understnd right from that text, but it sounds like program counter can not only read from memory but also from something like register file on nvidia
11:34Unei: Linux gt60 4.2.1-1-ARCH #1 SMP PREEMPT Tue Sep 22 06:57:07 CEST 2015 x86_64 GNU/Linux but cant
11:34karolherbst: can you compile nouveau now?
11:34Unei: same error
11:34karolherbst: also 4.2.0-4?
11:36Unei: no not same
11:36karolherbst: ls -la /usr/lib/modules/
11:37Unei: drwxr-xr-x 1 root root 66 сен 22 21:25 . drwxr-xr-x 1 root root 107212 сен 22 21:25 .. drwxr-xr-x 1 root root 380 сен 22 21:25 4.2.1-1-ARCH drwxr-xr-x 1 root root 42 сен 22 21:25 extramodules-4.2-ARCH
11:38karolherbst: doesn't look too bad
11:39karolherbst: ls -a /usr/lib/modules/4.2.1-1-ARCH
11:39Unei: /home/alex/git/nouveau/drm/nouveau/include/nvif/os.h:33:27: fatal error: soc/teg
11:40karolherbst: wait a sec
11:41karolherbst: there is no soc/teg in the ARCH package
11:41karolherbst: "libre" patch or what is happening?
11:41karolherbst: have to investigate
11:43Unei: cant understand...
11:44karolherbst: the soc/tegra stuff doesn't seem to be there
11:45karolherbst: pmoreau: any idea?
11:45pmoreau: No... I'm having a look
11:46karolherbst: I know 4.1 has it
11:46karolherbst: did it change for 4.2?
11:46karolherbst: but then again: https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/include/soc/tegra?id=refs/tags/v4.2.1
11:48karolherbst: yeah that is fine
11:48karolherbst: but you need include/soc/tegra/pmc.h
11:48Unei: im now compiling new kernel
11:48Unei: just use find in terminal
11:49Unei: other libs must be there to i hope
11:49karolherbst: should be fine
11:49karolherbst: it would have failed with another header
11:50pmoreau: I didn't find a tegra flag in their config of the kernel
11:51pmoreau: Shouldn't there be one?
11:51karolherbst: mhh not sure
11:51karolherbst: shouldn't be that header be isntalled anyway?
11:51karolherbst: but the header isn't in the file list
11:51karolherbst: this is just plain wierd
11:53pmoreau: And they are copying the headers from the include folder of the kernel, and not removing tegra. So it wasn't there in the first place I guess
11:54karolherbst: but why mhhh
11:54karolherbst: Unei: I hope you didn't mess with it? :D
11:55karolherbst: pmoreau: maybe some sort of deblobbing patch?
11:55pmoreau: I don't have it either
11:55pmoreau: Usually Arch isn't deblobbing
11:55karolherbst: pmoreau: how did you compile nouveau again? :D
11:55RSpliet: having Tegra includes on an x86(_64) machine isn't very sensible, requirements on it should be guarded
11:56karolherbst: Unei: okay, do this
11:56pmoreau: karolherbst: I also have a clone of drm-next ;)
11:56karolherbst: Unei: open drm/nouveau/include/nvif/os.h
11:57karolherbst: remove the "#include <soc/tegra/pmc.h>" line
11:57karolherbst: should be fine
11:57karolherbst: pmoreau: I see
11:58pmoreau: But I did use the stock kernel in a not to distant past, and it worked
12:00Unei: yes it start to work
12:01karolherbst: Unei: insmod nouveau/nouveau.ko
12:01karolherbst: as root
12:01karolherbst: so use sudo before it
12:02Unei: insmod: ERROR: could not insert module nouveau/nouveau.ko: File exists
12:03karolherbst: ohh nouveau is already loaded?
12:03karolherbst: then unload nouveau first
12:03qq[IrcCity]: … and unbind consoles?
12:04Unei: i have 2 adapters
12:04Unei: or i cant understand some words...
12:04qq[IrcCity]: Unei, speak Russian?
12:05Unei: how to да
12:05karolherbst: Unei: doesn't rmmod nouveau work?
12:06Unei: rmmod: ERROR: Module nouveau is in use
12:06karolherbst: pmoreau: will make install work on ARCH without problems?
12:06karolherbst: maybe you tell him how to install a kernel module a nice way :)
12:07qq[IrcCity]: oops, that link, with a scrpit.
12:07karolherbst: qq[IrcCity]: that won't work
12:07karolherbst: because Unei doesn't want to unload intel as well
12:08karolherbst: also X claims the nvidia card
12:08karolherbst: installing the new module is much easier
12:08karolherbst: and it will work after reboot immediatly
12:08karolherbst: pmoreau: please help him :)
12:08qq[IrcCity]: maybe reboot would be easier?
12:09karolherbst: qq[IrcCity]: he has to install the module first
12:09karolherbst: but I don't know how to do that on Arch the best way
12:09pmoreau: What I do is mv the stock kernel module to nouveau.ko.old, and symlink the build one to nouveau.ko
12:09qq[IrcCity]: good try.
12:10pmoreau: Really handy when you test different patches: just make in Nouveau, and load, it will pick the newly built module :)
12:17qq[IrcCity]: when I started to think about a biult-in reset and even read something about SOFTIRQ (as a mean to postpone requests to the driver), all visible glitches ceased.
12:18pmoreau: I'm out of idea why soc/tegra isn't there... It is in the archive they use as source, none of the patch remove it, they copy the whole directory linux, never explicitly remove the tegra one, and still, it's not there...
12:19qq[IrcCity]: pmoreau: maybe makefiles mess with .h paths?
12:20qq[IrcCity]: I mean what is specified with -I
12:20pmoreau: Could be, idk
12:25karolherbst: Unei: I hope you tried out the new module yet ;)
12:26qq[IrcCity]: I detest Web–IRC gates. it obscures what happens to the client.
12:31imirkin_: mwk: any idea what PGRAPH.MACRO.WDCNT is?
12:47karolherbst: imirkin_: wide counter?
12:47imirkin_: karolherbst: thanks.
12:48karolherbst: maybe word count?
12:48karolherbst: but I gues cnt is count :)
12:49imirkin_: karolherbst: did you name the register in envytools?
12:49karolherbst: I am just guessing
12:49imirkin_: then let the one who named it answer :p
12:49imirkin_: i can also guess. but i'd like to know exactly.
12:49karolherbst: ohh okay
12:52karolherbst: well it seems like Unei doesn't want to try it anymore :( sad
12:54qq[IrcCity]: does anybody know what means the «fb: trapped read… » crap?
12:55karolherbst: wut, GTX 980 in laptops? :/
12:55karolherbst: not the M version, the desktop version
13:20imirkin_: pmoreau: mind getting me a glxinfo -l -s from your G96 against mesa 11.0?
13:20pmoreau: Well, right now I do. :)
13:21pmoreau: I am rebasing my pull requests for envytools
13:21pmoreau: But, once I'm node, I'll do it :)
13:21imirkin_: yeah, not urgent
13:33mwk: imirkin_: watchdog counter
13:34mwk: how many instructions / cycles / whatever to let the macro run before it goes boom
13:34imirkin_: mwk: ah ok. that makes more sense
13:35imirkin_: mwk: did you ever get gmem working in graphics pipeline perchance?
13:35mwk: I don't think I've ever tried
13:35imirkin_: mwk: all of my attempts end up in tears. i might try blob ctxsw fw
13:35mwk: I certainly don't remember antyhing about it
13:35mwk: maybe some missing method? shader header flag?
13:36imirkin_: mwk: possible, but i'm trying really hard to do the exact same thing the blob is doing
13:36imirkin_: mwk: and they recently published docs for shader headers
13:37imirkin_: mwk: the missing method is the most promising line of investigation... but... there are a lot of them
13:38mwk: ah, crap, it's nvc0
13:38imirkin_: yeah, nvc0 has that GLOBAL_BASE thing
13:38imirkin_: kepler lost it, from the looks of it
13:41imirkin_: i actually don't have a kepler1 though... i've only tested on fermi and kepler2
14:46karolherbst: imirkin_: you know how I told you pre 4.0 doesn't work for me? Maybe I was also effected by this? https://bugs.freedesktop.org/show_bug.cgi?id=72180
14:46imirkin_: karolherbst: maybe.
14:46karolherbst: will try to revert and test
14:52karolherbst: I am kind of searching for a new test. I am not sure how much I will do for the pcie stuff on fermi, so I rather fix/improve something on Kepler
14:56karolherbst: maybe I try to get clock gating working on my card? will be fun I guess
15:08pmoreau: mwk: I finished rebasing both pull requests.
15:09pmoreau: mwk: The EVO will have one one-line commit that won't apply after merging the renaming request, but it is easy to fix.
15:35wayne: hi. how do i donate money to the nouveau project?
15:35wayne: just saved me a headache--want to show my thanks
15:35imirkin_: wayne: you can't, there's no legal nouveau project entity
15:36wayne: :( mmkay
15:37imirkin_: closest is probably the x.org foundation... not 100% sure they accept donations though
16:09karlmag: Thinking out a bit loud, I guess one could help the nouveau project (indirectly) by donating hardware to some developer. (No, I'm not one, and only related to the project by being a user of it)
16:10karlmag: Essentially giving some poor bastard more work ;-) :-P
16:11glennk: unless its some really hard to find hardware, most of it can be bought off ebay for less money than a developer makes in about an hour
16:12karlmag: glennk: still, one could pay for it and have it shipped to said developer to be helpful, possibly?
16:12glennk: developer time is the item in short supply, anything you can do to extend that time or make its use more effective is more useful
16:12karlmag: that is true
16:13karlmag: if you pay for that hour instead of the developer, that would (at least in theory) be helpful.
16:15glennk: most devs have more cards than machines to put them in
16:16karlmag: of course, if one where in a position to hire a developer for a shorter or longer period, that would obviously be more helful wrt being made available.
16:16karlmag: glennk: I know that problem - and I'm not even a developer :-P
16:17glennk: there may be some lower hanging things where one can help (typically by spending a bit of time to save on developer time)
16:17karlmag: time and (physical) space is often in high demand and short availability.
16:18glennk: one example may be going through a basic bug report and distilling it down to a minimal trace - may take a few hours but saves the developer having to do that task
16:19karlmag: I hope to end up in a position where I can be at least of a bit of help. Right now the "dependency chain" (in lack of a better description) for me to get there a bit unfun.
16:19imirkin_: karlmag: step 1: learn how to code? :)
16:21karlmag: imirkin_: heh... well... that would be helpful too I suppose, but it's more of a "get crap out from electronics-/computer lab-to-be" that needs attention first anyway. :-/
16:21imirkin_: no matter what it is, the first step is always the hardest
16:22karlmag: Anyone wanting a huge pile of old SUN, HP, SGI, etc *nix computers? :-P (That's a big and hard step :-P )
16:23imirkin_: it hurts to throw those out :)
16:23karlmag: heavy step at the very least..
16:23imirkin_: coz, you know, SGI used to be awesome
16:23karlmag: that is true
16:24imirkin_: what do you have? indy's? or O2's?
16:24glennk: shipping an sgi is a major task
16:24imirkin_: even if it's to the curb
16:24karlmag: both IIRC
16:24glennk: any sort of moving tends to induce injury
16:24imirkin_: hope no e10k's lying around in there
16:25imirkin_: those might be permanent
16:25karlmag: heh.. no
16:25glennk: no power challenges either?
16:25karlmag: I "only" have 3-4 SGIs laying about I think
16:25imirkin_: along with their beautiful 20" monitors?
16:26karlmag: I think I have one, actually
16:26karlmag: A while since I did anything like an inventory of that stuff
16:26glennk: reminds me of seeing quake software rasterized on a 24" on an alpha in the 90s
16:27karlmag: probably have 8-10 HPs and probably a couple dozen SUNs..
16:27karlmag: most of them not *that* big, but it adds up
16:28karlmag: SS1 through 20, a few of the lunchbox types and a couple bit later
16:28karlmag: And one sparkserver thing.. that thing is huge
16:28glennk: i chucked out a rs6000 a few years ago, i did wonder if it used depleted uranium in its construction
16:29glennk: though i guess it using aix meant users must be expected to try jumping on it
16:29karlmag: that sparc server I believe weighs (at least according to the manual) about 99kg :-P
16:29glennk: ohh, thats about the weight of a vax hard drive :-)
16:30glennk: 3 phase motor with belt drive
16:30glennk: 1GB !
16:32imirkin_: glennk: not *if* it used depleted uranium, but how much ;)
16:32glennk: i did get an offer for a cray 1 for 150CAD once, but shipping and oil was not included
16:33glennk: (neither was the false floor and 20kW air conditioning required for operation)
16:36karlmag: d uranium, but how much ;)
16:36karlmag: failed paste.. :-P
16:36karlmag: fun with spaces in URLS, but.. :-P
16:36karlmag: classic picture
16:36karlmag: SUN 670MP
16:37karlmag: I believe that monitor is a 20"
16:38karlmag: Anywho... sorry about derailing the OT discussion here.
16:38karlmag: (on topic that is)
16:42qq[IrcCity]: where should I get sources for Linux 4.3? http://nouveau.freedesktop.org/wiki/ doesn’t show that link, at least superficially.
16:44imirkin_: qq[IrcCity]: http://www.kernel.org/
16:49qq[IrcCity]: imirkin_, is it a working version or only “last approved”?
16:49qq[IrcCity]: working = developers work upon it
16:50imirkin_: qq[IrcCity]: not sure what you mean
16:51qq[IrcCity]: don’t know much about unstable branches.
16:51qq[IrcCity]: does 4.3 incorporate the last stuff from developers?
16:51imirkin_: again unsure what you mean by "instable branch". there's only one HEAD in linus's tree, which is where the linux kernel lives.
16:52imirkin_: there are some changes in ben's private repo which have not been integrated into 4.3
16:52imirkin_: qq[IrcCity]: http://cgit.freedesktop.org/~darktama/nouveau
16:54imirkin_: [note that this is not a linux tree, and is incredibly annoying to build for the average person, but it works nicely for ben, and he's one of the very few people doing development on it]
22:38restart: hi every1, I need help with nvidia gt620
22:40karolherbst: restart: please just ask for what you exactly need help
22:41restart: well, I have GT620 graphics card, and it has one broken SMD Capacitor
22:41restart: I was thinking if someone could help me out :(
22:43karolherbst: I don't think anybody can help you with replacing it remotly though
22:44restart: if some one know what's the capacitor on C608 on GT620 :/
22:44karolherbst: restart: did you figure out which part it is exactly?
22:44karolherbst: I see
22:45restart: SMD Capacitor on GT620 named C608
22:45imirkin: you mean 0608? that's a SMT size iirc
22:45karolherbst: imirkin: I think he means the label on the board
22:45restart: no like C001 C002 label
22:45karolherbst: like C nr 608 here:
22:46restart: yes karol
22:46imirkin: ok, well a 0 can look a lot like a C if it's small
22:46restart: it is not that small
22:47karolherbst: restart: I think you need to ask the card manufacturer directly
22:47karolherbst: maybe they will answer something like that, maybe not
22:48karolherbst: restart: what type of capacitor is it?
22:49restart: SMD Ceramic Capacitor
22:49restart: I'm also on Live Assistance of nVidia
22:50karolherbst: restart: which color?
22:50restart: they are all same color, but different in sizes
22:51karolherbst: still :D
22:52karolherbst: is it more brown or gray and more light or dark?
22:52karolherbst: not that this gives you the right value, but somehow a clue in which ranges it is
22:53restart: I don't quite remember, but I think it was medium
22:53restart: not too dark, or too light
22:54karolherbst: so mhhh
22:55karolherbst: should be something around 1uF and 1nF :/
22:55karolherbst: I doubt that nvidia can help with that though
22:55karolherbst: because usually they don't produce the boards? or do they?
22:55karolherbst: depends on the board, I don't know
23:03restart: they say to contact LeadTek, which is manufacturer of my GT620
23:05karolherbst: yeah, maybe the best idea
23:16restart: I'll try contacting them
23:16restart: btw, thanks
23:17karolherbst: RSpliet: where is the tegra clock gating code :)
23:35karolherbst: imirkin_: did you look at the tegra driver for zcull once? I found some bits for this there and I can't imagine it will be much different for kepler?
23:36karolherbst: ohh it is mainly userspace stuff I suppose
23:41hakzsam: karolherbst, somewhere around here :) https://android.googlesource.com/kernel/tegra/+/b445e5296764d18861a6450f6851f25b9ca59dee/drivers/video/tegra/host/gk20a
23:41karolherbst: hakzsam: so there is nothing ported to nouveau yet?
23:42hakzsam: some bits are probably similar
23:42hakzsam: but you can find interesting stuff I think
23:44karolherbst: okay, thanks
23:47karolherbst: "PMU_PG_CMD_ID_PWR_RAIL_GATE_DISABLE" this sounds like power gating
23:53karolherbst: hakzsam: all therm_gate_ thingies in here? https://android.googlesource.com/kernel/tegra/+/b445e5296764d18861a6450f6851f25b9ca59dee/drivers/video/tegra/host/gk20a/hw_therm_gk20a.h
23:53karolherbst: I think this might be the clock gating bits
23:53karolherbst: not sure though
23:54karolherbst: therm_gate_ctrl_r ahhh