00:22 imirkin_: mupuf: s-o-b is if you're in the maintainer chain
00:22 imirkin_: [for kernel]
00:23 mupuf: imirkin_: hmm, never seen that rule
00:23 mupuf: and we don't use it in i915, so maybe I just got confused
00:23 imirkin_: read what s-o-b means in the kernel
00:23 imirkin_: they have a document
00:25 mupuf: I see
00:25 imirkin_: https://www.kernel.org/doc/html/latest/process/submitting-patches.html#developer-s-certificate-of-origin-1-1
00:25 imirkin_: https://www.kernel.org/doc/html/latest/process/submitting-patches.html#using-reported-by-tested-by-reviewed-by-suggested-by-and-fixes
00:26 mupuf: ok, silly me, I wanted to say Reviewed-by all along, not S-o-b
00:26 mupuf: which should be a clear sign that I should not be reviewing shit to begin with
00:26 mupuf: well, bed time for me
00:26 mupuf: thanks ilia!
00:26 imirkin_: so e.g. ben slaps his s-o-b on it and sends it along to airlied, who would then put his s-o-b on it if ben were sending the patches along in email form
00:27 imirkin_: i guess the merge is an implicit s-o-b on all patches brought in via the tree.
00:28 imirkin_: i don't know all those details, since i'm not a super-maintainer.
00:28 mupuf: right
00:46 mupuf: oh, and to set the record straight, the rule for s-o-b is the same in i915, I just had a brain fart because I mostly work on other projects nowadays where I am the maintainer
00:47 imirkin_: :)
01:35 imirkin_: mupuf: still up?
01:35 imirkin_: if not, i can take a stab at replying to aritger
01:44 karolherbst: imirkin_: maybe you want to talk with Lyude before that? I know Lyude worked on Xwayland support through EGLStreams and I am sure also has something to say here? dunno, would make sense to me
01:44 imirkin_: karolherbst: about what?
01:44 imirkin_: fan control on fermi?
01:45 karolherbst: ahh right, wrong person... I was thinking about that device memory allocation, but that was jones...
01:49 karolherbst: imirkin_: *sigh* I just read his answer
01:52 karolherbst: and nobody should use LANG=C to begin with... let it just die
01:52 imirkin_: i use LANG=C
01:52 imirkin_: and i suspect that LANG=C is the default on the console.
01:53 karolherbst: doubtful
01:53 karolherbst: LANG=C is a fallback at most
01:53 imirkin_: it is for me.
01:54 karolherbst: yep, for me it is en_EN.utf8 on the console
01:54 imirkin_: in either case, whatever output a terminal has, it shouldn't affect the build system
01:54 karolherbst: right, it shouldn't, but depending on unicode doesn't sound wrong to me either
01:54 imirkin_: i don't mind depending on unicode
01:54 karolherbst: if somebody chooses to not use unicode I say it is their fault to do so
01:54 imirkin_: just don't depend on me having a multi-byte console output.
01:55 karolherbst: well LANG=C ain't unicode
01:55 imirkin_: LANG=C has nothing to do with the contents of the files
01:55 karolherbst: it still bitches around if you use unicode
01:55 imirkin_: no
01:55 karolherbst: well glibc that is
01:55 imirkin_: only if you try to display it to the screen
01:55 karolherbst: right
01:55 imirkin_: anyways... *somehow* make is able to make it work.
01:56 imirkin_: crazy, right
01:57 karolherbst: I am not saying that making LANG=C work is not good, but I am sure nobody will care that much anyhow. Following POSIX is right, but... I really don't want to think about "is this now compatible with LANG=C before I print it or not?"
01:57 karolherbst: for me supporting LANG=C sounds like a waste of time
01:57 karolherbst: that simple
01:57 imirkin_: i see.
01:57 karolherbst: the world moved on, utf8 should be the default
01:57 imirkin_: noted.
01:58 imirkin_: (you realize i could make the exact same claims with jsut a few minor things reversed, right?)
01:58 karolherbst: and I still get that unicode ain't easy and that there are devs not being able to implement their own unicode aware strlen and whatever
01:59 imirkin_: i see it much simpler though... any build system that has any dependency on my console output is broken-by-design
01:59 karolherbst: well, right, this is a different problem
01:59 imirkin_: nah, it's the same problem.
01:59 imirkin_: LANG should have no effect on build system output.
02:00 imirkin_: beyond the literal printing of any messages to mys creen
02:00 imirkin_: and i don't mind if they replace any unprintable chars with ? there
02:00 karolherbst: do you know what exactly depends on LANG here?
02:00 imirkin_: apparently their code is busted
02:01 imirkin_: in that they depend on the default python byte <-> char conversion logic
02:01 imirkin_: which in turn uses LANG
02:01 karolherbst: well perl just always checks LANG and LC_* stuff for example
02:01 karolherbst: mhhh
02:01 karolherbst: I am sure you can be explicit about the encoding being used and not depend on LANG there
02:02 karolherbst: depending on systemd default encoding is wrong to begin with, not just about LANG
02:02 imirkin_: yes, you can be
02:02 imirkin_: they just aren't
02:02 imirkin_: aka "their code is busted"
02:02 karolherbst: right
02:02 karolherbst: you should make a bug report :p
02:02 imirkin_: i could.
02:02 imirkin_: apparently they're aware and they don't care
02:02 imirkin_: they print a big fat warning
02:03 imirkin_: telling me that i'm wrong.
02:03 karolherbst: what kind of warning?
02:03 karolherbst: that LANG=C is silly?
02:03 imirkin_: "LANG must be set to utf8 or else"
02:03 karolherbst: they could just change it as long as meson runs......
02:04 imirkin_: as a result, i've lost all interest in that build system, and will do my best to prevent it from becoming the only option in any project i deal with.
02:04 karolherbst: okay, but then the issue isn't really about LANG=C, because maybe we have utf16 in the future or some other weird strange stuff nobody is able to come up with today
02:15 gnarface: LANG=C is the default if you debootstrap or do other types of minimal installs typically used for things like build environments...
02:16 imirkin_: or people who don't have a multi-byte-capable terminal emulator.
02:16 imirkin_: i'd be happy to move to like en_US.iso8859-1 or whatever
02:16 gnarface: unless you go through extended desktop setup steps, this is true for debian and all derivatives current and going back since the dawn of time
02:16 karolherbst: imirkin_: why can't you move to utf8?
02:16 gnarface: i imagine it's true for most other distros except if you're using a preconfigured full desktop image
02:17 imirkin_: karolherbst: aterm doesn't support it
02:17 imirkin_: and i've yet to find a terminal that has the same UX as aterm
02:17 imirkin_: (xterm and rxvt are both different)
02:17 gnarface: sounds like stupid curly-quote fetishism to me. build logs shouldn't have to be typographically correct at the expense of compatibility with ascii
02:19 imirkin_: it actually supports the curly quotes ;)
02:19 imirkin_: it has no problem with single-byte things
02:19 imirkin_: and for all i know, it'd be happy with e.g. utf16
02:20 imirkin_: but it definitely doesn't do utf8
02:20 imirkin_: with variable-width stuff
02:20 karolherbst: well... aterm should implement utf8 support. seriously
02:20 imirkin_: it's unmaintained
02:20 imirkin_: i've looked into it, didn't seem easy
02:20 imirkin_: (this was like ... heh. 15 years ago. i doubt it's gotten easier since then though.)
02:21 karolherbst: well, you would "simply" use icu
02:21 akochkov: imirkin_: but it has, I have Fedora 26, added Chinese locale recently, locale set to en_US.UTF-8, but still if I don't set LANG=en_US.UTF-8, a lot of programs output Chinese
02:22 karolherbst: also the aterm devs choosed to not support unicode to begin with, so even if they had a chance, they didn't do it
02:22 akochkov: aterm is dead, but you can check other, more modern terminals: https://gist.github.com/XVilka/8346728
02:22 karolherbst: well they kind of said that supporting unicode would make aterm slow
02:28 karolherbst: while would you report temperatures like this: 0x2d68 where the temperature is 0x2d.0x100/0x68
02:29 karolherbst: uhm
02:29 karolherbst: 0x2d.0x68/0x100
02:31 karolherbst: rhyskidd: would you mind adding support for 0x20460 in rnndb?
02:32 karolherbst: otherwise I just go ahead and to that
02:35 rhyskidd: sure, I'll clean up my rnndb patch for 0x20460
02:36 karolherbst: awesome, thanks :)
02:36 karolherbst: would be nice to being able to display the fractional part as well
02:36 karolherbst: but I doubt rnn supports that yet
02:40 karolherbst: rhyskidd: would be nice if we could put something like this into rnndb: ((val & 0xff00) >> 8) + ((val & 0xff) / 0x100)
02:41 karolherbst: or just declare the fixed point format?
02:41 karolherbst: dunno, just an idea for the future if somebody doesn't know what to do
02:41 karolherbst: either way, on my pascal I have a resolution of 0x8/0x100 for that sensors
02:43 karolherbst: which is 0.03125 C
02:43 karolherbst: weird. I can't print that little cirlce thing
02:44 karolherbst: silly IRC client
02:44 karolherbst: °
02:47 mangix: karolherbst: it's all about irssi
11:55 karolherbst: okay, I think I found the issue with the secure boot: those falcons come up in secure mode and we don't reset that state properly, so we can't grab the falcons and do stuff with those
11:56 karolherbst: after unloading nvidia I can poke into different regs and change their values. After boot/unloading nouveau I can't
12:00 karolherbst: gnurou: still around and do you have any ideas?
12:39 karolherbst: gnurou: maybe the sec2 firmware is borked in some way?
12:40 karolherbst: ... which would be a super painful situation
12:40 karolherbst: anyhow, acr_boot_falcon times out
13:11 karolherbst: uhm why does my falcon debugger work on the sec2 falcon loaded the acr image?....
13:12 karolherbst: like reading out regs and whatnot
13:12 karolherbst: but at least I know what is messed up now
13:13 karolherbst: mwk: where is that D[] mapped to in the mmio space? Or is that dmem stuff with the data uploaded to the falcon?
13:14 karolherbst: anyway, the image loops over something where D[someting] returns badfbadf
13:14 karolherbst: :D
13:14 karolherbst: sounds bad
13:14 karolherbst: is most likely bad for real
13:16 karolherbst: or maybe I can't read out that data space through that debugging interface
13:16 karolherbst: but regs are possible
13:28 mwk: karolherbst: D[] is accessible thru the data access regs at 0x1c0+
13:28 mwk: it's not directly mapped
13:32 karolherbst: okay
13:38 karolherbst: mwk: is there a nice way do dump an instruction through the debug register?
13:40 karolherbst: why can I break and step through that falcon running in LS mode ...
13:45 karolherbst: mwk: mhh, 0x180 and 0x184 seems to give me the full stuff
13:45 karolherbst: odd
13:48 karolherbst: mwk: okay, when I have the pc of the falcon, I think I can't just poke the pc into 180 and read the instruction back from 184. I still have to apply the base address somehow, right?
13:48 karolherbst: or not?
14:04 pmoreau: karolherbst: You seem to be having some fun with those falcons. :-)
14:04 karolherbst: kind of
14:09 mwk: karolherbst: it'
14:09 mwk: karolherbst: it's not a "base address", it's a page mapping
14:10 mwk: you can ask for virtual-to-physical mapping of $pc through reg 0x140 [VTLB opcode], then ask 0x180 for the returned phys address
14:10 karolherbst: I meant, that for the secure images, they usually start those with a base address. like first instruction is at 0x9700 not 0x0
14:10 karolherbst: ahh
14:12 karolherbst: mwk: mhh, I can't seem to poke anythong to 140
14:17 mwk: it's write-only
14:17 mwk: iirc
14:17 mwk: check if you get any result in 0x144
14:18 mwk: or, it might be that you're not allowed to touch it in LS mode...
14:23 karolherbst: or the result is 0
14:24 karolherbst: I am not allowed... most lilkely
14:24 karolherbst: but the hell
14:25 karolherbst: well at least I can't write to the regs...
14:27 karolherbst: I should rewrite that debugger in C... using bash becomes painful now
14:31 karolherbst: at least I don't depend on files providing the binaries now
14:39 karolherbst: mwk: I have some weird -1 offset problem I think...
14:40 karolherbst: ohh no, I just need that mapping I guess
15:21 karolherbst: okay, I think I narrowed it down enough
15:21 karolherbst: we don't get any answers from the sec2 falcon, I am 100% sure of this. Now the question: why
15:26 imirkin_: karolherbst: just a suggestion - the stuff you're adding to nouveau to figure that out - add it as nvkm_trace's
15:26 imirkin_: so that next time it's easier to diagnose
15:30 karolherbst: well, currently I don't really add anything
15:31 karolherbst: I will add new messages though after I understood what the issue is
15:39 karolherbst: wasn't there some reg to check the LS/HS/NS status of the falcons?
15:40 imirkin_: perhaps, but i haven't kept up
15:43 karolherbst: ahh +0x240
15:44 karolherbst: okay, sec2 is in LS mode. how convenient
15:58 karolherbst: but I doubt that this is the issue
15:58 karolherbst: it is something else
16:28 Lyude: mwk: re: meson for envytools: yeah?
16:30 karolherbst: Lyude: if it compiles faster than cmake + ninja :p
16:30 Lyude: it very well may, i haven't seen any concrete benchmarks
16:31 Lyude: it builds mesa pretty fast though
16:31 karolherbst: well meson ist fast due to ninja though
16:31 karolherbst: and because it skips a lot of configuring stuff
16:31 Lyude: yep
16:31 karolherbst: but cmake skips a lot as well
16:31 karolherbst: and can use ninja too
16:31 Lyude: karolherbst: tbh: the bigger thing I like about meson is that it's a non-tsl
16:32 karolherbst: tsl?
16:32 Lyude: everything feels a lot more consistent and predictable then cmake at times
16:32 karolherbst: ahh, right
16:32 karolherbst: well
16:32 Lyude: turing complete scripting language, meson doesn't have one
16:32 karolherbst: cmake was good prior meson
16:32 karolherbst: well. I did weird things with cmake already... so yeah
16:32 Lyude: yeah! I'm not saying it's a priority I just figured I'd mention it
16:32 karolherbst: well
16:33 imirkin_: until it can work on my system without funny workarounds, it's not a serious contender.
16:33 karolherbst: if you want to, you can, but there isn't much of a reason to do so
16:33 Lyude: imirkin_: does it not just work on your system?
16:33 imirkin_: nope
16:33 karolherbst: he uses an unmainteind terminal :p
16:33 Lyude: karolherbst: hehe, nah I don't have the time to myself
16:33 imirkin_: it requires a utf8 console.
16:33 Lyude: oh
16:33 Lyude: it is the future
16:33 karolherbst: right
16:33 imirkin_: which seems ridiculous for a build system to care about.
16:33 karolherbst: have fun
16:34 karolherbst: imirkin_: it doesn't care about the terminal encoding. I already told you yesterday
16:34 Lyude: more focused on getting clockgating working on kepler2 anyway :)
16:34 imirkin_: and yet ... it does.
16:34 karolherbst: it depends on the default encoding conversions done internally in python. It isn't really mesons fault that python depends on the terminal encoding here
16:35 imirkin_: no, it's meson's fault that it depends on python defaults.
16:35 karolherbst: that's right
16:35 imirkin_: it's python's fault that it *has* defaults - it shouldn't have them.
16:35 karolherbst: but it has nothing to do with the terminal or whatsoever per se
16:35 karolherbst: right
16:35 karolherbst: just like C or Java have
16:35 karolherbst: people did mistakes in the past
16:35 karolherbst: now we have to deal with those
16:35 imirkin_: and python2, for that matter.
16:36 imirkin_: it's a brand new mistake :)
16:36 karolherbst: :D
16:36 karolherbst: right
16:36 imirkin_: actually, hm. maybe py2 does have a default for str -> unicode
16:36 karolherbst: well the proper fix would be to pass those encodings parameters to the appropiate pythonc alls
16:36 imirkin_: not 100% sure how that works offhand.
16:36 karolherbst: I am sure py2 does the same
16:37 imirkin_: yeah, you might be right - e.g. str(unicode) will do *something*
16:37 imirkin_: you just never ever ever ever use it that way
16:37 imirkin_: because that's just crazy.
16:37 Lyude: I'm sure they'll accept patches :P
16:37 karolherbst: usually everything checks what the OS default encoding is and goes from there
16:37 karolherbst: which is odd, because windows uses UCS-2 aka utf16
16:37 karolherbst: so meson shouldn't run there as well
16:37 karolherbst: or does it?
16:37 imirkin_: Lyude: i don't have time to fix the world.
16:38 imirkin_: so i use my time to complain and hope that others agree with me
16:38 karolherbst: well UCS-2 != utf16 in a strict sense
16:38 karolherbst: because UCS-2 is fixed width
16:38 imirkin_: :)
16:38 karolherbst: but utf16 evolved from ucs-2...
16:38 imirkin_: no emoticons in UCS-2!
16:39 karolherbst: the more I talk about that stuff the more painful it gets
16:39 imirkin_: [actually there are some]
16:39 karolherbst: right...
16:39 imirkin_: and no linear-b script
16:39 imirkin_: how *did* people survive
16:39 karolherbst: we should create UCS-8
16:39 karolherbst: should be enough for everything
16:39 imirkin_: nah, there's UCS-4
16:39 Lyude: but I mean, how can you live without this https://lyude.net/~lyudess/tmp/Screenshot%20from%202017-11-22%2011-38-02.png
16:39 karolherbst: imirkin_: well you think it is enough today
16:40 karolherbst: people make those mistakes
16:40 karolherbst: Lyude: you can even call scripts that way and call those
16:40 Lyude: zsh doesn't support it unfortunately :(
16:40 karolherbst: file a bug
16:40 Lyude: yeah i've been on the fence about that
16:40 Lyude: it just seems like a silly bug, but it's also a bug
16:40 karolherbst: no clue why that should matter at all
16:41 karolherbst: eat a path, execute that path
16:41 karolherbst: that simple
16:41 Lyude: yeah
16:41 karolherbst: I am sure it is a silly bug
16:41 karolherbst: there are two valid bugs within unicode: 1. there is a bug inside icu 2. the dev used icu wrong or not at all
16:41 karolherbst: *regarding
16:42 karolherbst: allthough for executing a script, hyou don't even need icu....
16:45 imirkin_: Lyude: i'm so bad that i even have utf8-encoded files, and they just come out as ?????? when i ls :)
16:46 Lyude: hehe
16:46 imirkin_: i'm too lazy to rename them
16:46 imirkin_: the like 1 time per 5 years i need them, i pull up an xterm with a utf8 locale
16:48 karolherbst: uhm... why doesn't nouveau actually start the sec2 falcon. weird
16:49 karolherbst: ohh wait, I was wrong
17:00 Onionnion: Lyude: found you
17:02 Lyude: Onionnion: yo; when i get in the office I will give booting f27 on my fermi gpu a shot and see if I can reproduce the issue
17:02 Lyude: thinking it might be a silly issue I encountered right before 4.14 came out
17:03 imirkin_: what's the problem?
17:03 Onionnion: imirkin_: artifacts on screen, leading to eventual crash of the system
17:03 Onionnion: I'll reproduce and take pictures when I get home later as well
17:03 imirkin_: any additional info? like dmesg, xorg log, etc?
17:03 Onionnion: unfortunately no, sorry
17:04 imirkin_: or high-level system info
17:04 imirkin_: like GPU, X or Wayland, which ddx
17:04 Onionnion: Wayland on fresh F27 install with GNOME
17:04 Lyude: they're seeing it with wayland 4.13.13
17:04 Lyude: thinking it's the same silly atomic commit bug that I hit the other day on my kepler
17:04 Onionnion: I apologize for not having much information, but I can give whatever else may be needed later
17:04 imirkin_: that shouldn't lead to corruption though?
17:05 Lyude: imirkin_: i think it did
17:05 imirkin_: or can it? we were 1 behind on showing the framebuffer?
17:05 imirkin_: i guess that fb could now be getting overwritten by the next draw
17:05 Lyude: it was something weird like that, I know it did weird graphical thins
17:05 Lyude: *things
17:05 Lyude: right before it hung of course
17:06 Lyude: I'm sure if you hit it right out of a f27 install it will happen without much effort
17:06 Lyude: *reproduce
17:06 Onionnion: that's what happens with me
17:07 Onionnion: default F27 netinstall with GNOME into Wayland
17:07 imirkin_: Lyude: k, good to know
17:07 Onionnion: works for a little but, but slow, and then eventually artifacts and then hangs
17:07 Lyude: Onionnion: you don't have the computer in front of you right now right
17:07 Onionnion: I do not
17:07 Lyude: k
17:07 Onionnion: it's Nouveau code NV4C
17:08 Onionnion: specifically a Geforce 6150SE
17:09 imirkin_: gnome on C51 is not going to work out so hot
17:09 Onionnion: C51?
17:09 imirkin_: iirc that's the codename for nv4c
17:09 Lyude: it should still work though; the last time I checked it did
17:09 imirkin_: really? that's ... very surprising.
17:10 imirkin_: maybe it detects the suckage that's likely ahead and falls back to swrast?
17:10 Lyude: well yeah, I mean we're not just plain dropping all older cards :P, although I can't guarantee most of them work
17:10 Lyude: no, we don't need swrast just for fermi
17:10 Onionnion: for the record, it does work fine with a MATE install, but that's also with X11
17:10 Lyude: yeah, then that sounds like the bug I'm thinking of
17:10 imirkin_: Lyude: nv4c - pre-tesla. fermi = semi-recent DX11 gpu
17:10 Lyude: wait did you typo it Onionnion
17:10 Lyude: i thought you said nvc4
17:11 Onionnion: no I said NV4C
17:11 imirkin_: nvc4 = GF106, i.e. fermi.
17:11 Lyude: Oh.
17:11 imirkin_: nv4c = old.
17:11 imirkin_: i.e. not fermi :)
17:11 Lyude: yeah i do not have a nv4c and imirkin_ is totally right
17:11 imirkin_: but not ancient. nv4 without the c would be ancient ;)
17:12 tobijk: skeggsb: with 4.15rc0 is see memory "bugs" with nouveau and the new mm: https://hastebin.com/uyibasehur.vbs & https://hastebin.com/apisilereh.vbs
17:12 Lyude: (although if you have an old nvidia card to get off your hands...)
17:12 imirkin_: Lyude: happy to have stuff shipped to you if you like. they go for like $10 on ebay
17:13 imirkin_: (not the nv4c's, those are IGPs so are attached to motherboards, but other nv3x/nv4x boards)
17:13 Onionnion: yeah integrated
17:14 imirkin_: 6150SE's have an extra-special situation in that i think the DVI connector uses some external encoder that we don't support
17:14 Onionnion: this system is just VGA
17:14 imirkin_: some have a DVI connector
17:14 imirkin_: and a sil1374 encoder or something along those lines
17:14 imirkin_: er, SiI
17:14 Lyude: imirkin_: ooo
17:15 imirkin_: (i always think of it as "sil", but it's really "sii")
17:15 Lyude: i will have to just go through ebay and check if they're that cheap
17:15 imirkin_: Lyude: yeah, it doesn't really break the bank. that $10 covers shipping :)
17:16 Onionnion: for the record, I was just trying to revive this for my friend who wanted it just for writing and internets, and came across these issues in GNOME
17:16 Onionnion: but I can also just use MATE which works fine
17:16 karolherbst: or xfce
17:16 imirkin_: Quadro FX 3450 is a good one to search for - single slot, generally cheap, and 2 DVI ports.
17:16 imirkin_: [and no one bids on them]
17:16 Lyude: Onionnion: probably because that still uses the nouveau ddx
17:17 imirkin_: Lyude: https://www.ebay.com/itm/T9099-Dell-Nvidia-Quadro-FX-3450-256MB-DDR3-PCI-Ex16-Dual-DVI-S-Vid-Video-Card/302521611164
17:17 Lyude: I need to grab some old AMD cards as well and eventually actually get my irq rework submitted and upstream
17:17 imirkin_: from far-away marlborough, ma
17:17 Lyude: i'm in MA
17:17 Lyude: :P
17:17 imirkin_: i know.
17:17 imirkin_: and marlborough is not far from boston.
17:17 karolherbst: Lyude: I have some old AMD cards :p
17:17 Onionnion: I was just hoping to use GNOME for ease of use for her; she's not very savvy
17:17 Lyude: ah,. neat
17:17 Lyude: karolherbst: hrm, i should have you try some of those patches
17:17 karolherbst: well those are AGP cards
17:17 imirkin_: but it's probably easier to just have them ship it :)
17:17 Lyude: i hope I still kept them around
17:18 karolherbst: Lyude: one of those is even a powermac card with their fancy ADC port
17:18 Lyude: yep, looks like I did :). and karolherbst huh, I've never seen that port
17:18 imirkin_: i like how they say it has an s-video port, but really it's the 3-pin din connector for active 3d glasses
17:19 karolherbst: Lyude: it is basically DVI with some power so that you don't need a power cable for your display
17:19 Lyude: 3 pins, 3 dimensions? tomato tamato
17:19 karolherbst: but it wasn't enough to drive a 30" display
17:19 Lyude: lol
17:19 karolherbst: I think it provided like 5A max?
17:19 imirkin_: that 3-pin din port? it's not power
17:19 imirkin_: it's for vsync
17:20 karolherbst: imirkin_: ADC
17:20 karolherbst: uhh, just 4A
17:20 imirkin_: oh. one of YOURS. is ee.
17:20 karolherbst: yeah
17:20 karolherbst: Lyude: https://en.wikipedia.org/wiki/Apple_Display_Connector#Pin_3_and_11
17:20 karolherbst: I actually had to do this once
17:20 imirkin_: Lyude: oh, and another one to get is a NVS 280, which is a pci-express nv34.
17:21 imirkin_: but be sure you get one that comes with a DMS-59 cable included, otherwise it's less useful
17:31 karolherbst:is wondering if he should just use nvidias sec2 image....
17:31 karolherbst: apperantly they just write that into the falcon like they did prior maxwell2
17:35 mwk: Lyude: so, I tried to make a meson.build for envytools
17:35 mwk: but I run into a wall with converting cgen
17:36 mwk: I want to run a python module (ssot.gen_c) that will generate a .c and .h file from corresponding .py file in ssot/
17:37 mwk: in cmake, I just do 'python3 -m ssot.gen_c <args>', and tell it to execute it from the source directory; but with meson it seems there's no way to specify a working directory for a custom_target
17:38 mwk: or, for that matter, an environment variable (PYTHON_PATH would do the trick)
17:38 mwk: any suggestions?
17:43 karolherbst: mwk: any idea what falcon_base+0x370 might be?
17:43 karolherbst: uhm
17:43 karolherbst: +0x3c0
17:46 mwk: nope, sorry
17:49 karolherbst: mwk: any idea how to force a falcon to drop out of LS mode?
17:49 mwk: that's kind of a generic question, isn't it...
17:49 karolherbst: well, it doesn't matter if it looses the state or what else
17:49 mwk: tbh I have absolutely no idea about LS mode, all the falcons I've been messing with only had NS and HS
17:50 karolherbst: but it seems like nouveau can't really deal with the sec2 being in it's weirdo state
17:50 mwk: heh
17:50 karolherbst: PSEC2.UNK240 => { SEC_MODE = LS | 0x7020 }
17:50 mwk: in that case, punch PMC.ENABLE?
17:50 karolherbst: question is, what bit is for sec2...
17:50 imirkin_: that's documented
17:50 imirkin_: i'm like 99% sure
17:50 imirkin_: if not by nvidia, then in nouveau code by ben
17:50 karolherbst: PMC.ENABLE => { UNK0 | PIBUS | PCOPY0 | PCOPY1 | PFIFO | PGRAPH | PDAEMON | PUNK087 | PUNK084 | PVENC | PCOPY2 | UNK26 | BLG | PCOUNTER | PDISPLAY | 0x480000 }
17:51 imirkin_: maybe not in rnndb tho
17:51 mwk: PUNK087
17:51 mwk: rename it to PSEC2 while you're at it.
17:51 karolherbst: mwk: I am sure I tried that already... let me test something
17:51 karolherbst: mwk: variants are GM107- though
17:51 mwk: yes, and?
17:52 imirkin_: just coz it's written, doesn't make it so. also things get repurposed.
17:52 karolherbst: I am sure PSEC2 is there starting with gp102
17:52 mwk: I don't think so
17:52 mwk: I'm rather sure it's there on maxwells
17:52 karolherbst: mhhh
17:52 karolherbst: they don't use it then for secboot afaik
17:53 karolherbst: I don't think even gp100 uses it even if it is there
17:53 mwk: that's entirely possible
17:53 karolherbst: I try to check with the trace I have here
17:56 karolherbst: trying PUNK087 then
17:58 imirkin_: punk084 is vdec btw
17:58 karolherbst: mwk: what is the best way to know for sure?
17:59 mwk: well, punch the button, see if it works...
18:01 karolherbst: well, I just forgot, that nouveau can't put everything in a proper state alone anyway... messy. So Nvidia kind of needs to be loaded prior nouveau, otherwise nouveau won't do secboot correctly
18:01 karolherbst: but if I unload nouveau and load it again, it fails
18:02 karolherbst: well, what fails is that sec2 doesn't respond to the request to reset other falcons
18:02 imirkin_: the resetter has been reset!
18:02 imirkin_: who resets the resetter
18:03 mwk: the... master resetter of course
18:03 karolherbst: well, the PMU does something when nouveau gets removed
18:03 karolherbst: ...
18:03 karolherbst: because it makes sense to use the PMU for that
18:04 karolherbst: skipping that won't work either though
18:06 karolherbst: but with nouveau the sec2 also has this weirdo UC_CTRL value: PSEC2.UC_CTRL => { 0x40 }
18:07 karolherbst: uhm wait
18:18 karolherbst: now I am wondering if we just use nvidias PSEC2 image, because we don't overwrite it until nouveau does something on unload time
20:11 feep: hi!
20:13 feep: I'm trying to use nouveau on my ideapad z500 (gt645m, gk107) to do xrandr gpu offloading, but when I modprobe nouveau, I get "fb: failed to parse ramcfg data"
20:13 feep: I commented out the return in the kernel source to try and keep going, and it *works*, ie. renders at reasonable performance, but, rather expectedly, can't reclock
20:14 feep: (this is 4.14.1-gentoo)
20:22 feep: and then it hardlocked :D yay
20:25 feep: error and configuration is same as https://bugs.freedesktop.org/show_bug.cgi?id=91523
20:25 feep: anything I can add to this?
20:35 pmoreau: feep: Do you have the output of dmesg?
20:35 pmoreau: If it’s really the same bug, adding your VBIOs to the bug report could help.
20:36 pmoreau: If you are slightly unsure about it being the same bug, feel free to open a separate bug and mention the other bug in it; it is easy to merge two bug reports, but harder to split one bug report into two.
20:36 feep: pmoreau: I don't have dmesg with the error anymore, because I commented out the return in ramgk104.c:1577
20:37 feep: I'm something like 90% confident that it's the same bug, their hardware is identical to mine.
20:37 feep: output is different, but I think that's because his code is two years older
20:37 feep: er, his log
20:37 pmoreau: Oh right, I only had seen the chipset in the other bug report, but you have the same laptop model as well. :-D
20:38 feep: yep ^^
20:38 pmoreau: Yeah, in that case, even the VBIOS might not be useful, as it should be the exact same
20:39 pmoreau: You should add yourself to the bug report, on the CC list. Might want to say you are still hitting that with 4.14, and give some new logs.
20:40 pmoreau: karolherbst: ^ Any idea on it? I guess the ramcfg data is used for training and reclocking the RAM?
20:40 karolherbst: interesting
20:40 karolherbst: yeah, memory reclocking
20:40 pmoreau: :-D
20:40 feep: also vbios is identical, yeah
20:41 karolherbst: I could try to get a look tomorrow
20:41 feep: was a bit confusing to start, different md5sums, but it's just cause mine has a few more zeroes at the end
20:41 feep: karolherbst: that'd be awesome :D
20:43 karolherbst: Lyude: did you find some time to test my mmiotrace patch?
20:44 feep: added myself to the bug~
20:47 karolherbst: feep: if you find some time, could you make an mmiotrace running the nvidia driver (even through bumblebee would be fine)? Chances are, that some reverse engineering will be required to figure out what we have to do
20:49 pmoreau: feep: Posting a comment does not automatically add you to the list: you need to do that manually! Look at the CC list, there is still only the reporter in it. ;-)
20:49 feep: oops! thanks
20:49 feep: hm, I was thinking to just spam the kernel module with printks to see where it bails
20:49 pmoreau: Many do the mistake, that’s why I checked.
20:50 feep: but if mmiotrace is more useful, I can do that
20:50 pmoreau: s/do the/make the
20:59 Lyude: karolherbst: building a kernel right now to test it
21:05 feep: okay, added nvkm_warn up the wazoo, brb reloading nouveau
21:17 Lyude: ugh, nvidia's driver remains such a huge pain to setup for anything
21:17 imirkin_: i don't think i've run it in the last like 2 years :)
21:17 Lyude: heh, I try to avoid it but sometimes I need to grab a trace or two
21:17 imirkin_: i always feel a little bad when i ask others to do traces for me
21:17 imirkin_: but not as bad as i would running it myself
21:20 oday: So, whatever I do, I can't get my vm to see this Optimus gpu as a vga compatible device
21:21 imirkin_: is it a 3d controller?
21:21 oday: Yes, obviously
21:21 imirkin_: iirc you can write something to make it vga
21:21 imirkin_: hold on
21:22 imirkin_: nvapeek 88008
21:22 imirkin_: that should have 0301 in the top bytes?
21:22 oday: Sec
21:29 oday: 0302
21:29 imirkin_: er right
21:29 feep: yo
21:29 imirkin_: for some reason i always think it's 0301
21:30 imirkin_: oday: what's the full value?
21:30 oday: Just rebooted into another kernel, sec
21:30 imirkin_: ok, well, the next step would be
21:30 feep: if I'm reading this right, timingEe bails because *cnt is 12, but rammapSp (ver=0x11) says ramcfg_timing = 15
21:30 imirkin_: to replace the 02 with 00 and nvapoke it back in there
21:31 feep: hence out of bounds
21:31 imirkin_: which will hopefully make it report itself as a vga controller
21:32 oday: Got an acpi error while booting for some reason
21:32 oday: But yeah, that worked
21:32 oday: Ty
21:34 oday: Btw, what I'm trying to do is to pass the gpu to a vm and connect to the vm using something like xvnc
21:34 oday: With -vga none
21:34 imirkin_: should work in theory
21:34 oday: That doesn't work by itself
21:34 feep: is the nvidia bios documented anywhere?
21:34 Lyude: karolherbst: ergh, I'm going to have to do a fedora kernel rpm build just because of akmod being annoying and requiring a relevant dep package be installed :(
21:35 imirkin_: feep: define 'documented'
21:35 oday: feep: hahahahaha
21:35 feep: not promising, that laugh
21:35 imirkin_: feep: the DCB is documented on nvidia.com somewhere, but that's not what you're interested in
21:35 feep: I'm wondering if I should just ignore the oob check and hope it works out
21:35 imirkin_: the rest of the documentation is what we've RE'd
21:35 imirkin_: which is split between nvbios and the nouveau kernel driver
21:35 imirkin_: unfortunately those 2 don't always agree
21:35 imirkin_: when in doubt, i tend to trust the kernel driver more
21:36 feep: what's nvbios as a separate project?
21:36 imirkin_: https://github.com/envytools/envytools/tree/master/nvbios
21:36 imirkin_: it's just a utility that parses these things
21:37 feep: can you paste the clone url please? I'm in console
21:38 feep: links and github is being unhelpful :p
21:38 imirkin_: just remove the /tree/master/... stuff
21:38 imirkin_: you can git clone https://github.com/envytools/envytools
21:38 feep: thanks
21:39 imirkin_: not sure how they make it work
21:39 imirkin_: probably based on the user-agent
21:39 imirkin_: or some equivalent hack
21:39 imirkin_: you can also append a .git to the end
21:40 feep: got it
21:42 oday: Ohh wait
21:42 oday: Wrong gpu
21:42 oday: Turns out
21:42 oday: It did not work
21:42 oday: So nvapeek gives 030200a2
21:43 oday: But when I do nvapoke 88008 030000a2
21:43 oday: It does nothing
21:43 imirkin_: nvapeek 2x after that
21:43 imirkin_: sometimes you have to explicitly "post" it
21:43 imirkin_: not sure if you do for those pci regs tho
21:44 oday: A second nvapeek shows that the value has not been changed at all
21:45 oday: I'm not making some stupid syntax mistake, right?
21:45 imirkin_: well
21:45 imirkin_: it was just a theory that it was writeable :)
21:45 oday: rip
21:45 imirkin_: it probably is -- just not that way
21:46 imirkin_: maybe something at 8c000 somewhere. dunno.
21:47 oday: That's 00000002
21:48 mwk: what are you trying to do?
21:49 oday: Make my vm think my optimus gpu is a vga compatible device (030000) when it is actually a 3D controller (030200)
21:50 mwk: and what GPU is that?
21:51 mwk: the pci class is controlled by straps set #1 bit 4 on G80+ devices, FWIW
21:51 mwk: by overriding that, you should be able to change the class
21:52 oday: 960m (gm107)
21:54 oday: My actual goal is to use it, passed through, to provide graphics acceleration to my vm, to which I will then connect via vnc or something similar
21:54 oday: So I'm trying to make it look like it's a vga compatible device then look at what goes wrong
21:55 mwk: hmm, shouldn't a 3d controller work just as well for that purpose?
21:55 oday: It did not
21:55 mwk: and what went wrong?
21:55 oday: Let me pastebin some error logs
21:58 feep: also after a certain number of nouveau reloads my kernel panics :D
22:01 Onionnion: Lyude: so do you think this may be fixable for this chipset or nah?
22:01 Onionnion: np if not
22:02 Lyude: Onionnion: maybe, but it's unlikely that anyone's going to put the time into it unfortunately
22:02 Onionnion: figured
22:02 Onionnion: I'm hoping I can find my really old AMD GPU somewhere to throw in
22:03 Onionnion: a Radeon HD 2600 XT
22:03 Onionnion: old pos
22:03 oday: This will take a while (because I managed to break my vm in between reboots, restoring from an earlier snapshot right now)
22:04 feep: anyone here know how the timing mapping table in nvbios works?
22:04 oday: So just a pacstrap plus 100mb copied, not that huge of a deal
22:04 feep: entry 0 index 1 has a 0xf in it that makes no sense, because there's only six timing table entries, the rest are 0000
22:05 imirkin_: feep: how big is that value? is it 4- or 8-bit?
22:05 imirkin_: oftentimes 0xff is used to indicate "invalid" for 1-byte values
22:05 feep: no it's 0x0f
22:05 feep: but it's plausibly a 4-bit value
22:06 imirkin_: would require some research
22:06 imirkin_: we have a vbios database
22:06 feep: oh, should I grab a working one and compare?
22:06 imirkin_: not about working vs not
22:06 feep: got anything working similar to a gt 645m?
22:06 imirkin_: more like "what kind of data do they stick in there"
22:06 feep: yeah
22:07 feep: I mean as in "successfully interpreting"
22:07 imirkin_: since this thing has to work for *all* vbios's
22:07 oday: Techpowerup?
22:07 oday: That's the only database I managed to find
22:07 imirkin_: we have a private one.
22:07 oday: oh
22:07 imirkin_: with people's contact info in case we need ... more info
22:07 imirkin_: (which is why it's private)
22:08 oday: I see
22:08 feep: oh~ got anything similar to a gt 645m?
22:08 imirkin_: i don't have access to it from here... perhaps someone else can cehck?
22:08 imirkin_: what is that, GK107?
22:08 feep: yep
22:08 karolherbst: imirkin_: I will take a look tomorrow
22:09 oday: Is there an MXM GM107?
22:10 feep: well, I don't have anything else to do toevening, so
22:10 feep: :D
22:11 feep: hm, none of the bioses on techpowerup work with nvbios :(
22:11 feep: well, none of the two I tried so far
22:12 imirkin_: yeah, those bioses have weird headers/footers
22:13 feep: hm, the M ones may be working. 500 is too old tho
22:13 imirkin_: 500 is fermi
22:13 imirkin_: 600 is kepler
22:13 imirkin_: (usually)
22:14 feep: augh, those are all version 10, even the 670 :(
22:15 imirkin_: you want newer or older version?
22:15 feep: a working one with a type 0x11 timing mapping table would be nice
22:15 feep: idk which those are :(
22:15 imirkin_: try 770 and 780 ti
22:15 feep: kay~
22:17 oday: Oh, here we go
22:18 oday: I did xinit with only the nvidia gpu passed through
22:18 oday: With ssh
22:18 oday: It just hanged right there
22:18 oday: And I have no output so I don't know what's going on
22:18 oday: I can try sshing, but as soon as I enter the correct password
22:19 oday: The ssh process itself hangs
22:19 feep: don't parse afaics
22:20 oday: Btw, my ultimate goal here is pretty much to pass my gpu to a Windows vm with nvidia drivers, and then connect to said vm with rdp/moonlight
22:20 oday: rdp with remotefx is fast enough
22:21 oday: When I do that right now, I get a code 43
22:21 oday: Which is about as descriptive as "something went wrong"
22:21 feep: I'll just force 0xf to 0x0 and see what happens
22:23 feep: okay, well, it _loaded_. no errors so far.
22:26 feep: pshw
22:27 feep: that seems to have worked :D
22:34 oday: I'm actually not sure about how to do this
22:34 oday: As in, get the output of my passed through Optimus gpu from xvnc
22:35 oday: xrandr --listproviders while connected via vnc gives me providers: 0
22:35 oday: While nouveau is loaded and has initialized the gpu
22:42 tobijk: oday: imho prime is not usable with vnc
22:42 tobijk: s/vnc/ssh/ don't mind me :D
22:43 oday: Prime isn't what I'm trying to do though
22:44 oday: I'm trying to have the optimus gpu be the sole provider
22:45 feep: switching to X
22:52 feep: if I just skip the entry with the invalid offset, reclocking works~
22:55 tobijk: yeah, you just have less entires
22:55 tobijk: the other entires are ok
22:57 tobijk: feep: how many entries do you have in your pstate?
22:58 tobijk: keper tends to have 3+
22:58 tobijk: *kepler
22:58 feep: three, but one is labelled "AC" and I can't activate it
22:58 tobijk: AC is the current one
22:58 imirkin_: you can probably guess what that one is...
22:59 feep: > AC: core 0 MHz memory 0 MHz
22:59 imirkin_: (hint: unplug the power adapter)
22:59 imirkin_: that means it's off.
22:59 feep: I .. assure you it's on, given it's rendering a game rn
22:59 feep: owait no it's not, hang on
22:59 feep: rechecking
22:59 tobijk: so feep, you likely dont have 0xf?
22:59 feep: I do, I have 0x7 and 0xf
23:00 tobijk: ok then 0xe or similar is missing
23:00 feep: okay yeah, AC is current, thanks
23:00 tobijk: heh and gone
23:00 feep: hm, trying to switch to 07 didn't work
23:01 tobijk: feep make sure the card is on
23:01 tobijk: run glxgears or so on it :)
23:01 feep: owait yes it does, and yeah, it only works when the game is foregrounded or so it seems
23:01 feep: if I background it, the gpu goes off after a moment
23:01 feep: that's neat~
23:01 tobijk: uhm that should not happen for glxgears
23:02 tobijk: maybe for a "better" game
23:02 feep: I'm running stalker shadow of chernobyl fullscreen :P
23:02 tobijk: feep, just run glxgears
23:02 feep: but I wanna kill monsteeers
23:02 feep:glxgears
23:02 tobijk: (for reclocking purposes)
23:02 feep: yep, switching works
23:02 feep: between those two~
23:02 tobijk: other than that, kill as many monsters are you want :D
23:03 feep: :)
23:03 feep: oh and now sensors work too!
23:04 tobijk: feep, did you provide your vbios already? (havent followed the discussion)
23:04 feep: tobijk: it's in the bug report, the original poster has the same laptop
23:04 feep: anyway yeah, I have 810Mhz and 1800Mhz memory clock, and I'm pretty happy with those options~
23:05 tobijk: feep: oh so basically the same as my 640m did
23:05 tobijk: yeah you are missing 0xe :)
23:05 feep: makes sense for a 645m :)
23:05 feep: what's 0xe?
23:05 tobijk: the performance state in between :D
23:05 feep: ooh.
23:05 feep: well, it is a mystery.-
23:05 feep: I don't think it's that faulting first one either.
23:06 feep: I have four entries, one is disabled due to patch
23:06 feep: three seem valid
23:06 feep: tobijk: can I have your bios please, to compare?
23:07 tobijk: yeah, sec, have to get it out of the old files (i dont have the system with the 640m anymore)
23:09 tobijk: feep: https://homepages.thm.de/~tjkl80/vbios.rom
23:10 feep: tobijk: ... and that works with nouveau? :o
23:11 tobijk: feep: yep it did when i had the system (incl. manual reclock)
23:11 feep: wtf.
23:11 feep: you have the same weird 0xf as I do
23:14 tobijk: feep: isnt the entry size wrong?
23:14 tobijk: maybe the 0xf (at the end?) is a dummy entry
23:15 tobijk: guessing wild here :)
23:15 feep: I'mma just grab a diff
23:17 feep: I don't see any significant differences.
23:17 feep: of course, I also have p much no idea what I'm looking ati
23:17 feep: at*
23:18 feep: tobijk: https://gist.github.com/6fb83fd7a2242a24720da2eb9337e4e0 diff, you to me
23:19 feep: nothing significant jumps out.
23:20 tobijk: which one is yours?
23:20 tobijk: the base?
23:20 feep: you base, me target
23:20 imirkin_: feep: "diff -u" is easier to parse.
23:20 feep: kay
23:21 imirkin_: not that it *realy* matters
23:21 tobijk: yeah inline is always better
23:21 feep: diff -u https://gist.github.com/17eba1ef5097465812ac746fb2239924
23:21 feep: my bios is four days younger :D
23:22 imirkin_: and you have a lot more empty DCB entries
23:22 feep: how is ramcfg determined?
23:23 feep: erm, ramcfg_index*
23:23 imirkin_: more importantly, you have a mem_voltage gpio
23:23 feep: or rather, what does it mean?
23:33 tobijk: imirkin_: actually he doesnt, he got the GPIO 9: line 9 tag 0x80 [???] OUT DEF 0 gpio: normal
23:33 tobijk: which could be the same
23:33 imirkin_: +GPIO 17: line 17 tag 0x18 [MEM_VOLTAGE] OUT DEF 0 gpio: normal
23:34 tobijk: yep that is my vbios :)
23:34 tobijk: the working one
23:34 imirkin_: you're -
23:34 imirkin_: he's +
23:34 tobijk: whoops :D
23:34 tobijk: ok
23:40 tobijk: this looks odd https://hastebin.com/wawiyesuwu.pl
23:40 tobijk: second one looks like its ment to be 81250 as well