00:00 karolherbst: I think above 2.5GHz real clock?
00:01 karolherbst: basically 0-1.5GHz single, 750MHz-3GHz double and 2.5GHz- quad or something like that
00:02 karolherbst: RSpliet: there is a 100MHz margin where even the double rate mode with gddr5 is really unstable, which is near the transition. Even with nvidia the GPU crashed
00:03 karolherbst: I think basically 1.1 to 1.2 GHz is pretty much unusable in DDR mode
00:07 RSpliet: I never looked into that in great detail
00:08 RSpliet: but what you refer to is the transition from simple divider-based clocks to PLL-generated clocks
00:08 karolherbst: but I hope they won't have a driver without those coolbits ...
00:08 karolherbst: well why do I even bother, it will take until 2018 before we get the right PMU firmare to even think about memory reclocking :D
00:08 RSpliet: and it could well be that the range of that PLL is from 1,3GHz onward or sth...
00:09 karolherbst: yeah, most likely
00:09 RSpliet: I don't think we change between SDR and DDR on any memory chips atm
00:09 karolherbst: maybe we do without knowing it
00:09 karolherbst: skeggsb: any ideas?
00:10 karolherbst: RSpliet: but wouldn't SDR mode give us some power savings?
00:10 skeggsb: we copy what nvidia does, beyond that, no idea
00:11 karolherbst: yeah okay, as I thought
00:11 karolherbst: so if nvidia change, we change too
00:11 karolherbst: *changes
00:17 huelter: OK, I can't find another similar case on google, so here it goes: I'm using an nvidia card with nouveau and passing sound via HDMI. It works, but the problem is that when I connect a second monitor on the card, on another HDMI port, the sound comes on BOTH monitors. Alsa seems to not recnognize different outputs: http://pastebin.com/PMMMQqNk. I'm using gentoo, don't know if that's relevant.
00:18 imirkin_: that pastebin seems to indicate that alsa *does* recognize the diff outputs
00:18 imirkin_: er wait,
00:18 imirkin_: that's on the intel. nevermind
00:18 huelter: yep
00:18 huelter: 3 cards at the same time, quite a mess
00:19 imirkin_: well, there's definitely only 1 HDA device. but we could (and should) create multiple sub-devices as intel has done
00:19 imirkin_: but we quite clearly don't
00:19 imirkin_: i know ~nothing about this though
00:19 huelter: what's interesting is that on fedora all is working well
00:19 huelter: so nouveau might not be the culprit
00:20 imirkin_: maybe it was broken/fixed?
00:20 imirkin_: this is a kernel thing
00:20 imirkin_: or could be that fedora has some local patches that never made it upstream
00:20 imirkin_: (bad skeggsb)
00:20 huelter: yea, someone on #alsa said there was someone on gentoo with the same problem, they found something missing
00:21 huelter: google has nothing on the subject sadly
00:21 imirkin_: can you find the list of patches applied to a fedora kernel?
00:21 imirkin_: ah nm, found it
00:21 imirkin_: http://pkgs.fedoraproject.org/cgit/rpms/kernel.git/tree/
00:22 imirkin_: nothing nouveau-related in there though
00:23 huelter: quite a mistery
00:28 imirkin_: skeggsb_: know anything about this multi-hdmi-port business as it relates to audio sub-devices?
00:29 huelter: sec, testing new kernel
00:31 huelter: imirkin, found what was missing
00:32 huelter: CONFIG_SND_DYNAMIC_MINORS needs to be set, so that I can have more than 8 sound cards
00:32 huelter: enabling it make aplay show 9 devices
00:32 imirkin_: lol
00:33 imirkin_: first world problems? :)
00:33 huelter: yea... but I had the nvidia card, intel gpu and a usb headphone
00:33 huelter: having many outputs bumped the number of sound cards
01:37 karolherbst: meh, nobody got a pascal vbios for me, how disappointing
05:01 imirkin: skeggsb: how would you interpret http://hastebin.com/oxatududep.css ?
05:02 imirkin: skeggsb: m2mf error coz of ctxsw timeout, or ctxsw timeout coz of m2mf error?
05:03 imirkin: as a separate manner, what could MULTIPLE_WARP_ERRORS be an indication of? the "warp" is always xx0014.
05:03 imirkin: matter*
05:20 skeggsb: imirkin_: i'd probably say it's either a) m2mf errors a result of something going funny after killing the channel, or b) completely unrelated to each other
05:20 skeggsb: how'd you trigger them?
05:23 skeggsb: imirkin: replied to your _ variant btw :P
05:24 imirkin: the variant who doesn't idiotically run a game *twice* on the machine, knowing full well even beforehand it'll hang the box?
05:24 skeggsb: he probably just runs different games ;)
05:24 imirkin: skeggsb: triggered by running F1 2015
05:29 imirkin: so the basic claim is that somewhere i have LINE_LENGTH_IN * LINE_COUNT != number of words submitted?
05:29 skeggsb: yeah, apparently
05:30 imirkin: that's quite the claim
05:32 imirkin: we don't exactly do p2mf in a lot of places...
05:33 skeggsb: this is all *assuming* that the error codes haven't changed since, what, fermi..
05:34 imirkin: well, in gk20a it's similar
05:35 imirkin: gr_memfmt_hww_esr_extra_inline_data
05:35 imirkin: while the next bit is gr_memfmt_hww_esr_missing_inline_data
05:37 pmoreau: skeggsb: Would you have some time to review https://lists.freedesktop.org/archives/nouveau/2016-April/024687.html and https://lists.freedesktop.org/archives/nouveau/2016-May/024902.html please?
05:37 imirkin: i wonder if i need something for NVF0_P2MF_CLASS there... http://hastebin.com/vefizefana.pl
05:38 skeggsb: pmoreau: i've got it on my list
05:39 skeggsb: imirkin: it's already bound by default
05:39 imirkin: skeggsb: i guess i should be sticking a0b5 for nvf0 and b0b5 for maxwell, no?
05:39 imirkin: skeggsb: how so?
05:40 pmoreau: skeggsb: Ok, thanks!
05:40 skeggsb: imirkin: host (PFIFO) handles the copy engine class magic for gr channels
05:41 imirkin: skeggsb: ah ok
05:41 skeggsb: this is as of kepler, btw
05:41 imirkin: right, so that if (kepler) thing is unnecessary as well?
05:41 skeggsb: yeah, in theory
05:41 imirkin: :)
05:41 imirkin: you sound confident
05:42 imirkin: anyways, i suspect we would have noticed by now that we were doing it wrong
05:42 skeggsb: always ;)
05:42 imirkin: i guess it really could be X that's doing it...
05:42 skeggsb: it certainly doesn't *hurt* to do it "the right way", who knows if the hw will change at some point to care again
05:43 skeggsb: nvidia still do it "properly"
05:44 skeggsb: should *actually* be making sure the copy class is allocated via the kernel too, for if/when some day we get around to powering off unused parts
05:46 imirkin: hm, well X appears to only ever use copy for kepler, no p2mf
05:47 imirkin: oh seriously?? gr. in the header we have: PUSH_DATAu
05:48 imirkin: but never with an unbounded argument...
05:50 skeggsb: hm, i wonder what happens if you hit a NOUVEAU_FALLBACK() in say, NVC0EXAPictTexture..
05:50 imirkin: yeah
05:50 imirkin: but ... not too much data
05:50 imirkin: only not enough data
05:50 skeggsb: well, depends what comes after it
05:51 imirkin: oh hm, good point
05:51 imirkin: it does set it up for "n" dwords, and then you have a runaway thing
05:51 skeggsb: yeah
05:52 imirkin: it'd have to be a damn lucky command that comes next though
05:52 imirkin: since it'd have to get the channel/mthd right
05:53 imirkin: (and high bits)
05:53 skeggsb: indeed
05:54 imirkin: of course watch it be 0x3f800000 or something :)
05:54 skeggsb: it's a bug, in any case - even if it's not this one
05:54 imirkin: separately, any idea about the multiple warp errors? i get oodles of them when the game is starting, with apparently no ill visible effect
05:55 skeggsb: what's the whole error?
05:57 imirkin: skeggsb: http://hastebin.com/fihoxuzuda.sm
05:57 imirkin: note that it always just says X for me btw, not the actual app name
05:57 imirkin: been that way for a few kernels
05:58 airlied: dri3
05:58 skeggsb: (the 0x14)
05:58 airlied: since X now opens the socket
05:58 airlied: ^socket^device
06:00 imirkin: ooooh
06:00 imirkin: mask divergent
06:00 imirkin: that sounds like something i don't know jack shit about
06:00 imirkin: and could easily have messed up
06:00 skeggsb: ignore the mask, the register name is all up until _DIVERGENT
06:00 imirkin: who's wearing these masks, and why are they diverging?
06:00 imirkin: ah ok
06:00 skeggsb: not that that's any more helpful
06:01 imirkin: on wait no, that could make sense
06:01 imirkin: reporting diverging control flow
06:01 imirkin: without a joinat
06:01 imirkin: or some shit like that
06:05 imirkin: skeggsb: could you add those error codes into our decoidng logic?
06:05 skeggsb: that's going to make my eyes bleed from staring at gk20a headers :/
06:05 skeggsb: but, sure
06:06 imirkin: which header was that in? i didn't see it
06:06 skeggsb: hw_gr_gk20a.h
06:06 skeggsb: register 419e44 - it's not the register we read the code from, but it's the enable bits for each code
06:06 imirkin: oh, got it
06:06 skeggsb: seemed to match up with our list anyway
06:08 imirkin: yep, thanks
06:19 skeggsb: imirkin: how's that?
06:20 imirkin: i meant - found it in the gk20a headers :)
06:20 skeggsb: oh, i meant, "how's the patch i just pushed"
06:21 imirkin: skeggsb: very similar to the rnndb patch i was about to push :)
06:24 imirkin: skeggsb: thanks for taking care of the nouveau end of it
06:24 imirkin: should be helpful next time we run into weird errors :)
10:16 hussam: imirkin: hi. you suggested I use DRI 3 the other day. It causes Xorg to crash on switching TTY.
10:42 mwk: huh, LTO support is free if you get clang and lld working
10:42 mwk: I like this thing
11:29 karolherbst: skeggsb_: if you got time for two small patches, could you talke a look over the two first commits of my hwmon branch? I sent the patches out to the ML a month ago
11:30 karolherbst: skeggsb_: they just add support for in_min and in_max in hwmon
11:34 mwk: alright
11:34 mwk: I'll need to write more tests for it, but I think the LLVM Falcon v3 support is now complete for assembler and disassembler
11:34 karolherbst: yay :)
11:35 mwk: and lld is usablish if you don't need overlays, though you need a custom linker script
11:37 mwk: next step: codegen
11:37 mwk: or maybe hwtest, it'd be good to ensure all these instructions actually function as expected
11:41 karolherbst: ohh
11:41 karolherbst: more error codes: https://github.com/skeggsb/nouveau/commit/1c916b61fb9a9c452527471b5f19b3f71d0f9616
11:41 karolherbst: that's nice
11:43 karolherbst: skeggsb_: your branch doesn't compile :p
11:43 karolherbst: skeggsb_: there is a dot: https://github.com/skeggsb/nouveau/blob/1c916b61fb9a9c452527471b5f19b3f71d0f9616/drm/nouveau/nvkm/engine/gr/gf100.c#L978
12:32 karolherbst: anybody found a way how to fake the device id on nvidia gpus?
12:53 mwk: yeah... there are a few
12:54 mwk: which device id though?
12:57 karolherbst: mwk: I wnat to fake it to a quadro k4000m
12:58 karolherbst: 11BD
13:00 karolherbst: mine is 11E0 I
13:00 karolherbst: ..
13:01 karolherbst: 11FC would work too (Quadro K2100M)
13:01 karolherbst: ohh wait, k4000m is gk104, I should better use 11fc then
13:02 mwk: in that case, read about straps
13:02 mwk: but do note that nvrm checks for attempts to fake IDs
13:02 mwk: so it won't work
13:04 karolherbst: what do you mean?
13:12 mwk: there are registers that you can use to fake the pci device ID
13:12 mwk: but nvidia driver checks whether you messed with them
13:12 mwk: and if so, restores the original value
13:12 karolherbst: ahh
13:12 karolherbst: okay
13:12 karolherbst: so I can only mess with it while nvidia is unloaded?
13:13 mwk: you can mess with it anytime, but nvidia will see through the lie
13:13 mwk: so marking your card as a Quadro serves little purpose
13:13 karolherbst: mhh
13:14 karolherbst: I just want to enable those software features
13:14 karolherbst: like nvidia-smi stuff
13:14 mwk: and that's exactly what nvidia wants to prevent
13:15 karolherbst: so you say ther is no way to achive that
13:16 mwk: you can have fun disassembling the driver and patching the right instruction
13:17 mwk: but, no way that I know of
13:18 Lekensteyn: Moving the cursor on an external DP monitor corrupts the cursor and more (reverse PRIME, GTX965M, 4.7-rc1, mesa 11.2.2) https://lekensteyn.nl/junk/nouveau-corrupt.jpg
13:18 karolherbst: mhh
13:18 Lekensteyn: any pointers for debugging this?
13:31 pmoreau: Lekensteyn: It could just be that your card is clocked too low to power an external screen fluidly
13:32 pmoreau: s/an external screen/more than one screen
13:32 Lekensteyn: pmoreau: the primary display is driven by intel, so nvidia only has one monitor to work with (Optimus laptop)
13:32 Lekensteyn: does that explain corruption that sticks around? only a small area needs an update
13:33 pmoreau: Hum… Is it a big screen?
13:33 Lekensteyn: 2560x1400, but the issue persists when I change it to 1920x1080
13:34 Lekensteyn: this laptop also provides a BIOS option to switch between discrete only and hybrid graphics, if I change it to discrete, then the cursor corruption issue is gone
13:34 pmoreau: Probably not then… you could have a try with the blob, see which clocks it uses at idle with that external monitor.
13:35 pmoreau: So if you switch to discrete, the corruption is gone, even though the NVIDIA card drives both screens? Or you mean you had no corruption on the internal one, but didn’t necessarily tried with an external one in that case?
13:36 karolherbst: PCiE bottlenecked most likely
13:36 karolherbst: allthough it shouldn't lead to corruptions
13:36 Lekensteyn: no corruption on the external DP-1 and internal eDP-1 screen in discrete mode
13:37 Lekensteyn: would it help to try lower resolutions/refresh rates?
13:37 karolherbst: Lekensteyn: did you try to reclock your gpu and check if that helps?
13:37 pmoreau: Weird…
13:37 Lekensteyn: karolherbst: nope I did not, I have no idea where to start investigating this issue
13:37 pmoreau: Isnt’t 965M a Maxwell v2?
13:37 pmoreau: Or is that a v1?
13:37 karolherbst: it is v2
13:37 karolherbst: but pcie and engine reclocks still work
13:38 Calinou: is GTX 960M Maxwell v1 or v2 by the way? (my laptop's graphics card)
13:38 karolherbst: v1
13:38 pmoreau: Oh, okay. Even memory reclocking?
13:38 Lekensteyn: by v2 do you mean the new line introduced this year?
13:38 pmoreau: GM20x, the ones needing signed firmwares
13:38 Lekensteyn: lspci shows this: 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GM204M [GeForce GTX 965M] [10de:13d9] (rev a1)
13:38 karolherbst: pmoreau: maxwell uses the clk/gk104 implementation
13:39 karolherbst: Lekensteyn: you should be able to reclock the gpu, but memory clock won't change
13:39 Lekensteyn: is that a debugfs thingey with pstate?
13:39 pmoreau: Isn’t memory clock the most important when you have large displays to drive / multiple of them?
13:39 pmoreau: With 4.5+, yes
13:40 pmoreau: `/sys/kernel/debug/dri/1/pstate`
13:40 karolherbst: pmoreau: well partly, on reverse prime PCIe is more important
13:40 pmoreau: I mean, compared to the engine clocks
13:40 pmoreau: I agree PCIe might be more important
13:41 karolherbst: well there is also pdisplay
13:42 karolherbst: oh wait
13:42 Lekensteyn: a question, how is it possible that driving a DP and eDP screen in discrete mode gives no corruption while in hybrid mode a single DP monitor has issues?
13:43 karolherbst: Lekensteyn: well PCIe isnt important in that case
13:43 karolherbst: and some software issues
13:43 pmoreau: Especially since the DP monitor is connected directly to the NVIDIA card and not going through the Intel one I guess?
13:43 karolherbst: Lekensteyn: basically with reverse prime, you copy the rendered image on the intel GPU to the nvidia GPU over PCIe
13:43 karolherbst: and anything above FullHD is critical
13:43 karolherbst: FullHD kind of works
13:44 karolherbst: pcie isnt exactly fast
13:45 karolherbst: and sometimes those mobile chips only have a x8 connection
13:45 karolherbst: you can imagine how good 2GB/s is for 60 full hd frames ;)
13:45 Lekensteyn: I still had issues with FHD I think, let me try 1024x768 first (extreme value, should work right :)) and then changing pstate
13:49 Lekensteyn: meh, deadlock while writing to /sys/class/drm/card1-DP-1/status while runtime suspended http://sprunge.us/APfU
13:50 pmoreau: Try with runpm=0 maybe to avoid the auto-powering down
13:52 Lekensteyn: alright, rebooting and using runpm=0, solving one problem at a time.
13:52 karolherbst: nouveau.runpm=0 if you add it to the kernel command line )
13:52 karolherbst: ;)
13:53 Lekensteyn: I have blacklisted nouveau for deterministic testing purposes :)
13:53 karolherbst: I se
13:53 karolherbst: e
13:57 Lekensteyn: even with 1024x768 there is cursor corruption
14:00 pmoreau: Maybe switch the rendering backend of kwin away from OpenGL? Is there anything in dmesg?
14:01 pmoreau: Or disable the compositor all together, try with a raw X or just twm, some simpler WM?
14:01 Lekensteyn: currently reproducing it at the sddm login manager screen, not sure what it uses. in the beginning I had it even with i3wm
14:02 pmoreau: :-(
14:03 Lekensteyn: cat pstate gives -ENODEV btw
14:06 karlmag: hmm... I guess the CodeNames page need some new entries now?
14:06 pmoreau: Like a Pascal one? :-)
14:07 karlmag: possibly ;-)
14:08 karolherbst: ohh right
14:08 karolherbst: maxwell2 has no clk subdev set currently
14:08 Lekensteyn: still corruption with 720x400 on plain Xorg with xterm
14:08 Lekensteyn: karolherbst: let me know if you have some patches to test :)
14:08 karolherbst: Lekensteyn: https://github.com/karolherbst/nouveau/blob/master_4.6/drm/nouveau/nvkm/engine/device/base.c#L2060-L2091
14:09 karolherbst: add .clk = gk104_clk_new,
14:09 Lekensteyn: do I need to cherry pick something or just add a single line?
14:10 karolherbst: just a single line
14:10 karolherbst: add it after .bus or something
14:11 Lekensteyn: nouveau 0000:01:00.0: disp: 0x6341[0]: INIT_GENERIC_CONDITON: unknown 0x07
14:11 Lekensteyn: also saw that earlier btw
14:13 Lekensteyn: karolherbst: pstate now shows a single line: AC: core 405 MHz memory 648 MHz
14:18 karolherbst: Lekensteyn: huh...
14:19 Lekensteyn: this is the journal if it helps http://sprunge.us/gOYK
14:22 imirkin: Lekensteyn: most often such corruption issues are due to the "primary" ddx sending over bad data
14:23 Lekensteyn: so Intel to modesetting?
14:23 imirkin: Lekensteyn: make sure you're using the latest ddx and also xorg 1.18 wouldn't hurt
14:23 Lekensteyn: 1.18.3 is currently in use
14:23 imirkin: ok, so that's fine
14:23 imirkin: make sure to get intel ddx from git
14:24 imirkin: *esp* for skylake
14:24 Lekensteyn: xf86-video-intel 1:2.99.917+654+ga508b11-1 on Arch Linux, that was built on 17 May
14:27 imirkin: ok, that should be recent enough
14:45 karolherbst: Lekensteyn: could I have your vbios from /sys/kernel/debug/dri/1/vbios.rom ?
14:59 Lekensteyn: karolherbst: sure, hang on
15:01 Lekensteyn: karolherbst: https://lekensteyn.nl/files/vbios-gm204-124190a1-
15:02 karolherbst: huh
15:02 karolherbst: odd
15:02 Lekensteyn: what are you looking at :)
15:02 karolherbst: the vbios looks odd
15:03 karolherbst: yeah
15:03 karolherbst: all the clocking related things aren't parsed correctly
15:03 karolherbst: mwk: you will like that :D
15:04 karolherbst: https://gist.github.com/karolherbst/71efca224edaaecf45fefcac61d4ecf5
15:04 mwk: lovely.
15:05 Lekensteyn: do you want me to run a blob and get some information out of it>
15:05 karolherbst: Lekensteyn: nah
15:06 karolherbst: Lekensteyn: we know what went wrong
15:06 karolherbst: it is just we never encounter this afaik
15:08 karolherbst: still odd
15:08 Lekensteyn: hm, are there some generic approaches that you follow to investigate cursor/image corruption issues? I can apparently work with 30hz refresh rates, but unreadable text/cursor is a bit more difficult ;)
15:09 karolherbst: Lekensteyn: well, let me deal with that vbios first :D
15:09 karolherbst: Lekensteyn: chances are, nouveau just missinterprets it
15:09 Lekensteyn: okay, have your fun :)
15:09 Lekensteyn: oh
15:09 Lekensteyn: it should be the same even if I reboot into discrete mode right?
15:10 karolherbst: mwk: but it seems those tables addresses are just encoded in 32bit instead of 16bit
15:25 karolherbst: https://gist.github.com/karolherbst/4bf27a8f41722e6a7ce0af5905269331 much better now :)
15:27 karolherbst: that's odd though
15:28 karolherbst: it doesn't make sense anyway
15:28 karolherbst: ...
15:32 karolherbst: "BIOS size 0x1d000"
15:32 karolherbst: mhh
15:34 karolherbst: yeah, there is only garbage at some point
15:34 karolherbst: odd
15:34 karolherbst: Lekensteyn: do you have envytools installed?
15:34 Lekensteyn: karolherbst: nope, I can grab it though
15:34 karolherbst: Lekensteyn: there is a tool called nvagetbios
15:35 karolherbst: Lekensteyn: I am hope the vbios isn't hidden inside the ACPI tables or something?
15:35 Lekensteyn: there was a _ROM method, but iirc that read from the PCIe config, lemme checj
15:36 karolherbst: mhh
15:36 karolherbst: maybe the vbios is fine though
15:37 Lekensteyn: I think that the _ROM returned by ACPI is about 0x00020000 bytes
15:37 karolherbst: no, it looks fine
15:37 karolherbst: mhh
15:37 karolherbst: yeah
15:37 karolherbst: that is big enough
15:37 karolherbst: ohhh I think I know
15:39 karolherbst: hehe
15:40 karolherbst: nvbios says: 0x4dca: 0f 10 0d 07 10 00
15:40 karolherbst: but my smart hex editor says something else
15:40 karolherbst: :D
15:40 Lekensteyn: nva/nvagetbios is complaining about extraction method that fails (PRAMIN)
15:40 karolherbst: -s prom
15:40 karolherbst: but that won't work as well
15:40 karolherbst: I don't think the tool can handle acpi yet
15:41 Lekensteyn: "Attempt to extract the vbios from card 0 (nv124) using PROM." "Vbios extracted successfully!"
15:41 Lekensteyn: the contents look familiar (using xxd :p)
15:42 karolherbst: :D
15:43 Lekensteyn: here you go https://lekensteyn.nl/paste.php?f=2BRj (it is binary)
15:43 karolherbst: shit
15:43 karolherbst: ...
15:43 karolherbst: this smells like work
15:43 karolherbst: I don't like it
15:43 karolherbst: mupuf: do you have some time? :D
15:44 karolherbst: crap
15:44 Lekensteyn: hmm, maybe I should be reading reports or my team kills me :p
15:44 karolherbst: god damit...
15:44 karolherbst: why does this happen to us :D
15:45 karolherbst: okay, now this table looks okay
16:15 karolherbst: the work in nouveau will be a lot more messy
16:15 karolherbst: because of thos stupid bios functions
16:15 Lekensteyn: if (0) { ... } else if (1) { ... } hmm
16:15 karolherbst: now I have to change the return value and be sure that the code does the right thinkg
16:15 karolherbst: Lekensteyn: yeah well, I am too laty to figure out if we can do that always
16:16 karolherbst: maybe we can here
16:16 Lekensteyn: yes, I was more thinking about a /* TODO */ comment in such cases
16:17 karolherbst: nah, we will deal with that before merging it in
16:17 karolherbst: I am more worried about the nouveau side
16:17 Yury: hi guys, some advice on old and unsexy hardware use with nouveau?
16:17 karolherbst: because the bios parsing API is really hard to change here
16:18 Yury: ..that msg on the list summarises: https://lists.freedesktop.org/archives/nouveau/2016-June/025202.html
16:20 karolherbst: Lekensteyn: nah, this is too much work without a proper card....
16:20 karolherbst: now I am really annoyed by ths
16:21 karolherbst: *this
16:21 Lekensteyn: would giving you ssh access help?
16:21 karolherbst: Lekensteyn: only if you don't plan to use the machine for a week
16:21 Lekensteyn: that is OK
16:22 Lekensteyn: I'll be taking it for travelling in the end of next week
16:22 Lekensteyn: but before that you can do mostly anything with it, there is no important data on it
16:23 karolherbst: I see
16:23 karolherbst: yeah maybe I work on that after I try to fix it without testing ...
16:23 karolherbst: well I have your vbios so I might get it done
16:24 Lekensteyn: sorry for pushing more items on your TODO stack
16:24 Lekensteyn: you probably did not expect this when you woke up this morning :p
16:25 karolherbst: no
16:25 karolherbst: :D
16:25 karolherbst: I think nobody did
16:25 karolherbst: ahh well
16:26 karolherbst: but somehow we should have known this
16:26 karolherbst: having a vbios bigger then 0xffff also means the tables can start somewhere above 0xffff
16:26 karolherbst: ...
16:26 karolherbst: and clearly 16bit values aren't big enough for that
16:27 Lekensteyn: what is the effect of this issue?
16:28 Lekensteyn: the dmesg does not shout "oh dunno what this is!!1"
16:28 karolherbst: Lekensteyn: well
16:28 karolherbst: Lekensteyn: basically we parse the vbios wrong
16:28 karolherbst: Lekensteyn: which can lead to any issue
16:28 karolherbst: Lekensteyn: like your pstate file being empty ;)
16:29 Lekensteyn: so everything that seems to be working now is just by luck?
16:29 karolherbst: something like that, yes
16:29 karolherbst: allthough most of the tables are still below 0xffff, so most os the stuff is find
16:29 karolherbst: *fine
16:30 karolherbst: only the reclocking related tables are above the 16bit range
18:49 hakzsam: karolherbst, btw, sorry I still didn't test your dual issue stuff on my gf119 but I'm looking at a serious issue with F1 2015
18:50 hakzsam: which is hard to track down
18:50 karolherbst: mhh
18:51 karolherbst: sadly I don't have that game
18:51 karolherbst: hakzsam: compute related?
18:52 hakzsam: compute, shared mem, atomic ops, images
18:52 hakzsam: inside the same shader :)
18:52 karolherbst: :D
18:52 karolherbst: sounds like fun
18:52 hakzsam: yeah
18:52 hakzsam: it's not surprising that new features are quite buggy though
18:54 hakzsam: we already did fix a bunch of those
18:54 hakzsam: but this one is new
20:10 karolherbst: YEAH!!!
20:10 karolherbst: found a 1080 vbios
20:13 karolherbst: let's check
20:15 karolherbst: mhh
20:15 karolherbst: nice
20:15 karolherbst: wokring
20:15 karolherbst: well
20:15 karolherbst: holy crap
20:15 karolherbst: :O
20:15 karolherbst: mwk: 0x98 P table
20:16 karolherbst: ..
20:16 karolherbst: mupuf:
20:16 karolherbst: :D
20:17 karolherbst: ohh shit
20:17 karolherbst: yeah
20:17 karolherbst: we have to change the offsets to 32bit
20:17 karolherbst: P table: https://gist.github.com/karolherbst/f4da2dc7cec1ffbe8176529a4335751f
20:17 Calinou: meh, too late
20:17 Calinou: you no longer need my BIOS
20:18 karolherbst: give it
20:18 karolherbst: :D
20:18 karolherbst: the more the better
20:18 Calinou: well I don't have my 1080 yet
20:18 Calinou: I will buy it next month
20:18 Calinou: when I have enough money + custom cards start being available
20:18 Calinou: (there's no way I'm buying a Founders Edition)
20:18 imirkin_: you mean coz no one has them in stock? :)
20:19 karolherbst: okay
20:19 karolherbst: so a lot of pascal commits incoming now :p
20:19 Calinou: in France, the custom ones (in pre-order) start at €730
20:19 Calinou: :(
20:19 Calinou: they promised €600
20:19 Calinou: that's a joke, lol
20:19 Calinou: $600*
20:19 Calinou: still
20:19 hakzsam: karolherbst, how did you get a pascal? oO
20:20 karolherbst: no
20:20 karolherbst: a vbios!
20:20 karolherbst: I don't have a pascal
20:20 karolherbst: just some proud owner uploaded his vbios with flashing tool on a internet forum :D
20:20 karolherbst: and I found it
20:20 hakzsam: yeah, but you know someone who has a pascal ? :)
20:20 karolherbst: no
20:20 karolherbst: I just read through 15 pages of a thread
20:21 hakzsam: :)
20:22 karolherbst: huh
20:22 karolherbst: "unknown chipset"
20:22 karolherbst: ahh
20:22 karolherbst: that's not the id
20:24 karolherbst: 0x1b80 device id
20:24 karolherbst: 8604 is the chipset number
20:26 karolherbst: mhh
20:26 karolherbst: anybody any idea if that chip will be NV134 or NV144?
20:33 karolherbst: ...
20:33 karolherbst: I should be more careful
20:43 imirkin_: uhhhhhh force-pushed?
20:43 imirkin_: karolherbst: never do that
20:43 karolherbst: I know, but I just removed the commit I pushed accidentially :/
20:43 imirkin_: ah
20:43 karolherbst: usually I wouldn't do that
20:43 imirkin_: ok
20:44 karolherbst: Swap Ready Out: This signal, which is related to Fliplocking, is used to drive the gate of an external FET.
20:44 karolherbst: that's int eh GPIO table
20:45 karolherbst: and something new which isn't in the docs
20:45 karolherbst: "Unknown ram type" no shit
20:45 karolherbst: :D
20:46 karolherbst: nooooooo
20:46 karolherbst: nooooooooo
20:46 karolherbst: ....
20:46 karolherbst: they removed the CSTEP table
20:46 karolherbst: nooo :(
20:46 karolherbst: and the boost table
20:47 karolherbst: and the volt table is also gone
20:47 karolherbst: yeah well
20:47 karolherbst: but the volt mapping table is still there
20:50 karolherbst: ohh
20:50 karolherbst: what do we have here
20:52 karolherbst: anyway, that vbios is partly broken :/
20:54 karolherbst: but that's the newest P bit table: https://gist.github.com/karolherbst/f4da2dc7cec1ffbe8176529a4335751f
20:55 karolherbst: three new M tables as well
20:55 karolherbst: INA3221
20:57 karolherbst: but the vbios is bricked after somewhere around 0xf000
20:58 karolherbst: on 0xf200 there is 0x55 0xaa as bytes
20:59 karolherbst: maybe after 0xf000 it is already broken... well doesn't mater
21:10 karolherbst: 0x68: 0x4e35 => POWER UNK68 TABLE
21:11 karolherbst: lets check this out
21:14 karolherbst: https://gist.github.com/karolherbst/8df17c1164fe95a94d1d28bd7a3f9628
21:14 karolherbst: mhhh
21:14 karolherbst: rather boring
21:15 karolherbst: 0xc35 => 3125
21:15 karolherbst: could be the base clock?
21:16 RSpliet: 3125 sounds like the clock speed for the timer units
21:18 karolherbst: mhh
21:18 karolherbst: or maybe it is the new volt table
21:19 karolherbst: and 3125µV is the pwm step
21:19 karolherbst: I have 6250µV step size
21:19 karolherbst: and GPIO has 12500µV step size
21:19 karolherbst: and the volt table is gone
21:19 karolherbst: oh well
21:20 karolherbst: actually why not
21:20 karolherbst: mhh
21:20 karolherbst: sadly the rest of the table doesn't look like anything
21:22 karolherbst: classic
21:22 karolherbst: Failed to parse UNK6C table at 0x4d71, version 0
21:22 karolherbst: Failed to parse UNK70 table at 0x4e45, version 0
21:26 karolherbst: ahh
21:26 karolherbst: https://gist.github.com/karolherbst/8df17c1164fe95a94d1d28bd7a3f9628
21:26 karolherbst: the 6c table looks like something
21:26 karolherbst: new sense table
21:27 karolherbst: mhh maybe not
21:28 karolherbst: 0xa4cb8: 675000
21:28 karolherbst: 0x493e0: 300000
21:28 karolherbst: 0x13d620: 1300000
21:29 karolherbst: 0xf4240: 1000000
21:29 karolherbst: okay
21:29 karolherbst: this table makes some sense
21:30 karolherbst: multiple 3byte+1byte pairs of values
21:31 karolherbst: but what could that be...
23:36 karolherbst: yay
23:36 karolherbst: found more vbios