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