00:44 imirkin: skeggsb_: were you going to look at https://bugs.freedesktop.org/show_bug.cgi?id=101587 ?
00:45 skeggsb_: imirkin: yeah, i'm getting to it.. i've seen reports somewhere though that 4.12 already resolves it, though i have nfi how
00:45 imirkin: errr... well could be some kind of ordering coincidence
00:45 imirkin: or maybe runpm broke :)
00:46 skeggsb_: who knows, but yeah.. i'm trying to get you some kind of mesa tree to take a look at in the next couple of days, then i'll look at that bug (among other things)
00:46 imirkin: ok cool
00:47 imirkin: i'm not sure when i'd be able to take a meaningful look at a serious mesa change - i'm trying to crawl out from under a tonne of shit that's been piled on me. not succeeding. not 'til next weekend at the earliest.
00:48 skeggsb_: yeah i hear you, i've had a bunch of life stuff up-end itself on me the last couple weeks which is making stuff drag a bit!
00:48 imirkin: =/
09:12 karolherbst: mupuf: and if I don't read them?
09:14 pmoreau: karolherbst: Blame's on you? ;-p
09:15 karolherbst: sad!
09:15 pmoreau: Indeed
09:22 karolherbst: skeggsb_: it would be really really great if you could look over my last clk update series, I need this + a few other patches related to the thermal daemon for that software clock throttling to enable maxwell2 reclocking hidden behind a flag.
09:51 mupuf: karolherbst: I had faith in you ;p
09:59 karolherbst: mupuf: do you by any chance know where the sw throttling rules may be stated on pre Kepler GPUs?
10:00 mupuf: SW throttling?
10:03 karolherbst: I meant downclocking on high temperatures
10:03 karolherbst: in contrary to the hw mechanism the GPUs have for it
10:08 mupuf: ok, let's just call it downclocking then
10:08 mupuf: pretty sure they just use the fixed thresholds or what's in the therm table
10:09 mupuf: or there is yet another table I missed
10:09 mupuf: there is one value I hardcoded for 100%, in the fan management
10:09 mupuf: for fermi+
10:09 mupuf: because I could not find the right value anymore
10:09 mupuf: but maybe this value actually exists somewhere
10:10 mupuf: I wish nvidia would fucking release the specs of the bios, especially now that we can;t fake it easily...
10:10 RSpliet: "pardon my French"
10:10 mupuf: yep :D
10:11 RSpliet: Since when did we go from "hack ALL THE THINGS!!!" to "*snicker* we just want all the docs..."?
10:16 karolherbst: I didn't
10:16 karolherbst: having docs is no fun
10:17 karolherbst: it would be nice to have confirmation though. Like if we ask them "is X correct" that they would say "yeah, sounds about right"
10:20 karolherbst: mupuf: I doubt there is another table, but having a value inside the therm one might make sense. We should figure that out for Tesla as well
10:20 mupuf: RSpliet: since we cannot upload a new bios on maxwell 2+?
10:21 mupuf: right now, it is ok because we largely avoid working on maxwell 2+
10:21 karolherbst: nobody says we can't do so in the future
10:21 mupuf: but, this is hurting the project
10:21 karolherbst: yeah sure, but we could also just try to fix it ourself
10:21 mupuf: karolherbst: we'll see
10:21 mupuf: I tried
10:22 mupuf: I did not give it all, but still
10:22 karolherbst: yeah, I know, it's super hard now, but maybe there is a way somewhere
10:22 RSpliet: mupuf: I was obviously not super-serious, I know of the limitation (was it properly signed with AES?)
10:22 karolherbst: I super dislike to depend on nvidia here so my least favourable solution would be to wait for nvidia
10:23 mupuf: karolherbst: of course. The best would be for them to allow this again
10:23 karolherbst: well RSA-1024 is considered weak now
10:23 mupuf: it may simply has been broken
10:23 karolherbst: just a matter of time until AES-128 is weak as well
10:23 mupuf: have*
10:23 mupuf: by accident, and no-one cared to fix it
10:23 mupuf: or even realized
10:23 mupuf: weak, by which standards?
10:24 karolherbst: keys can be brute forced
10:24 mupuf: if we need to rent a datacenter for a one week, this will not do
10:24 karolherbst: in sensible time
10:24 mupuf: yeah, but it will likely never been as weak as one machine being able to attack it.
10:24 karolherbst: true
10:24 karolherbst: and for the RSA-1024 attack you need a quantum computer
10:25 karolherbst: but it's totally doable now
10:25 mupuf: ;p
10:25 RSpliet: might have to see if I still have some connections with TU Delft then...
10:26 karolherbst: they can calculate the prime factors really fast now, so this part is broken, which doesn't affect AES in any way though
10:26 mupuf: but I don't get it though, modders still manage to upload new vbios
10:26 karolherbst: nvidia tools
10:26 mupuf: so, it may just be PRAMIN that is not allowed as a source anymore
10:26 karolherbst: yeaj
10:26 karolherbst: that's what I think as well
10:27 karolherbst: I am sure with the proper tools you can just reflash a new vbios
10:27 mupuf: yes, but I would rather avoid that...
10:27 karolherbst: sure, but if it's the only feasable way for now?
10:27 karolherbst: but
10:27 karolherbst: who says we actually _have_ to flash it?
10:28 karolherbst: maybe that tool is dump and contains the key
10:28 karolherbst: why securing PRAMIN if you want to only allow signed vbios on the GPUs?
10:28 karolherbst: it makes no sense
10:29 mupuf: exactly why I think this was accidental
10:29 mupuf: because it does read the bios from PRAMIN
10:29 mupuf: and then aborts at some point
10:29 karolherbst: the driver does it afaik
10:29 RSpliet: Do modders still actively modify their VBIOS? Or do they just steal VBIOSes from cards with slightly higher clocks and keep their fingers crossed that the DRAM parameters aren't 100% bogus all of the sudden?
10:29 karolherbst: RSpliet: they still do
10:29 karolherbst: because they want to go even higher
10:30 karolherbst: maybe those vbios files are just leaked from persons who can actually write such vbios files
10:30 karolherbst: who knows
10:31 karolherbst: I doubt they are able to do it by hand, because those tools are usually shitty and do shitty things
10:31 karolherbst: pretty sure they have OEM tools
10:31 karolherbst: and I am 100% those tools contain the key
10:40 mupuf: karolherbst: possible
10:41 mupuf: but I would like nvidia to give us these tools. What's the point anyway, I would be OK to sign an NDA for that
10:41 karolherbst: I wouldn't
10:41 mupuf: NDA as in: Do not share to with another party
10:41 karolherbst: NDAs are usually a nogo for me and I won't sign one for hobbies or private stugg
10:41 karolherbst: you don't need an NDA for that
10:41 karolherbst: this is already covered by copyright and so
10:42 mupuf: but still, be able to write whatever code you want with it, as long as it does not contain keys or stuff
10:42 RSpliet: "Do not share to with another party" sounds like a non-disclosure agreement... semantics
10:42 mupuf: karolherbst: right
10:42 karolherbst: RSpliet: license/copyright covers this already
10:42 RSpliet: "semantics"
10:42 mupuf: anyway, I would be ok with following the license
10:43 RSpliet: Can we get Freedesktop to sign up as an NVIDIA OEM? :-P
10:43 karolherbst: sure, license are fine, I just won't sign an NDA for this
10:44 RSpliet: karolherbst: "semantics". It's the content of the license that matters, not the abbreviation used to describe it
10:44 karolherbst: there is a difference though
10:44 karolherbst: if you sign an NDA and you reduce the rights you have, it's your problem
10:44 RSpliet: But equally no two NDAs are the same
10:44 RSpliet: Ah, is that true in European law?
10:45 karolherbst: if there is invalid parts in the license, it's not your problem
10:45 karolherbst: well you can give up rights through contracts
10:45 karolherbst: like NDAs
10:45 karolherbst: and if you sign it, it's voluntaraly
10:45 mupuf: karolherbst: not true
10:46 mupuf: contracts cannot violate the law, if they do, this part is invalid
10:47 karolherbst: mhhh I wasn't talking about violation of law
10:48 karolherbst: you can sign that you won't use it for RE purposes
10:48 karolherbst: this is totally legal
10:48 karolherbst: allthough by law you have the right to do so if you didn't sign that NDA
10:49 karolherbst: there are also other situations where you can give up rights through contracts
10:49 karolherbst: and this is normal daily business
10:49 karolherbst: and that's why NDAs are shit
10:49 karolherbst: usually
10:49 karolherbst: and everybody should only sign NDAs after they spoke with lawers about it
10:49 mupuf: right
10:50 karolherbst: because there might be consequences you aren't aware of
10:50 mupuf: I see. Fair point!
10:50 karolherbst: with licenses you are simply less fucked
10:51 RSpliet:hears the pen scribbles of NVIDIA taking notes :-P
11:30 mupuf: I thought I had reviewed all the clk patches, but it looks like there are 2 I did not
11:30 mupuf: :o
11:31 karolherbst: shame on you :p
11:39 mupuf: well, ... , hmm, yes :(
13:59 RSpliet: Love how ROP seems to have been renamed from Raster OPeration (array) to Render OutPut (unit)
15:17 UberLambda: Hello anyone! Does anybody here have a working Intel 630 + NVIDIA GTX 1060 Optimus Laptop working with nouveau?
15:17 UberLambda: The only way I could manage to boot the machine was with "nouveau.modeset=0" on the kernel command line, but that seems to disable the external card completely
15:18 UberLambda: Otherwise it would just freeze to "Pointer to flat panel table invalid"
15:23 imirkin_: UberLambda: try nouveau.runpm=0
15:24 imirkin_: also, what kernel are you using?
15:25 UberLambda: imirkin: Arch Linux latest (4.11.9-1-ARCH)
15:25 UberLambda: imirkin_: what does that option do exactly? I've never seen it
15:26 imirkin_: https://nouveau.freedesktop.org/wiki/KernelModuleParameters/
15:26 UberLambda: thanks
15:26 UberLambda: Hm, so it could be a power issue?
15:26 UberLambda: I'm adding this to the kernel command line... rebooting, fingers crossed
15:27 imirkin_: well, without any logs from you, all one can do is guess.
15:27 UberLambda: I can't seem to get logs
15:27 imirkin_: you might need 4.12 for pascal to work ok
15:27 UberLambda: The system just freezes and I can't access any TTY
15:27 imirkin_: depending on how far in the boot the system is getting ... ssh or netconsole
15:27 UberLambda: It doesn't even seem to be a kernel panic, LEDs are not flashing
15:28 imirkin_: also you can avoid loading nouveau, and then load it once the system is fully booted
15:28 UberLambda: imirkin_: I tried that, but it doesn't seem to detect the card as a PRIME sink
15:28 imirkin_: which one's PRIME sink again?
15:28 imirkin_: render offload, or making outputs available?
15:29 UberLambda: I'd like to transfer rendered frames from the discrete card to the screen's buffer
15:29 UberLambda: extra outputs are wired to the discrete card
15:30 UberLambda: but the laptop has an integrated screen that, from what I could tell, is hardwired to the Intel graphics chip
15:30 UberLambda: It's a CLEVO P650HP
15:30 UberLambda: (rebooting, will come back soon)
15:34 UberLambda_: I'm back
15:34 UberLambda_: so... it turns out that an external monitor works fine
15:34 UberLambda_: the internal screen is completely frozen though
15:34 UberLambda_: The system is actually functioning, I'm writing from a TTY right now
15:35 UberLambda_: Do you need the Xorg.0.log?
15:35 UberLambda_: imirkin_: ^
15:44 imirkin_: you need kernel 4.12 for pascal accel
15:44 imirkin_: render offloading requires accel
15:44 UberLambda_: imirkin_: I will update it then
15:44 UberLambda_: Thanks for the help!
16:23 rmbeer: hello
16:24 rmbeer: how to change the mode setting with nouveau? I read all about of this and KMS. But can't found the command, device, or other options for change the mode setting.
16:27 rmbeer: why nouveau can setting the resolution of the screen in the kernel booting and xorg server but i can't change the simple resolution of the tty???
16:27 rmbeer: i must report in the bug list or what???
16:40 imirkin_: rmbeer: it's not any different with nouveau than any other kms driver
16:41 imirkin_: rmbeer: fbcon uses fbdev, which in turn has no concept of changing resolution and the such (i think)
16:41 imirkin_: [or maybe fbdev does, but fbcon doesn't support it? dunno.]
16:43 rmbeer: unknown about of fbdev and fbcon, what is this?
16:44 rmbeer: imirkin_, i have any method for use direct from the driver of nouveau? maybe in C from the api or something.
16:45 imirkin_: fbcon is the thing that draws the terminal
16:46 imirkin_: fbdev is an old api for creating a framebuffer that applications can control
16:46 imirkin_: chances are, irrespective of what you're trying to do, the answer is "use the KMS api"
16:47 imirkin_: here's a sample kms application: https://cgit.freedesktop.org/mesa/kmscube/
16:58 rmbeer: imirkin_, thanks, now are studying it
17:05 rmbeer: imirkin_, then for use KMS i must use from DRM?
17:09 imirkin_: DRM is for rendering, KMS is for modesetting
17:10 orbea: for a non-sample example, RetroArch works with kms too
18:38 karolherbst: nice
18:38 karolherbst: there is no -+1 handling in the P50 table
18:38 karolherbst: those are simple < / > checks
18:39 karolherbst: so if t0 is 95 and the offsets are both 0, then downlock is at x > 95 and downclock at x < 95
18:39 rmbeer: imirkin_, the kmscube take a several leaks...
18:39 rmbeer: stuff* leaks
18:42 imirkin_: send patches :)
18:43 mupuf: karolherbst: yeah, they had the same in ptherm
18:43 karolherbst: yeah
18:44 karolherbst: I add the stuff to nvbios now before I forget it
18:44 mupuf: Yep!
18:50 karolherbst: yay, with the stock vbios nvidia did what I expected
18:50 karolherbst: mupuf: any suggestions regarding layout/style? https://gist.github.com/karolherbst/606859bd7619c866f6ef26ef2e7788ce
18:51 karolherbst: I remove that silly "-- entry " thing
18:53 mupuf: wait, interval == 200us :o
18:53 karolherbst: it's ms
18:53 karolherbst: I know
18:53 mupuf: that makes more sense
18:53 karolherbst: yeah
18:54 mupuf: when you reach 96°C, by how much does it downclock?
18:54 mupuf: one pstate or one cstate?
18:54 karolherbst: none
18:54 karolherbst: t has to be > 95 + 1
18:54 karolherbst: ;)
18:54 karolherbst: it's defined by the interval and a step
18:54 karolherbst: the step is also there
18:54 rmbeer: imirkin_, you maintain the repository?
18:54 karolherbst: it basically say: each 200ms - 50 MHz
18:55 mupuf: where is the step defined here?
18:55 karolherbst: not quite sure anymore
18:55 karolherbst: need to figure it out
18:56 mupuf: :)
18:56 karolherbst: +0x0a or later
18:56 karolherbst: somewhere here : "12 30 ff ff 60 00"
18:56 karolherbst: I figured it out once, but forgot
18:56 karolherbst: I think it was "12 30 ff ff"
18:57 karolherbst: -53229 kHz
18:58 karolherbst: funny though, the same speed is used while upclocking if I don't missremember
18:58 mupuf: well, that makes sense
18:59 mupuf: but yeah, easy to check: make the value 25MHz and see if when the temperature increases, the gpu gets upclocked :D
18:59 mupuf: the driver may have a check for that thoyugh
18:59 karolherbst: I thought -1kHz is a good idea
18:59 karolherbst: but then.....
19:00 karolherbst: -4MHz should do
19:00 mupuf: ah ah
19:00 karolherbst: mupuf: ohh no, I won't try silly values
19:00 karolherbst: not with this table
19:00 mupuf: why?
19:00 karolherbst: if there is invalid stuff, nvidia won't load or crash the kernel
19:00 mupuf: hehe
19:00 mupuf: chicken!
19:01 karolherbst: "NVRM: RmInitAdapter failed! (0x25:0x40:1080)" :/
19:01 karolherbst: ohh
19:01 karolherbst: change the wrong bytes
19:02 karolherbst: uhm, no, it was okay
19:05 karolherbst: mhh, I think they fixed a few bugs there
19:12 karolherbst: mupuf: okay, it's much more complicated than this, I remember now
19:13 karolherbst: there are some flags to tweak the way of how to down/up cock
19:13 karolherbst: *clock
19:13 karolherbst: and then you havea a few parameters to tweak it
19:13 karolherbst: for me it slowly reclocks until ~640MHz and then it jumps to the lowest
19:14 mupuf: well, of course it slowly downclocks, because the temperature remains constant
19:14 karolherbst: that wasn't what I meant
19:15 mupuf: make a bash script that forces the temperature to 95, then increase it to 98 for 200ms and back to 95
19:15 karolherbst: there is some kind of curve or so
19:15 mupuf: this way, you can single step :)
19:15 karolherbst: I can also just increase the interval to 2 seconds
19:55 tobijk: hey airlied with the pull request for 4.13 i get a new probe error: nouveau 0000:01:00.0: DRM: curs917a allocation failed: -16
19:55 tobijk: bisect points me to this commit: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=78f1ad6f655847411b36bda2b2acbd0648a03d5c
19:56 tobijk: card is GP106 btw
19:56 tobijk: is this already know or even fixed? :)
20:09 imirkin_: tobijk: already fixed
20:10 imirkin_: tobijk: https://github.com/skeggsb/nouveau/commit/59554a07143e461d287f19ef7749bafa811d2743
20:10 tobijk: imirkin_: ah k
20:10 tobijk: thx
20:13 airlied: skeggsb_: do i have that fix?
20:13 imirkin_: you do not.
20:13 imirkin_: i sent it out after you'd gone on vacation
20:13 imirkin_: and danvet suggested it wasn't worth worrying about for 4.12
20:15 tobijk: imirkin_: 4.12 -> 4.13? 4.12 was fine for me
20:15 danvet: small correction: not worth worrying about for me while airlied was on vacation
20:15 imirkin_: tobijk: the issue exists since 4.10
20:15 danvet: but still sounds like 4.13 material
20:16 imirkin_: tobijk: it's referencing random other data, which if it's not 0, will fail to allocate the cursor channel
20:16 imirkin_: tobijk: in your 4.12 build, that random data happened to be 0, and then get overwritten with the pointer. so all worked ok :)
20:16 tobijk: heh ok :)
20:16 imirkin_: danvet: right, sorry if i misrepresented your comments.
20:18 danvet: imirkin_, no worries
20:18 danvet: airlied, I think you just need to pick it up directly
20:18 imirkin_: ftr, this only affects GP102+
20:18 danvet: for more context on what I discussed with imirkin: I don't really want to make drm-misc the stop-gap for all not so greatly maintainer drivers
20:18 imirkin_: and only with displays (i.e. not the optimus-only ones)
20:18 danvet: seems to only train maintainers to do a bad job and cause confusion
20:19 danvet: hence drm-misc = small drivers officially maintained in there + core and across-drm stuff
20:21 airlied: and skeggsb_ is reliable though i now have to drive an hour to motivate him im person :-p
20:35 imirkin_: he said he was going to look at stuff in a few days
20:35 imirkin_: after he finishes the mesa stuff he's been working on
20:35 karolherbst: airlied: sounds like a solid plan
20:36 imirkin_: [in addition to looking at a few of the outstanding bugs]
20:40 karolherbst: mhh, maybe we should try to kind of work on the bugs ourself if possible, so he can take care of more of the merging and reviewing stuff? dunno, kind of the situation worries me a little bit right now
20:41 imirkin_: go ... work on the bugs ... :)
20:41 imirkin_: that's what i do when i can
20:42 karolherbst: sadly I don't have any desktop GPU here so I can't work on like most of the bugs
20:42 karolherbst: I should change that
20:42 imirkin_: well
20:42 imirkin_: i don't have the hw most of the time either
20:42 imirkin_: write patches, send them, get the person to test them, etc
20:42 karolherbst: ohh wait
20:43 karolherbst: that lspci I know of
20:43 karolherbst: this is the pci sysfs files being silly
21:10 karolherbst: hum, I thought I found the new volt table on pascal?
21:20 karolherbst: I think I will add support for TEMP_ALT_{VALUE,OFFSET} to nouveau and just read out this value on pascal, dunno if it makes much sense to do there a lot of parsing or so