03:12 gnurou: karolherbst: have you tried unloading/reloading nouveau.ko instead of doing a suspend/resume? Can you start the PMU in that case?
07:53 gnarface: ok, i think its fair to say this is an irq issue.
07:53 gnarface: 1) holding a keyboard button down freezes video playback
07:53 gnarface: 2) unplugging the keyboard before boot-up fixes the streaming issue
07:54 gnarface: video card using a different irq probably is a red herring
07:55 gnarface: legacy usb support IS on in the bios, but without it the usb keyboard doesn't work during boot-up
07:55 gnarface: (and there's no ps/2 ports on this sad thing)
08:27 karolherbst: gnurou: I think reloading nouveau only works when I disable secboot. But I only tried it with a secboot disabled nouveau first, reclock, secboot enabled nouveau
08:28 karolherbst: I doubt that reloading nouveau as it is works, cause I am reloading nouveau while testing this
08:34 karolherbst: gnurou: I am quite sure, that something within secboot oneinit does something which isn't cleared up later in fini, but get reset by suspend
08:35 gnurou: if this "something" is done by the signed firmware, then sadly we are screwed :/
08:35 karolherbst: gnurou: how is the gr brought back up after suspend by the way?
08:36 gnurou: but! when you resume from suspend, secboot is run again, right?
08:36 karolherbst: no idea?
08:36 karolherbst: that's why I am asking
08:36 gnurou: ah, you're talking about oneinit, not init
08:36 karolherbst: but there is no init in secboot
08:36 karolherbst: so I guess the falcons can be suspended and resumed just fine
08:36 karolherbst: even when in LS mode
08:36 gnurou: errr no secboot must be re-run after a resume, let me check that...
08:36 karolherbst: odd
08:37 karolherbst: I mean sure, the pmu still needs to be run after secboot... right
08:37 karolherbst: okay maybe secboot is indeed performed again
08:37 karolherbst: but then again, why does suspending the machine help
08:39 gnurou: secboot is performed, but there is no init function because it is done lazily
08:39 karolherbst: mhhh
08:39 karolherbst: so whenever the GR is accessed again
08:39 gnurou: (that's due to the firmware files not necessarily being available when init() is called)
08:39 karolherbst: okay, I didn't try if I am still able to reclock after running OpenGL stuff or starting X
08:40 gnurou: GR will ask secboot to reset the falcons, and secboot will redo all its business
08:40 karolherbst: I see
08:40 karolherbst: that explains it then
08:41 karolherbst: maybe
08:41 gnurou: now, all that oneinit does is allocate some VRAM and set it up to be used as an instance block
08:42 gnurou: so I doubt it could be the cause of your troubles
08:42 karolherbst: I know that secboot is performend when nouveau gets loaded
08:42 karolherbst: so I guess that something wants to do stuff with the gr or the gr is just loaded for some reasons
08:43 karolherbst: and after suspend/resume it may be done lazily
08:43 gnurou: GR should be acquired immediately to render the (accelerated) console, both at load time and during resume
08:44 karolherbst: there is no display attached ont he machine
08:44 gnurou: aha
08:44 karolherbst: and I only care about machines with fans not controlled by the GPU for now
08:44 karolherbst: so mainly mobiles
08:44 gnurou: then GR should not be acquired until you use it... on Tegra this is what happens.
08:44 karolherbst: yeah
08:45 karolherbst: and I figure it gets started on nouveau loading time anyway
08:45 karolherbst: sooo on mobile chips it would work anyway, cause the gpu gets suspended hopefully
08:45 karolherbst: which is then fine for now
08:45 karolherbst: but
08:45 karolherbst: this patch is still required: https://github.com/karolherbst/nouveau/commit/2b6c1f54eaef6b544e3aa56b1368adadc61b82a3
08:46 karolherbst: and I don't get my head around why it should matter in this situation
08:46 karolherbst: gnurou: maybe I need to run gr_fini as well?
08:47 gnurou: what I don't understand is how secboot can run its unload blob when you suspend, but you cannot run your own code?
08:47 gnurou: the use case should be exactly the same
08:47 karolherbst: but there is no fini implementation for gf100+
08:48 karolherbst: yeah
08:48 gnurou: have you tried hacking the secboot code to load *your* PMU code instead of the unload blob?
08:49 karolherbst: mhhhhh
08:49 karolherbst: I could patch the unload blob
08:49 karolherbst: I know that our pmu code is too big for the 0x100 unsecure area
08:50 karolherbst: might get a bit ugly
08:50 karolherbst: ohh wait
08:50 karolherbst: I could just hack around that somehow
08:50 karolherbst: have to tinker with it a little then
08:50 karolherbst: and first I have to understand the secboot code more deeply
08:56 karolherbst: gnurou: but I am actually surprised that code can be loaded after the falcon was put into HS mode, allthough I am sure the HS priviliges are dropped, but then again: wtf :p
08:58 gnurou: 0x100 unsecure area?
08:59 gnurou: HS privileges should be dropped after the ACR completes, you can check the mode by reading register 0x10a240
08:59 gnurou: bit 0 is set if the falcon is in LS mode, bit 1 is set if it is in HS mode
08:59 gnurou: a falcon in non-secure mode should have both bits set to 0
09:03 karolherbst: gnurou: I meant from 0xa0 to 0x1a0
09:03 karolherbst: gnurou: ohh, this is good to know
09:04 karolherbst: it isn't inside rnndb yet :p
09:06 karolherbst: gnurou: but I was under the impression, that the falcon never goes back to NS mode because of the risk of leaking data?
09:08 gnurou: it does, if the HS firmware allows it
09:08 gnurou: of course in that case, all sensible data is supposed to be cleared
09:09 karolherbst: I see
09:17 mupuf: "supposed to", will be fun to test that theory
09:32 karolherbst: mupuf: chances are high they don't though
09:33 karolherbst: well, I doubt that there is anything valuable enough to be usefull though
10:55 hakzsam: imirkin_: how many failures with CTS btw?
12:27 adfeno: Hi all! :)
12:28 adfeno: I have a friend who has an Nvidia GeForce GT 730 (no M letter).
12:29 adfeno: And we want to know if Nouveau supports it with 3D acceleration
12:33 karolherbst: adfeno: yes
12:33 karolherbst: it is a kepler or a fermi one most likely
12:33 karolherbst: hope it is kepler
12:35 adfeno: karolherbst: luizrpgluiz (my collegue) and I found strange that Nouveau's FreeDesktop wiki page about code names doesn't list that GPU.
12:36 adfeno: However, it lists only the M counterpart.
12:36 karolherbst: it's a waste of time to adjust the list all the part
12:36 karolherbst: check wiki for the code names: https://en.wikipedia.org/wiki/List_of_Nvidia_graphics_processing_units
12:36 karolherbst: or your gpu
12:36 karolherbst: mhh
12:36 karolherbst: the codenames are different
12:37 karolherbst: well
12:37 karolherbst: gfxxx is fermi
12:37 karolherbst: and so on
12:37 adfeno: We have Nvidia GeForce GT 730
12:37 karolherbst: ohh wait, on the codenames nouveau page there are actually both "kinds" of tags
12:37 karolherbst: adfeno: yeah, but you need the chipset as well
12:38 karolherbst: there should be a gf108 or gk208 somewhere
12:38 karolherbst: well
12:38 karolherbst: if you check lspci
12:38 karolherbst: gf108: fermi, gk208: kepler2
12:39 adfeno: The chlipset of this desktop computer is Intel G41 Express
12:39 adfeno: It originally came with an integrated Intel GMA X4500 graphics.
12:39 adfeno: (still has it, though)
12:40 adfeno: But we are planning to use the Nvidia GPU in question instead.
12:46 adfeno: karolherbst: So... How do I know if it's Kepler or Fermi?
12:49 karolherbst: adfeno: check lspci
12:49 karolherbst: both is supported
12:49 karolherbst: but starting with 4.10 you should be able to reclock a kepler gpu without problems
12:50 adfeno: 4.10 is version of Nouveua?
12:50 karolherbst: linux
12:58 adfeno: Hm... Thank you very much karolherbst :)
13:41 RSpliet: skeggsb: nice set of recovery patches
13:47 mupuf: fuck yeah!
13:47 mupuf: and we can implement robustness now too :)
13:53 karolherbst: wuhu
14:17 pmoreau: Indeed! Very nice serie!
14:25 karolherbst: :) https://github.com/skeggsb/nouveau/commit/9e20a303f3aaa73fecdac18fe7031d9aaa5fb077
14:25 karolherbst: I like that one
14:25 karolherbst: I hope nouveau unloads much faster when stuff goes south with this :D
14:47 pmoreau: :-)
14:59 karolherbst: mhh, wondering what would happen if you reclock your GPU, and get SCHED_ERRORS all the time
14:59 karolherbst: this might be fun
17:09 imirkin_: orbea: sounds like this should fix your vblank issue - https://github.com/skeggsb/nouveau/commit/5007eb88028a91e793f50c6aa31e0d85ff366bd4
17:45 orbea: imirkin_: it does :) I've tested the patch when skeggsb asked me to
17:45 imirkin_: ah cool
17:45 imirkin_: wasn't sure if he was talking to you or not.
17:46 imirkin_: skeggsb: so what's the upshot of your various recovery fixes? does nouveau recover some of the time now?
18:27 whompy: Adding to the above, looks like this should only affect newer generations?
18:28 imirkin_: fermi and up, yeah
19:25 karolherbst: somebody any complaints about this commit? https://github.com/karolherbst/envytools/commit/3679a3a5b580dd9e8e0abae61b8400a7ecf95dfa
19:25 karolherbst: allthough there is something at 0x3000
19:26 karolherbst: and for a secure booted gr it is set to 0x7021
19:27 karolherbst: uhh wait
19:27 karolherbst: it is GM204- ? -...
19:27 karolherbst: okay
19:27 imirkin_: yeah
19:27 imirkin_: and also it might be GM107-
19:27 imirkin_: but wtvr
19:27 karolherbst: it might be even something lower
19:28 karolherbst: it is set to 0 on the gm107
19:28 imirkin_: not according to the doc
19:28 imirkin_: well, we don't use the secure modes ;)
19:28 karolherbst: well, the reg defaults to 0x3000 on the gm206
19:29 imirkin_: so the higher bits aren't there, wtvr
19:29 karolherbst: the crypt extension isn't exactly new though
19:29 karolherbst: so maybe even tesla have that reg
19:29 imirkin_: the PCRYPT engines had an AES thingie
19:29 imirkin_: for HDCP and other idiocy
19:29 imirkin_: but it was't for encrypted code
19:29 imirkin_: it was for encrypted data
19:30 imirkin_: er, ignore the "encrypted code" comment
19:30 imirkin_: but either way, it was for data only afaik
19:30 karolherbst: well
19:30 karolherbst: the process is nearly the same
19:31 karolherbst: just one secure mode less
19:31 karolherbst: and less secure overall
19:31 karolherbst: imirkin_: did you see this? http://http.download.nvidia.com/open-gpu-doc/Compute-Class-Methods/
19:31 imirkin_: nope.
19:31 karolherbst: 23th of jan ;)
19:32 karolherbst: :D
19:32 karolherbst: clc1c0.h
19:32 karolherbst: pascal_compute_b_struct
19:32 karolherbst: ohh wow
19:32 karolherbst: back to nv50_compute_t
19:33 hakzsam: it's especially useful for pascal because the launched descriptor is commpletely different..
19:33 imirkin_: nice. NV90C0_SET_SU_LD_ST_TARGET_FORMAT
20:22 mooch: karolherbst, since we're getting some hwdocs for g80 and later
20:22 mooch: and we uh finally get some fucking complete nv3 and nv4 docs?
21:36 karolherbst: mooch: progress! :D
21:39 mooch2: no i mean
21:39 mooch2: can
21:39 mooch2: not and
21:39 mooch2: sorry, i must have not noticed the typo lmao
21:41 imirkin_: you overestimate the probability that such docs existed
21:52 mooch: what do you mean? didn't they have to have them for the driver devs?
21:52 imirkin_: drivers were simpler.
21:52 imirkin_: the docs may have been "write values x, y, z to these regs and let the good times roll"
21:53 mooch2: lmao
21:53 mooch2: they still had to implement opengl
21:53 mooch2: and direct3d
21:53 karolherbst: readme.txt
21:53 mooch2: and gdi
21:53 karolherbst: uhhh
21:53 imirkin_: this is still how docs are provided for some components of the gpu's
21:53 imirkin_: (esp the memory stuff)
21:53 karolherbst: well
21:53 karolherbst: stuff was simplier back then
21:54 karolherbst: was there even an OpenGL 1.0 spec?
21:54 mooch2: yeah
21:54 karolherbst: or was it written _after_ opengl 1.0 come to live
21:54 mooch2: there was a spec
21:54 karolherbst: ohh wow
21:54 karolherbst: found it
21:54 imirkin_: GL 1.0 came out a LONG time ago
21:54 karolherbst: nearly 150 pages
21:55 karolherbst: 1994 was the spec
21:55 mooch2: besides, the riva 128 already implements opengl 1.1
21:55 mooch2: and the tnt goes to 1.5
21:55 imirkin_: with tons of driver support :)
21:55 mooch2: yeah but still
21:56 imirkin_: no t&l, no 3d, no lots of stuff
21:56 imirkin_: i'm amazed they got 1.5 on nv4
21:56 mooch2: nv4 at least does dx6
21:56 mooch2: and isn't ogl 1.x basically just d3d7?
21:57 imirkin_: nfc. i know what nv4 supports and what we fail at in the nouveau_vieux GL 1.2 driver.
21:57 mooch2: oh geez, it only goes to gl 1.2?
21:57 mooch2: good lord
21:57 mooch2: gl 1.0 has t&l too tho
21:57 imirkin_: let's see...
21:58 imirkin_: https://people.freedesktop.org/~imirkin/glxinfo/#p=compat&b=version&g=NVIDIA%20Riva%20TNT%2FTNT2
21:58 imirkin_: that's the mesa driver for it
21:58 imirkin_: basically all the missing bits are things that the hw doesn't support
21:58 imirkin_: but could be worked around in the driver somehow
21:59 imirkin_: with a MASSIVE perf hit
21:59 imirkin_: one thing we lie about is 3d textures
21:59 imirkin_: to get GL 1.2
21:59 mooch2: wow, so the hardware only supports gl 1.1?
22:00 imirkin_: there was no 3d texture support until nv30 :)
22:00 imirkin_: i think people just knew not to use them
22:00 mooch2: WOW
22:00 mooch2: that's quite shitty
22:00 imirkin_: since otherwise you fell off a perf cliff
22:01 mooch2: wtf nvidia
22:01 mooch2: anyway, i'm thinking about possibly adding the intel 740 to 86box again
22:01 mooch2: only problem is
22:01 mooch2: i couldn't get the bios working last time
22:01 mooch2: so, intel graphics gen 1
22:01 imirkin_: only problem is there never were drivers for i740? :)
22:02 imirkin_: you should talk to vsyrjala - i think he might have looked at supporting i740 somewhere.
22:02 mooch2: i know xfree86 has a 2d driver
22:03 mooch2: imirkin_, looks like you lie about supporting shaders too lmao
22:03 imirkin_: ?
22:04 imirkin_: first off - i never lie. i provide alternative facts...
22:04 karolherbst: :D
22:04 imirkin_: secondly, what did i say about shaders?
22:04 mooch2: ARB_shading_language_100 • •
22:04 imirkin_: yeah what about it?
22:04 mooch2: no i mean mesa lies
22:04 mooch2: sorry
22:05 mooch2: on nv4/nv5 anyway
22:05 imirkin_: well, amusingly, if you look at the spec, it doesn't say you can actually use it anywhere
22:05 imirkin_: it just provides a way of specifying shaders
22:05 imirkin_: "ARB_shader_objects, ARB_fragment_shader, and ARB_vertex_shader are
22:05 imirkin_: required to utilize the OpenGL Shading Language associated with this extension"
22:06 imirkin_: it's exposed by mesa for all drivers
22:06 mooch2: oh
22:06 mooch2: welp
22:06 imirkin_: which is why you see some "late" extensions exposed on there
22:13 skeggsb: imirkin_: it did "some" of the time before. this should at least greatly improve CTXSW_TIMEOUT recovery, which failed a lot of the time on some boards before. i don't have a test case that doesn't recover now, but, i'm sure i'll come across more
22:13 imirkin_: skeggsb: awesome =]
22:14 skeggsb: i'll work on doing more for userspace reacting appropriately too, but i haven't got that stuff ready yet
22:14 skeggsb: currently, you'll still have to ctrl+c the app that faults, for example
22:14 skeggsb: but, on the up-shot, it'll die instantly now, instead of timing out for ~30s or so
22:15 imirkin_: iirc there were situations where you had to ^C the app "in time"
22:15 imirkin_: or else it took everything down
22:15 imirkin_: where "in time" was within 5-10s of the fault happening
22:15 skeggsb: hm, i haven't come across that
22:15 imirkin_: anyways, if you want to hang your box, just try to start a race with F1 2015
22:15 imirkin_: works every time ;)
22:15 skeggsb: what does the kernel report for that?
22:16 imirkin_: no clue. hakzsam spent a bunch of time on it
22:16 skeggsb: userspace still needs to be fixed for arb_shader_image_load_store-atomicity btw, the shaders hang the channel
22:16 imirkin_: i have a degraded raid5 array, so i've tried to stay away from that kind of stuff.
22:16 skeggsb: the kernel recovers the rest of the gpu now though at least
22:17 skeggsb: and i still need to push the mesa fixes for the CE2 hangs that enabling gl 4.3 cause
22:21 karolherbst: skeggsb: did you had time to look over my last power cap series? Really would like to get it in for 4.11 if this is still possible
22:21 skeggsb: karolherbst: i was going to do it yesterday, but i'll get to it today
22:21 karolherbst: :) awesome thanks
22:22 Echelon9: skeggsb: If I take the Trello task "hwmon_device_register() is deprecated please convert the driver to use hwmon_device_register_with_info()" will I be stepping on anyone's toes, or duplicating work that's already been done in your knowledge?
22:22 karolherbst: Echelon9: I created that card :p
22:22 Echelon9: You may have seen I've been picking up basic nouveau / envytools tasks
22:22 Echelon9: @karolherbst: Oh ok, yes I see that
22:23 karolherbst: Echelon9: it's something related to 4.10
22:23 karolherbst: and I doubt anybody was aware of that
22:23 karolherbst: or it was
22:23 karolherbst: no idea
22:23 karolherbst: if you want, you can do it
22:23 Echelon9: OK
22:24 karolherbst: can you comment on the cards?
22:24 mooch2: Echelon9, there's an nvidia emulation effort in 86box if you want to help with it
22:24 karolherbst: then you should leave a note and it will be okay
22:24 Echelon9: I'll create/register an account on Trello and do that
22:24 karolherbst: Echelon9: and if you want, you can finish this as well: https://trello.com/c/fndxUee1/92-clock-gating-fermi
22:24 karolherbst: later on
22:24 karolherbst: I think it would be a perfect issue for a new dev
22:25 karolherbst: because you can have a really crappy implementation at first
22:25 karolherbst: and improve it while you go
22:26 karolherbst: skeggsb: did you port every vbios table over to 32 bit or are there still some left?
22:26 skeggsb: karolherbst: all the P table ones, i did. there's potentially some others elsewhere
22:27 karolherbst: okay
22:27 Echelon9: @karolherbst: Thanks for the pointer
22:27 karolherbst: Echelon9: you can echo me or mupuf about that card, no idea who else knows enough about this one
22:29 karolherbst: ohh I was smart enough to use 32bit for the power budget table :) good good