01:01dboyan: imirkin_: I saw this one when trying gnurou's firmware: https://patchwork.kernel.org/patch/9572597/
01:02dboyan: Is mmiotrace of a gp107 still needed?
01:03dboyan: My care is one of those and getting "unknown chipset (137xxxxx)" for now
01:03skeggsb: dboyan: yes please!
01:04skeggsb: i'll be able to merge support once i confirm that it doesn't need other subtle changes
01:04skeggsb: dboyan: you're also going to need to wait for gnurou's next revision of that patch series, there's a patch of mine that's needed to make 3D not hang the GPU too
01:05dboyan: skeggsb, okay. I will capture that later today.
01:06skeggsb: dboyan: that'd be great, thank you :)
01:06skeggsb: it's the one pascal chipset i don't have
01:48LeoTh3o: Hello, I've been pointed here while looking for a way to read the temperature of the GPU while it is bound to vfio-pci. The modified version of nvapeek.c from envytools doesn't seem to work for me as the tool "can't probe" the address of the card
02:06dboyan: skeggsb: The blob failed to initialize when mmiotracing, but it became fine as soon as I ended tracing. Strange
02:07skeggsb: did it say something like "failed to copy vbios to system memory" by chance?
02:07dboyan: yes, exactly
02:07skeggsb: use "nvagetbios -s PROM > vbios.rom", and then use "nvafakebios vbios.rom" before loading nvidia.ko
02:07skeggsb: nfi why that happens, but, the above works for me
02:08skeggsb: or, if you've got an acpi rom, load nouveau, and copy it from /sys/kernel/debug/dri/0/vbios.rom
02:09dboyan: skeggsb: well, nouveau doesn't load on gp107 without hacking :)
02:10skeggsb: yep, so hack it up :P
03:10dboyan: skeggsb: I tried nvafakebios vbios.rom before loading nvidia module, but it still didn't work. The same error occurred when I'm using optirun.
03:11dboyan: The vbios was retrieved from nouveau. nvagetbios -s PROM says 0x55aa invalid signature
03:17dboyan: skeggsb: There was something in mmiotrace btw, about 14MB. No idea if that contains useful information
03:20gnurou: dboyan: skeggsb: although IIRC GP104 worked just fine with the GP100 GR - at least the accelerated console
03:20skeggsb: accelerated console was fine
03:29dboyan: skeggsb: Any idea about my mmiotrace?
03:31skeggsb: not really, that's always worked for me so far :/
03:32dboyan: Then does that 14MB trace contain useful information by any chance?
03:33skeggsb: i doubt it, but i can take a look just in case
03:36dboyan: skeggsb: https://expirebox.com/download/d47dbadb075e503d7a0cc812bde26a69.html
03:40skeggsb: ah... it's a display-less chipset... so, nvafakebios can't do its job (the display regs are necessary to point at the shadow bios image)
03:41skeggsb: and no, there's no useful info in there, it's all attempts to read the vbios
03:43dboyan: well, that's disappointing
03:44skeggsb: i'll see if i can find me a discrete version
06:36mlankhorst: looks like my gtx 480 killed itselff
06:36mlankhorst: horizontal white lines in the bios when booting up, lots of errors when loading nouveau
08:20mystified: hey guys can you help out.. I've have Nvidia g210 (gt218)
08:20mystified: It really does not matter to me i'f i'm using nvidia or nouveau.
08:21mystified: Nouveau is running on my distro (nutyx)
08:21mystified: The graphics are shocking.
08:21mystified: I'm not sure what to do about it.
08:22mystified: nouveau is definetly the driver (NOT VESA)
08:23mystified: egrep -i
08:24mystified: VGA compatible controller: NVIDIA Corporation GT218 [GeForce 210] (rev a2)
08:24mystified: drm_kms_helper 106496 1 nouveau
08:24mystified: drm 290816 7 ttm,drm_kms_helper,nouveau
08:24mystified: syscopyarea 16384 1 drm_kms_helper
08:24mystified: sysfillrect 16384 1 drm_kms_helper
08:24mystified: sysimgblt 16384 1 drm_kms_helper
08:24mystified: fb_sys_fops 16384 1 drm_kms_helper
08:24mystified: BOOT_IMAGE=/boot/kernel root=/dev/sde2 ro quiet
08:24mystified: cat: '/etc/modprobe.d/*kms*': No such file or directory
08:24mystified: ls: cannot access '/etc/X11/xorg.conf'
08:25mystified: can you guys suggest how I can rectify this
08:25mystified: OpenGL vendor string: nouveau
08:25mystified: [ 30.827] (II) LoadModule: "glx"
08:25mystified: [ 31.122] (II) LoadModule: "nouveau"
08:25mystified: [ 31.199] (II) LoadModule: "nv"
08:25mystified: [ 31.200] (II) LoadModule: "modesetting"
08:25mystified: [ 31.207] (II) LoadModule: "fbdev"
08:25mystified: [ 31.217] (II) LoadModule: "vesa"
08:25mystified: [ 31.219] (II) LoadModule: "fbdevhw"
08:25mystified: [ 31.227] (II) LoadModule: "dri2"
08:25mystified: [ 31.329] (II) LoadModule: "fb"
08:25mystified: [ 31.348] (II) LoadModule: "shadowfb"
08:25mystified: [ 31.401] (II) LoadModule: "exa"
08:25mystified: [ 34.279] (II) LoadModule: "evdev"
08:42mystified: BOOT_IMAGE=/boot/kernel root=/dev/sde2 ro quiet
08:42mystified: <mystified> /etc/modprobe.d/
08:42mystified: <mystified> /etc/modprobe.d/broadcom-wl.conf
08:42mystified: <mystified> cat: '/etc/modprobe.d/*kms*': No such file or directory
08:42mystified: <mystified> ls: cannot access '/etc/X11/xorg.conf'
11:05mlankhorst: [ 1.914643] nouveau 0000:01:00.0: fifo: write fault at 0000000000 engine 05 [BAR3] client 08 [BAR_WRITE] reason 0c [INVALID_STORAGE_TYPE] on channel -1 [005fdd4000 unknown]
13:09dboyan: imirkin_, How do you think of my rcp and rsq code in the current shape?
16:10snkcld: the opengl library knows how to communicate directly with the graphics card right?
16:10snkcld: atleast i guess for e.g. the nvidia proprietary driver?
16:10snkcld: how does it know where the card is?
18:04guanche: hi, I've followed the installing-howto (outside of the tree), and I'm now wondering
18:05guanche: if it's common to compile an xserver while the actual is running? I'd like to upgrade to opengl es, and to a newer version basically
18:05guanche: so, just wondering how it's done
18:09gnarface: compiling a newer version of currently-running software is safe
18:09gnarface: installing over top of it may cause delirious results until you restart it
18:10gnarface: (just stop X before running make install)
18:11guanche: so how do you install dependencies of further packages so that all points to /usr/X11R6 in my case?
18:11guanche: I mean, libXbk migth need libXinupt
18:12gnarface: won't actually matter
18:12gnarface: just go ahead and install them too
18:13gnarface: compile them first and then make install all of them after exiting X if you're worried, but if you don't, the worst thing that might happen is one of your programs might crash before you restart it
18:13pq: how do I read /sys/kernel/debug/dri/0/pstate - does AC mean the current clocks, or is it the '*' at the end of another line?
18:13gnarface: (and i only say *might* because it can if it has to try to re-read it from disk hours later for whatever reason)
18:13gnarface: (usually this is not a practical concern)
18:14guanche: the thing is that I have a very little linux console font, so I wanted to make sure I wouldn't lose my xterm
18:14guanche: compiling the rest of the server, in the case of some api collision, on hte linux terminal might not be suitable
18:15guanche: but I'll try none the less
18:15gnarface: guanche: in my experience its never been a problem... once, iceweasel crashed the next day because i forgot to restart it
18:15gnarface: guanche: if you're paranoid, you can always redirect the console output to a text file
18:16gnarface: guanche: make [options] > ./some_text_file.log 2>&1 &
18:16gnarface: guanche: tail -f ./some_text_file.log
18:17gnarface: guanche: but probably it will be safe to make&install everything first, THEN restart X and all the programs
18:17gnarface: guanche: its not fundamentally different than using your distro's native binary upgrade mechanism
18:17gnarface: pq: (sorry, no idea)
18:17guanche: I have a git copy if, so I'll be pulling and installing in the correct order
18:18pq: gnarface, no prob, I'll just wait if someone could tell off-hand
18:19prg: pq: afaik the * shows what's supposed to be set, the AC (or DC depending on power source) line shows what's actually used
18:19Tomin: pq: AC means that you are not on battery power, the last line should tell the current clocks and I have no idea what the * means. That is at least what I was told when I asked about it last year
18:19guanche: I use a linux compiled, but never faced before have to install an x server on top of a running system, but the point is on where configures now pick up existing packages that might not be the newer
18:19guanche: I mean, PKG_CONFIG_PATH
18:19pq: prg, ok, that makes perfect sense in my case. Thanks - Tomin too.
18:20gnarface: guanche: that's only a theoretical concern if you're launching new programs inbetween upgrading some libraries. it won't be a problem for already-running software
18:20pq: what I see is a result of a failed reclocking of G96 and I have the errors to prove it failed.
18:20guanche: It should'nt beause it's in memory already
18:20gnarface: guanche: correct, replacing the on-disk copy of any given library *does not* automatically replace the in-memory version
18:21guanche: yes, that's true
18:21gnarface: guanche: launching a NEW program however WILL read the new library version off the disk
18:21gnarface: guanche: afaik though, the already-running programs will still use a memory-resident cache of the OLD version until they are restarted. i've only run into a couple exceptions to this, and they all happened literally days later
18:22guanche: yes, there could be api colissions with existing programs, and until that doesn't change the system will be unstable even after the new one installed
18:22gnarface: guanche: so i don't think you'll run into any problems, but like i said, use that build log example if you are that worried
18:22guanche: yes, I'll do that, thanks
18:23pq: G96: "clk: failed to raise voltage: -22" and "clk: error setting pstate 3: -22" on a 4.9.10 kernel. I've been meaning to do a bz search, but haven't got to it yet.
19:00pmoreau: Tomin, pq: the * indicates which level is currently set but shouldn’t be used to guess what the clocks are. The last line should be used instead.
19:00pq: pmoreau, thanks for confirming.
19:01pmoreau: I don’t think there are any bug reports about failing to rclock on G96, but I could be wrong.
19:02pq: yup, nothing in bz. I suppose volting just isn't implemented for G96, or is more recent than 4.9.
19:02pmoreau: Whether or not one already exists, please attach your VBIOS to it.
19:02pmoreau: G96 reclocking was merged ages ago IIRC
19:02pq: ah, ok, will do.
19:03pmoreau: Ok, maybe not that long ago, but somewhere towards the end of 2015
19:05pmoreau: RSpliet: -^ if you have time :-)
19:06pmoreau: Ah, which memory type does it have? (I just found that card: https://trello.com/c/A4lqI9kt/89-tesla-1st-gen-memory-reclocking)
19:08pq: pmoreau, fb: 512 MiB GDDR3 says the kernel log
19:11pmoreau: Let’s see whether karolherbst or RSpliet have an idea.
19:27pq: imirkin_, oh wow, I didn't even notice the memory clocks actually got raised.
19:33RSpliet: pmoreau: haven't had time since can't remember how long ago O:-)
19:39pq: imirkin_, thanks, that a noticeable performance raise here. :-)
19:51pmoreau: RSpliet: :-/ One day, maybe, you'll have time…
19:55karolherbst: pmoreau: oh well, we could figure out the one issue you have already :p
22:14guanche: does anybody happen to know why mesa's configure gives me this: "OpenGL: yes (ES1: no ES2: no)"
22:15guanche: or is it there needs to be hardware support for opengl es?
22:25airlied: guanche: maybe some missing egl enables or platforms
22:32guanche: yes, I got it, thanks
22:55karolherbst: mupuf: got some time to plug the fermi in? I really would like to test the fermi reclocking code more deeply
23:01mupuf: karolherbst: oh, righr!
23:01mupuf: what fermi?
23:02mupuf: nvce is plugged
23:05karolherbst: one that has several pstates :D
23:05karolherbst: nvce should be fine
23:05karolherbst: just wanting to test stuff and fix engine reclocking issues I find
23:21karolherbst: compiling nouveau on reator is sometimes really painful :/
23:27mupuf: too slow?
23:28karolherbst: no, finding the fitting base commit
23:28mupuf: ah, right, that too
23:28karolherbst: especially, because I usually rebase skeggsb/master
23:28mupuf: IIRC, I now have icecream running
23:28mupuf: so reator uses my desktop pc to speed up compilation
23:29karolherbst: fermi gpus boot so terribly slow :/
23:32karolherbst: with nouveau loaded, lspci hangs
23:34karolherbst: something is terribly broken again
23:35karolherbst: will look into this tomorrow