03:51 imirkin: karolherbst: i'm seeing https://paste.debian.net/1190225/ -- looks like the serialize stuff is off a bit?
03:51 imirkin: i guess the addReloc logic misses some initialization sometimes? dunno
05:59 imirkin: interesting. glxspheres + HUD = major fail on nv50: nouveau 0000:04:00.0: glxspheres[19329]: pushbuf push count exceeds limit: 161228 max 512
09:28 Wolf480pl: Checked on Windows again and under load GPU-Z is reporting mem clock 1248 MHz (meanwhile OpenHardwareMonitor reports 2x that) and 1.025V. On Linux with nouveau, in pstate != 07, sensors(1) is reporting only 1.01V.
09:29 Wolf480pl: Could it be that nouveau is setting voltage too low and/or mem clock 2x too high?
09:31 Wolf480pl: (pstate 0f says 5000MHz which, is 4x higher than what GPU-Z was reporting on Windows, or 2x higher if we account for DDR AFAIU)
10:13 karolherbst: imirkin: could be. yes
10:13 karolherbst: how did you hit it?
10:16 karolherbst: (or maybe I should just run with libasan through the entire shader-db with cache enabled)
11:14 Wolf480pl: RSpliet, either way the fps count was way off (showed 100fps, felt like 5fps) and so was the score
11:46 RSpliet: lyude: I just updated my Fedora machines to kernel 5.11.7. And behold, on my Kepler GPU the cursor is wrecked. Can you chase up backporting your fix to Fedora?
14:09 karolherbst: Wolf480pl: that's on a laptop, right?
14:09 Wolf480pl: yup
14:09 karolherbst: mhhhh
14:10 karolherbst: not sure if that's an intel but then
14:10 karolherbst: *bug
14:10 karolherbst: I noticed that if you don't vsync and don't get 60 fps straight, the intel driver missbehaves terribly
14:10 karolherbst: but could also be a stupid nouveau bug in the prime offloading path
14:10 Wolf480pl: I reran the benchmark with nouveau as primary gpu and got a saner result
14:11 Wolf480pl: ~500 points with pstate 0a
14:11 RSpliet: \o/
14:11 karolherbst: what about 0xf?
14:11 Wolf480pl: crashes
14:11 karolherbst: Wolf480pl: well, if you don't care about battery lifetime or general instability, you can use nouveau as the main, yes :D
14:11 karolherbst: ahh :/
14:11 karolherbst: ohh that's GK104...
14:11 karolherbst: shit
14:11 Wolf480pl: I can give you dmesg, but that was with an older kernel
14:11 karolherbst: Wolf480pl: do you have a pastebin of the pstate file somewhere?
14:12 karolherbst: I think that's the high clock issue
14:12 Wolf480pl: pstate https://gist.github.com/Wolf480pl/4c506a4eb6637cea5d524d875ed77198
14:12 Wolf480pl: dmesg https://gist.github.com/Wolf480pl/cab91b80d0ca0aab5889581e45a011f8
14:12 karolherbst: does 0xe work?
14:12 Wolf480pl: nope, similar hang to 0xf
14:13 Wolf480pl: tbh I don't remember if the dmesg is from 0xe or 0xf
14:13 karolherbst: mhhh
14:13 karolherbst: the error kind of indicates something odd with memory
14:13 karolherbst: could alsom be related to unknwon bits
14:13 Wolf480pl: so, more traces needed?
14:14 karolherbst: did you file a bug already? I think it would make sense to 1. attach a vbios 2. attach a mmiotrace with nvidia when clocking with the nvidia-settings GUI
14:14 Wolf480pl: if I did it was years ago
14:14 karolherbst: ahh yeah...
14:14 Wolf480pl: but I'm not sure if I did
14:14 karolherbst: sadly I wouldn't have time to work on those issues :/ best we can do is to document it
14:15 RSpliet: This stuff doesn't change much. If you did, the old trace should be usable
14:15 karolherbst: trace with nouveau would also help
14:16 karolherbst: but yeah.. the memory is getting bonkers :/
14:16 Wolf480pl: also, it doesn't hang immediately, I can run glxspheres for a while and it works, but when I run heaven it hangs sooner or later
14:16 karolherbst: yeah... just some instabilities
14:17 karolherbst: could also be something trivial like we don't increase the mem voltage for whatever reasons
14:17 Wolf480pl: could this be related to voltage?
14:17 karolherbst: might be
14:17 karolherbst: might also be some missconfiguration
14:17 Wolf480pl: oh, but which voltage does sensors(1) report?
14:17 karolherbst: core
14:17 Wolf480pl: :/
14:17 RSpliet: really high (memory) clocks sometimes require to increase the PLL in two stages, or even use two PLLs to get up there. Not sure that logic is perfect
14:18 karolherbst: yeah... memory voltage is... annoying
14:18 karolherbst: RSpliet: we do that
14:18 karolherbst: the threshold is a memory clock
14:18 karolherbst: but yeah...
14:18 karolherbst: maybe that threshold is bonkers
14:18 karolherbst: could be anything really
14:18 Wolf480pl: btw. do I remember correctly nouveau bugs used to be on freedesktop bugzilla?
14:19 karolherbst: we are kind of moving to gitlab
14:19 karolherbst:plans to work on issue templates on momnday
14:19 karolherbst: *monday
14:19 Wolf480pl: ok, but are old bugs still on bugzilla or on gitlab already?
14:22 karolherbst: I think they are mostly migrated
14:35 karolherbst: imirkin: ohh, actually.. I think that's just padding
14:36 karolherbst: we should calloc the entry
14:37 karolherbst: we either we memset or do some fancy realloc thing?
14:50 Wolf480pl: btw. I looked at my old (2015) notes from past driver debugging and it says "The blob sets the register 20344 to 44 which increases the voltage to 1.02V", is this useful or should I try to make new traces with the blob?
14:56 Wolf480pl: btw. btw. I still have `options nouveau config=War00C800_0=1` in my modprobe.d, does this option still exist?
14:58 Wolf480pl: oh, it's on by default now?
15:04 Wolf480pl: nvm that was in skeggsb's fork
15:12 Wolf480pl: karolherbst, so I open nvidia-settings, start mmiotrace, switch "preferred mode" to "maximum performance", stop mmiotrace?
15:12 karolherbst: you have to enalbe mmiotrace before loading the nvidia driver sadly :/
15:12 karolherbst: but with nvidia-settings you have nice controls over when to reclock
15:12 karolherbst: and can add markers into the trace
15:13 Wolf480pl: in nvidia-settings I only see "powermizer settings: preferred mode: [auto|adaptive|maximum performance]"
15:14 Wolf480pl: unless application profiles can be used for reclocking too
15:16 karolherbst: the powermizer setting is good enough
15:16 karolherbst: maximum perf can be set to force the highest perf mode
15:50 Wolf480pl: I have an mmiotrace from `modprobe nvidia*` to changing powermizer to highest perf and back. I didn't run any 3d load in that trace, but nvidia-settings did show pstates changing anyway. Is this good enough?
15:52 Wolf480pl: Should I also make an mmiotrace of what nouveau does when told to change pstate?
15:52 Wolf480pl: Should I also include dmesg or sth?
17:01 imirkin: karolherbst: yeah, i figured it was something like that
17:03 imirkin: karolherbst: i hit it by running deqp, while trying to debug an unrelated issue
17:04 imirkin: (running valgrind on it, that is)
17:04 imirkin: i think it's much more common on nv50, since nv50 has to do CALL relocations
17:04 imirkin: (there are no relative calls)
17:04 imirkin: /jumps/etc
17:19 karolherbst: mind putting a memset or something to see if that fixes it?
17:19 imirkin: any particular place?
17:19 karolherbst: otherwise maybe we want to declare everything packed we serialize
17:20 karolherbst: imirkin: when the reloc gets allcoated
17:20 karolherbst: I guess direclty after the realloc?
17:20 imirkin: ok. i'll look at that code a bit closer later on i guess
17:21 imirkin: trying to put a series of misc fixes together
17:22 karolherbst: did we even enalbe the cache for nv50 yet? I was under the impression that I didn't merge the nv50 enabelemt, because the rework was bigger and I too lazy to review it in depth at that point? Or maybe I went through it and checked it.. can't remember :D
17:22 imirkin: dunno. but the bug i was debugging was on nv50.
17:22 imirkin: (found it -- apparently bufctx_cp != bufctx_3d ... who knew)
17:22 karolherbst: ahh
17:25 imirkin: my nv50 enablement of compute/images/etc is nearly complete
17:25 imirkin: just a few things left to address, which aren't huge deals
17:26 karolherbst: nice
17:27 karolherbst: and then I break it with the CL CTS :p
17:27 imirkin: well, someone will have to do the nir hookup as well
17:27 imirkin: i had to do a bunch of dodgy stuff
17:28 imirkin: well - not THAT dodgy. just slightly.
17:28 imirkin: like doing the buffer/image file remapping to gmem slots
17:28 karolherbst: yeah...
17:28 karolherbst: I am aware of some issues I have to look into
17:28 imirkin: and i sorta assume that you didn't take all the precautions of from_tgsi in generating the IR
17:29 imirkin: so it might rely on things which don't work on nv50
17:29 karolherbst: yeah...
17:29 karolherbst: I have to rework some offset stuff and addresses
17:29 imirkin: but as far as ES 3.1 compute support, it's ~done
17:29 imirkin: i have some very weird format reinterpret issue going on with rgba8_snorm
17:30 imirkin: which makes no sense, so i sorta assume it's an entirely unrelated issue
17:30 imirkin: and if i were nice, i'd hook up indirect dispatch
17:31 imirkin: and there are a handful of "weird" fails, at least one of them is because the generated program code is too large, i think
17:31 karolherbst: uhhh
17:31 karolherbst: don't remind me of too large program codes :/
17:31 karolherbst: but I guess the ones you are talking about are still small
17:32 karolherbst: how mamy instructions can nv50 hw execute? 64k?
17:32 karolherbst: ehh
17:32 karolherbst: 2 million actually
17:33 imirkin: the issue is actually with the *uplaod* of the program
17:33 imirkin: we use SIFC, and i think we overflow it
17:33 karolherbst: ohh
17:33 karolherbst: mhh
17:33 karolherbst: yeah well.. at least for CL we have to fix it
17:33 karolherbst: :/
17:33 imirkin: right, but it's not like a core problem
17:33 karolherbst: with compute applications are just super crazy
17:34 imirkin: it's a simple fix, assuming that is it.
17:38 karolherbst: wait.. I actually have nv30 hardware..
17:39 imirkin: that won't help testing nv50...
17:39 karolherbst: no, unrelated
17:39 imirkin: CL on nv30? :)
17:40 karolherbst: I thought my pre nv50 gpus are AGP or something...
17:40 karolherbst: :D
17:40 karolherbst: sure
17:40 imirkin: as long as you don't try to use control flow, should be fine =]
17:40 imirkin: or, you know, memory loads/stores
17:41 karolherbst: https://www.gigabyte.com/Graphics-Card/GV-NX66T128VP#ov
17:43 imirkin: nice
17:43 imirkin: supports SLI
17:43 imirkin: you can finally get some fast rendering done!
17:43 karolherbst: the other is a Quadro FX 3450
17:43 imirkin: i have that one
17:43 imirkin: not a bad board
17:43 imirkin: note that there are 2 nv4x 3d classes
17:44 imirkin: the "nv40" and "nv44" ones
17:44 karolherbst: annoying
17:44 imirkin: one of them supports index buffers (in a buffer), the other doesn't and you have to stream them in
17:44 karolherbst: wondering if I should look into issues like this: https://gitlab.freedesktop.org/mesa/mesa/-/issues/4397
17:44 karolherbst: but probably super painful to figure out
17:44 RSpliet: I have an nv4b.. here in the UK even
17:44 karolherbst: it's not like htere are even tests I could validate against
17:45 imirkin: yeah, i mean obviously the geometry got messed up somehow
17:45 imirkin: but it's not like it's 100% messed up
17:45 imirkin: so you're looking for something slightly subtle
17:45 imirkin: you can run deqp-gles2 and see if that triggers anything
17:45 karolherbst: we support gles2 on those?
17:45 imirkin: nv4x, sure
17:45 karolherbst: ahh
17:45 imirkin: nv3x just gets you GL 1.5
17:45 karolherbst: ohh
17:45 imirkin: but nv4x gets you GL 2.1 and GLES2
17:46 karolherbst: I thought nv4x is also only 1.5
17:46 karolherbst: do we do tricks or did nvidia not care?
17:46 imirkin: nvidia's driver is also GL 2.1
17:46 imirkin: (at least 2.0)
17:46 karolherbst: ahh then the website is wrong
17:46 karolherbst: wiki indeed lists 2.1
17:46 imirkin: it's been known to happen
17:46 karolherbst: okay, for gl 2.1 we also have a few CTS tests
17:46 imirkin: i wouldn't be surprised if they even did 2.0 for the nv3x hw
17:47 imirkin: but that'd be a LOT of fallbacks
17:47 karolherbst: yeah...
17:47 karolherbst: I think thye reported 2.1
17:47 karolherbst: wiki says this: "All models support Direct3D 9.0a and OpenGL 1.5 (2.1 (software) with latest drivers)"
17:47 imirkin: but back in those days, applications knew what they could and could not use
17:47 imirkin: so it didn't really matter
17:48 karolherbst: actually surprised nvidia or AMD didn't release a GL_EXT_is_feature_slow extension :D
17:48 imirkin: :)
17:48 imirkin: bad marketing
17:50 RSpliet: well, they did have the GeForce slowdown commands
17:50 imirkin: not in a public ext :)
17:51 RSpliet: shame we never got an extension for that! Sounds like a killer feature for applications!
17:52 imirkin: ;)
18:00 agneli: guys I spent few last weeks researching my question, no luck, maybe wrong places
18:01 agneli: can I get a multihead card, let us say nVidia Quadro 160M
18:01 agneli: to display different vts on different displays?
18:01 imirkin: not really. what you're looking for is "multiseat"
18:01 agneli: like i could with fbcon=map:
18:01 agneli: even with a 40 yrs old hgc...
18:02 agneli: not quite
18:02 imirkin: although even that might be one GPU per seat
18:02 agneli: I like text terminals I just want multihead
18:02 imirkin: tbh i'm not 100% sure how vt's work
18:02 agneli: but yes multiseat I wanted to check as well but later
18:03 agneli: mapping usually happens per /dev/fb*
18:03 imirkin: so the thing is... let's say "it works" and you can do this
18:03 imirkin: how do you direct input to a vt?
18:03 imirkin: and how do you tell it which vt goes to which screen
18:03 imirkin: (there are more than 2 vt's)
18:03 agneli: so let us say I have an old i486 with VGA and HGC (even dos supports that)
18:03 agneli: I can map one vt to /dev/fb1 and another to /dev/fb0
18:04 imirkin: there are 12 vt's
18:04 imirkin: ok, so you just pre-declare that vt's 1, 3, 7 go to connector A
18:04 agneli: yes
18:04 imirkin: and 2, 4, 5, 6 go to connector B?
18:04 agneli: yes
18:04 agneli: fbcon=map
18:04 imirkin: i'm unfamiliar with that
18:04 imirkin: anyways, like i said, there's no HARD reason this can't work
18:05 agneli: o
18:05 agneli: :)
18:05 karolherbst: is fbcon even a kernel command line tihng?
18:05 imirkin: the GPU is there, fbcon has hooks to draw to stuff
18:05 agneli: fbcon is a kernel module
18:05 imirkin: karolherbst: fbcon is the software which displays text
18:05 karolherbst: sure
18:05 imirkin: karolherbst: it acts as a fbdev client, which in turn acts as a kms client
18:06 karolherbst: but I don't see any mention of a fbcon parameter
18:06 imirkin: karolherbst: it's there.
18:06 imirkin: just perhaps not where you're looking
18:07 karolherbst: ahh https://www.kernel.org/doc/html/latest/fb/fbcon.html?highlight=console
18:07 karolherbst: so map maps drivers
18:07 agneli: Documentation/fb/fbcon.rst
18:07 imirkin: ideally you could feed it connectors. but i don't think fbcon interacts with kms at that level
18:07 imirkin: i'm not sure how fbdev deals with multihead either, tbh
18:08 Wolf480pl: so you'd need to create more than one fbdev per gpu?
18:08 karolherbst: I guess fbcon should be able to not always mirror things
18:08 karolherbst: because atm I think that's what it does
18:08 imirkin: at least in my limited experience with it, fbcon output is mirrored across displays
18:08 karolherbst: mirror the current one to all displays
18:09 imirkin: but i dunno what it does if you have diff size monitors
18:09 karolherbst: being shitty
18:09 imirkin: which don't have a single compatible mode across them
18:09 karolherbst: litterally tried that
18:09 karolherbst: it's annoying
18:09 agneli: imirkin: that I can answer
18:09 karolherbst: either you have cut outs
18:09 imirkin: ka-boom? :)
18:09 karolherbst: well, not that bad
18:09 agneli: it lowers the resolution to the smallest monitor
18:09 karolherbst: but you get like a FHD worth ot space on a 4K display
18:10 karolherbst: or you get 4k worth of space on the fhd one by things getting cut of
18:10 agneli: karolherbst: but I am able then set it back to 4k using fbset
18:10 karolherbst: I think it kind of depends when you add displays
18:10 karolherbst: agneli: ohh sure
18:11 agneli: but then it cuts things out
18:11 karolherbst: I am just the "it has to work by default, otherwise it's stupid" guy
18:11 karolherbst: best case would be that terminals are getting scaled accordingly
18:11 karolherbst: oh well..
18:11 agneli: there is a vresx vresy parameter in the /etc/fb.modes though...
18:11 agneli: which stands for virtual
18:12 agneli: man fb.modes
18:12 agneli: but I have no idea what it means...
18:12 karolherbst: yeah well...
18:12 karolherbst: I fixed the console on my 4k screens by setting a custom font
18:12 imirkin: agneli: virtual resolution is usually something which enables panning
18:13 imirkin: e.g. you might have a 1024x768 monitor but you enable a 2000x2000 virtual resolution
18:13 karolherbst: thing is... I don't know how I did it :D
18:13 imirkin: and then the monitor is a 1024x768 viewport into that "global" display
18:13 karolherbst: I think it's some grub magic in my case
18:13 imirkin: it was more of a thing back in the 90's
18:14 agneli: I am fixing this issue by forcing all displays to the highest bidder via video= option
18:14 agneli: the smaller displays just complain they cannot cope
18:14 imirkin: karolherbst: btw, when you get a chance: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9740
18:14 agneli: but well they just mirror anyway...
18:14 karolherbst: already saw the MR
18:14 imirkin: kk
18:15 karolherbst: yeah.. if I don't forget, I will take a deeper look on monday
18:15 imirkin: karolherbst: none of those are big fixes - the viewport thing makes it look bigger than it is, but that's a separate MR
18:16 RSpliet: karolherbst: btw, I didn't CC you on this because I think it's Lyude's bug/patch, but https://bugzilla.redhat.com/show_bug.cgi?id=1941291
18:17 karolherbst: RSpliet: I think somebody already fixed it?
18:17 karolherbst: there were some cursor related patches on the ML
18:17 RSpliet: karolherbst: yes, Lyude. But Fedora is broken
18:17 karolherbst: specifically for kepler
18:17 karolherbst: ehh....
18:17 RSpliet: They just pushed 5.11 to F33 stable.
18:17 karolherbst: request a backport of the patch :p
18:17 RSpliet: Without that fix in it
18:17 karolherbst: :D
18:17 RSpliet: I did
18:18 RSpliet: Just not sure who's going to pick that up, so making sure I bug all of y'all RH people :-P
18:18 karolherbst: RSpliet: https://src.fedoraproject.org/rpms/kernel/pull-requests :p
18:18 karolherbst: or ping... ehhh....
18:19 karolherbst: RSpliet: jforbes
18:19 karolherbst: but it would be easier to already prepare the spec patch and everything
18:19 karolherbst: with URL to upstream commit, etc...
18:20 karolherbst: it's the "drm/nouveau/kms/nve4-nv108: Limit cursors to 128x128" patch, isn't it?
18:20 RSpliet: Believe so yes
18:20 karolherbst: well...
18:20 karolherbst: did you try it?
18:21 RSpliet: I don't have a kernel tree handy
18:21 karolherbst: you don't need to
18:21 karolherbst: .. wait
18:21 karolherbst: clone the spec repo
18:21 karolherbst: add the patch
18:21 karolherbst: get fedpkg
18:21 karolherbst: and do "fedpkg mockbuild"
18:21 karolherbst: that gives you rpms
18:22 karolherbst: and those you can isntall via "dnf update *.rpm"
18:22 RSpliet: That almost sounds easy. I actually have (... had) an alias called rpmbuild.kernel. It just takes several hours on my machine
18:22 karolherbst: :D
18:22 karolherbst: let it run over night
18:22 RSpliet: Because it's a puny FX 6300 with cooling issues (the cooler is loud and ineffective)
18:22 RSpliet: Hah, not sure I can sleep with my machine on :')
18:23 RSpliet: AMD stock coolers really are a work of art
18:23 karolherbst: :/
18:23 karolherbst: annoying
18:24 RSpliet: It's in need of replacement. It's embarassing how theoretically the fastest computer in my house is an SBM. In practice though, I suspect its cooling isn't up to the job either and it'll throttle if I use it as a build farm
18:25 RSpliet: Think you can get COPR to build that kernel easily? Not even sure if this fix made it upstream yet :-C
18:25 RSpliet: (I'm also still cooking)
18:26 karolherbst: ehh.. copr
18:26 karolherbst: it will probably time out
18:26 karolherbst: yeah... if it's not upstream yet.. mhh
18:27 karolherbst: RSpliet: upstream in drm is enough though
18:28 RSpliet: Well, not really. Nouveau is broken on kepler for upstream 5.11 and 5.12rc3. Upstream shouldn't be broken. The patch was on the ML two weeks ago, that really should have fast-tracked upwards.
18:29 karolherbst: ping airlied or danvet then :p
18:29 RSpliet: danvet hereby pinged :-P
18:29 imirkin: RSpliet: works fine, just don't use stupid xf86-video-modesetting :p
18:30 karolherbst: I think the patch still mostly misses reviews
18:30 RSpliet: imirkin: wayland
18:30 imirkin: RSpliet: ah, sad
18:30 karolherbst: imirkin: [PATCH] drm/nouveau/kms/nve4-nv108: Limit cursors to 128x128 :p
18:30 imirkin: karolherbst: yeah, but it's only a problem if someone requests the large cursors to begin with
18:30 karolherbst: RSpliet: but yeah, I think it would make sense to try it out
18:30 danvet: I thought Lyude was going back on that to respin?
18:30 karolherbst: or maybe I could
18:30 karolherbst: danvet: no idea...
18:31 danvet: but also not going to look anywhere near a git tree today :-)
18:31 karolherbst: imirkin: what? we don't request larger cursors in the novueau ddx?
18:31 RSpliet: danvet: it sounds like somewhere a ball was dropped. Not too fussed about the "who" question, but the result is that currently upstream is broken
18:31 karolherbst: danvet: fair
18:31 imirkin: karolherbst: no, always 64x64
18:31 karolherbst: imirkin: :/ sad
18:31 RSpliet: danvet: that's fine. There's a bug on RHBZ. I'll see if I can quickly get an RPM build tree to do a review if that's what it takes.
18:31 imirkin: danvet: afaik there's some "better" solution that's possible, but it's more involved. this is a good backport candidate.
18:31 danvet: but airlied should wake up any moment
18:31 danvet: but he's not here
18:31 danvet: poke him on #dri-devel
18:31 Wolf480pl: agneli, looks like this is the code that makes fbdevs https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/drm_fb_helper.c#L1867
18:32 karolherbst: imirkin: well.. I guess we will habe those "cursor looks crappy on 8k" bugs soon then :p
18:32 imirkin: karolherbst: yes ... i expect those to start flowing in RSN
18:36 agneli: Wolf480pl: let me digest it ;)
18:37 imirkin: should be possible to introduce a "zaphodheads" setting for generating the fbdevs
18:37 imirkin: maybe.
18:47 RSpliet: karolherbst: if it makes you feel any better, looks like Renoir also soiled itself on 5.11
18:48 karolherbst: ohh, I am happy that only cursors are broken, based on our testing, everything is broken in each release until proven otherwise :p
18:48 RSpliet: Oh no I mean, Renoir as in amdgpu
18:51 HerrSpliet: wouldn't wake up no matter how many buttons I bashed on my keyboard. restarting gdm didn't do the trick. Reboot and suddenly plymouth played ball on the shutdown process.
19:29 imirkin: karolherbst: ok, the viewport MR is in, i updated the misc fixes MR so that it's a bit easier to look at diffs hopefully
19:30 imirkin: all pretty straightforward stuff.
19:36 RSpliet: 17 iterations later, I'm actually building a kernel RPM now. I forgot that my PC is more stable since I've introduced thermal paste
19:36 imirkin: yummy
19:38 RSpliet: every tried a peanut-butter-thermalpaste sandwich?
20:03 imirkin: RSpliet: is it like tomato paste?
20:29 RSpliet: Ohh it's a lot more moreish, it's like tomacco paste!
20:44 imirkin: mmm... tomacco...