03:51 <clover[m]> steev: is that from the recent firmware updates?

03:51 <steev> clover[m]: seems like it, maybe? i used to watch it closely, and building a kernel would usually get 90 on all 8 cores

03:53 <szclsya[m]> yeah same experience here

03:54 <szclsya[m]> a laptop stand with fans really helps. it can shave 6-10 degrees off. also the battery doesn't come nearly as hot, which is a good thing for lithium battery

04:16 <steev> i'm not using a laptop stand, i just sit it on top of the work macbook ;)

04:18 <amstan> don't stack laptops

04:18 <amstan> or you'll wonder why the top one is turning off randomly or the middle one is waking up even though the lid is closed

04:18 <amstan> this happens to us so many times, lol

04:19 <steev> it's not actually stacked, it's only about half way on it

04:20 <amstan> could still happen ;)

04:21 <steev> true

04:22 <steev> if i'm not gonna be using it for a bit, i usually put it off to the side on top of the bpf book that is about 5 times thicker than i thought it would be

04:50 <clover[m]> did yall hear about the GRUB bug? time to switch to sd-boot :P

04:52 <clover[m]> https://reddit.com/r/linux/comments/wzshhg/latest_grub_update_on_arch_distros_seems_to_cause/

05:24 <amstan> clover: i keep seeing this but idk if i've been affected

15:03 <robclark> clover[m]: or a different distro's fork of grub?

16:10 <clover[m]> robclark: yeah if you don't care about upstream i guess

16:15 <robclark> not too sure about arch.. but last time I checked, it seemed like everyone had their own fork of grub and no one was using upstream.. maybe that is only distros that support secureboot

16:16 <robclark> maybe it has improved since then, idk..

16:33 <qzed> arch mostly uses upstream grub, only a couple of customizations: https://github.com/archlinuxarm/PKGBUILDs/tree/master/core/grub

16:33 <qzed> IIRC other distros mostly base things on fedora's secureboot patches

19:49 <steev> blergh

20:17 <flowriser> Did a nifty thing with lxc that can compile arm64 kernels: https://github.com/SMFloris/lxc-kernel-taskfile

20:18 <flowriser> Should be helpful for people that compile multiple architectures

20:58 <steev> not too shabby, question though; doesn't 22.04 make zstd the standard compression? doesn't that also apply to the make deb-pkg target on the kernel? if so, that'll break for non-ubuntu deb users

23:24 <clover[m]> <steev> "blergh" <- whats wrong?

23:25 <steev> c630 is deferring the audio device on torvalds latest again

23:27 <clover[m]> so now there's both gpu and audio regressions?

23:37 <steev> no, the gpu works fine on 6.0.0-rc3 on the c630, audio however seems to "work" (everything seems correct but there's no actual audio out of the speakers), or defer

23:37 <steev> audio works fine on 5.19, but gpu seems to have broken, and i'm not sure what of my patchset does it

23:44 <steev> and for the thinkpad, display stuff is gonna need to be redone or something because https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c?id=1a258ee22634d0e856083a813273f7f337476178 drops the top support, which is used by the thinkpad patchset, although it may not be needed, i'm not sure

23:50 <steev> bamse: speaking of which, looking at "drm/msm/dpu: Introduce SC8280XP", which throws DPU_HW_VER_800 into drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c - right below it there's a comment about /* TODO: 0x102e for LP_DDR4 */ and then it proceeds to use 0x103e?

23:50 <steev> looks like it comes from drm/msm/dpu: update UBWC config for sm8150 and sm8250