00:00 mwk: there was something about crc in pre-nv50 hardware iirc
00:01 mwk:checks her notes
00:02 Lyude: imirkin: ^ :)
00:02 Lyude: time to patch dump
00:02 mwk: yep, there is something
00:03 mwk: 680608 is TEST_CONTROL where you can enable/reset the crc and select which channel you're CRCing (red green or blue), 68060c is the checksum value
00:03 mwk: or at least so it seems from old register list leaks
00:05 mwk: (bit 0 reset, bit 4 crc enable, bits 8-9 channel select, and the checksum seems to be 24-bit?!?)
00:05 Lyude: mwk: it lets you select all the channels at the same time too, right?
00:05 mwk: no
00:05 mwk: choose one
00:05 Lyude: oh lord
00:05 mwk: 0 is blue, 1 is green, 2 is red
00:05 Lyude: yeah that's probably not worth the effort trying to implement
00:06 mwk: and I have nfi what the algorithm is
00:06 imirkin: why would you want to checksum multiple channels at once?
00:06 imirkin: that's just ridiculous
00:06 Lyude: imirkin: you only want to checksum multiple channels at once, that's how most modern hw does it (although the crc might have different channels in each 8 bits, depending on the algorithm)
00:06 Lyude: also mwk the algorithm isn't important, igt assumes you don't know it
00:06 imirkin: </sarcasm>
00:07 Lyude: imirkin: ah lol
00:07 Lyude: tbh that sounds a lot like matrox's CRC stuff
00:07 Lyude: but i think even they let you select all channels
00:07 imirkin: (that's a lie by the way ... in no way is it the end of my sarcasm)
00:08 Lyude: mwk: any chance there's different tap points you can read CRCs from? maybe they don't all do channel selection
00:09 mwk: there are only two registers on the whole card with "CRC" in the name
00:09 mwk: and the other is the same thing, but for TV out
00:10 Lyude: sad :(
00:10 mwk: ... oh, and a third one, for digital output
00:10 Lyude: oh!
00:10 Lyude: ok, that sounds more like it
00:10 mwk: no
00:10 Lyude: oh :(
00:10 mwk: I mean the exact same thing
00:10 mwk: except for TMDS, not DAC
00:11 Lyude: bizarre
00:11 mwk: well that's because the checksum circuitry seems to be tied to the output resource
00:11 mwk: which is a separate thing for (VGA) DAC, TV out, and TMDS out
00:13 Lyude: mwk: no I meant just that it's weird that you could only select one channel on tmds as well
00:14 Lyude: crc's are also tied to outps on gf119+, but can also come from different portions of the outp's scanout and additionally from the RG
00:14 mwk: interestingly, the channels are called "7_0", "15_8", and "23_16" on TMDS and TV instead
00:14 mwk: I don't think it's any different in behavior though
00:15 Lyude: it is probably worth a shot to play around with at least, if anyone here gets bored enough
00:17 mwk: have fun
00:17 mwk: I don't even have hw access at this point, even if I wanted to
00:23 Lyude: mwk: hehe, np, wasn't expecting you to :P
00:27 pabs3: is there anything (as someone who doesn't know GPU stuff) I can do to help fix GPU hang issues? can I capture debug info somehow?
00:32 mwk: Lyude: ... a few years ago, I'd have jumped at it and probably be reversing the algorithm by now :p
00:52 Lyude: can someone approve the cover letter for https://patchwork.freedesktop.org/series/74804/ on nouveau's ml? it got blocked by it again
00:52 Lyude: also - we should really change that
00:52 RSpliet: Lyude: just so you know, I've definitely seen nouveau upload scripts to the PMU to do small display config thingies in VBLANK
00:53 Lyude: RSpliet: oh neat, tbh though i'm not really sure it's worth the effort
00:53 Lyude: also we can't upload random stuff to the pmu post maxwell 2 anyway
00:54 RSpliet: Well, timing wise it's a lot more reliable than doing it on a multi-core time-shared CPU with interrupts and stuff :-P
00:54 RSpliet: First thing we do for DRAM reclock is wait for VBLANK, such that at least one display doesn't flicker
00:54 Lyude: RSpliet: that's what the vblank workers are for :)
00:54 Lyude: they use the highest possible priority allowed by the scheduler , and intel's planning on using that for doing vblank-sensitive hw programming as well
00:55 RSpliet: Yep, but CPU overheads are much higher as it has to cross a (shared) PCI-e BUS
00:56 RSpliet: I think you have like... 500μs? Unless you get unlucky and find one of those reduced-VBLANK monitors
00:57 RSpliet: Either way, it's something to bear in mind. If not for now, than perhaps for follow-up work. And for REing as well, if you feel like some bits are missing from NVIDIAs command stream, they might be hiding in plain sight in there
00:57 Lyude: RSpliet: it's a bit more then that iirc, given a 60hz monitor it should be 16.6ms per-scanout period, I should probably also note it doesn't need to happen -within- the vblank, just before the next vblank
00:58 Lyude: so even if the update gets processed half-way through the scanout period, that should still be ok, as long as the whole thing happens during that one scanout
00:59 RSpliet: Ahh okay, yeah that changes requirements a bit
01:00 RSpliet: DRAM reclocking must happen in VBLANK. I suspect so does reconfiguring the NISO buffer. But we don't do that sadly...
01:01 Lyude: alright-misc work I came up with during CRC stuff, the actual CRC patches, and the igt tests for said patches are on the ml :).
12:31 cosurgi: imirkin: any chance you could also test this with displayport?
12:33 imirkin: zero
12:33 imirkin: no DP output on the GP108 :)
12:37 cosurgi: ah :) But the general idea is the DP should work exactly the sae as HDMI, right?
12:38 cosurgi: maybe there is some hidden mute switch which I didn't find. And it even plays the music but at zero volume
12:38 imirkin: there's definitely more to it. DP audio didn't always work.
12:38 imirkin: but we did make it work at some point
12:39 imirkin: (and when i say 'we', i mean 'ben')
12:39 cosurgi: I don't know why I can't regulate volume in alsamixer, only mute/unmute, and the channels are called S/PDIF, S/PDIF 1, S/PDIF 2, ...
12:39 cosurgi: ah! good :)
12:39 imirkin: sounds right
12:41 karolherbst: cosurgi: S/PDIF is controlled on the end device as it's a digital signal
12:42 imirkin: yeah, it's 100% digital to the monitor - no volume controls or anything
12:43 imirkin: that's expected.
12:43 cosurgi: ok then. So when I have set volume on the monitor to the max, and I even hear a faint white noise coming from the monitor speakers, then theoretically I have done all that I should have done?
12:45 imirkin: yes
12:47 cosurgi: ok, good :) So if you will have experiments in mind to do with recompiling driver or kernel, plese let me know. Together we will fix it ;)
12:47 cosurgi: albeit I prefer to reboot rarely.
17:54 squimrel: The last working kernel version was 5.0.9Thinkpad P73 Dual-Graphic: Intel UHD Graphics 630 & NVIDIA GP107GLM [Quadro P620]Default Fedora 31 (5.5.9-200.fc31.x86_64) set-up. No proprietary nvidia stuff was ever installed.Packages: xorg-x11-drv-nouveau:1.0.15 libdrm-devel:2.4.100I was waiting since October on 5.0.9 for a magic fix so that I wouldn't
17:54 squimrel: have to go and report this with no clue on how to report stuff in the first place. I didn't compile nouveau from master and test that so I don't know if it was magicly fixed in the latest version.journalctl -a -o short-iso-precise -k -b -1: https://pastebin.com/mCDRW5SpApart from that I can't say anything except that it doesn't boot properly an
17:54 squimrel: there're stacktraces in the logs.
17:55 squimrel: Spaces -.- https://pastebin.com/mCDRW5Sp
17:57 imirkin: this is a good way to report
18:54 squimrel: imirkin, Thanks! Please help me make sure the report is not lost in space.
18:55 imirkin: squimrel: unfortunately it's not a great time for me. moving tomorrow.
18:55 imirkin: keep the info handy, and repost it on, like, saturday
18:55 imirkin: or maybe someone else will be able to have a look
18:55 imirkin: i dunno what your issue is
18:56 imirkin: but if it hangs
18:56 imirkin: then chances are karolherbst has some patches for you to try
18:56 karolherbst: what issue?
18:56 imirkin: scroll up
18:56 karolherbst: I asked because I was being lazy :p
18:57 karolherbst: but yeah, looks like runpm
18:57 karolherbst: squimrel: https://github.com/karolherbst/linux/commits/runpm_fixes top two patches
18:57 karolherbst: if you run fedora 31 I can even provide you with a kernel build
18:58 squimrel: karolherbst, Can you link me to a guide on how to test those as well?
18:58 karolherbst: ahh, it's fedora 31
18:58 karolherbst: squimrel: https://copr.fedorainfracloud.org/coprs/karolherbst/Nouveau_Testing/
18:58 karolherbst: use that copr
19:06 squimrel: karolherbst <3 !!!! That works! (Although my external monitor doesn't work yet.)
19:06 karolherbst: mhhh
19:06 karolherbst: could be some other issues
19:06 karolherbst: Lyude might know
19:07 karolherbst: or imirkin :)
19:07 karolherbst: squimrel: does the monitor start working when you execute lspci?
19:07 karolherbst: maybe hotplugging detection is screwed
19:07 Lyude: i doubt it, usually hpd is pretty reliable these days
19:08 Lyude: squimrel: can you boot your kernel with log_buf_len=50M nouveau.debug=disp=trace drm.debug=0x16
19:08 squimrel: karolherbst, no
19:08 Lyude: then get me your dmesg after trying to plug in the display?
19:08 squimrel: Sure!
19:09 karolherbst: Lyude: I am actually kind of happy that my patch still always works when users complain as this is already limited to just that one intel bridge controller :)
19:09 Lyude: yeah, it is a big relief
19:47 squimrel: Lyude, so it's a little bit weird. The secondary monitor _sometimes_ works when re-plugging the display (usb-c) during boot. However so far didn't work when re-plugging it after boot and even makes it break. https://pastebin.com/3iuRHA64
19:49 squimrel: So, it may be unrelated to nouveau?
19:55 squimrel: karolherbst, :D Sorry - I should've waited for the magic fix a little longer.
19:55 karolherbst: what do you mean?
19:58 squimrel: karolherbst, I mean instead of being one of the users who comes and complains about an issue that will be merged into mainline soon. It's just really hard to find a solution for this with google.
19:59 karolherbst: ohh no, it's fine
20:03 Lyude: squimrel: can you send the whole log without trimming it at all?
20:05 apteryx: hello, Icecat (based on Firefox) sometimes crash my X session, like:
20:05 apteryx: https://paste.debian.net/1135468/
20:05 apteryx: is there something I should do to get a more useful log?
20:06 squimrel: Lyude, now it works even after boot. Probably the fault of my crappy display. I assume the trimmed logs look normal to you as well. I guess that solves it. Thanks!!!!
20:07 Lyude: not sure what I did but you're welcome!
20:07 karolherbst: squimrel: could also be just something random though
20:07 karolherbst: or maybe some latencies shifted
20:07 Lyude: or a loose cable. never trust cables.
20:07 karolherbst: or that
20:08 Lyude: it's a little weird how USB-C adapters for video stuff seem to break so often
20:08 squimrel: karolherbst, Using a different usb port fixed it. Not sure why. Yeah maybe cable.
20:08 karolherbst: Lyude: annoying that my patch is stuck.. or maybe it got applied.. I should probably check
20:08 Lyude: squimrel: might be that only one port can do video output
20:08 Lyude: karolherbst: poke airlied maybe?
20:08 karolherbst: Lyude: I would be interested in knowing how well that works with windows
20:08 Lyude: karolherbst: hah
20:08 Lyude: i promise the results may surprise you
20:09 Lyude: or at least it was like that when I tried mst on windows, only to find out it's actually worse then linux
20:09 Lyude: for intel anyway
20:09 karolherbst: heh
20:09 karolherbst: maybe it works better with macs then...
20:10 karolherbst: sounds like something they would really care about
20:11 Lyude: karolherbst: it'
20:11 Lyude: oops
20:12 Lyude: *it's funny, I used to think getting confused by the DP spec was just a me thing, but everyone from intel/amd/google have trouble understanding it as well
20:12 airlied: I think apple have avoided mst where possible :-P
20:12 karolherbst: uhm... and who are the people who actually wrote it? :D
20:12 Lyude: ^ that as well
20:12 Lyude: karolherbst: those companies, probably
20:12 karolherbst: airlied: what do they do on their usb-c/TB only macbooks then?
20:13 Lyude: specs are hard
20:13 karolherbst: not using MST?
20:13 Lyude: karolherbst: you can run up to like two video streams through TB3 actually, iirc
20:13 karolherbst: ahh
20:13 Lyude: but a lot of laptops don't support it
20:13 karolherbst: I see
20:14 airlied: karolherbst: just DP
20:33 gruetzkopf: i've previously looked at what little public info there is about dp alt mode on usbc
20:34 gruetzkopf: so - many - optional things
20:35 Lyude: well yeah, otherwise it'd be too expensive to incentivize manufacturers to use it unfortunately