07:11 <HdkR> steev: Quality ISP there

07:16 <steev> yeah....

07:16 <steev> they still aren't sure where the issue is

07:16 <steev> 1112 packets transmitted, 684 received, 38.4892% packet loss, time 1128417ms

07:16 <steev> rtt min/avg/max/mdev = 270.606/5849.017/23847.354/6032.037 ms, pipe 24

07:17 <steev> the good news - irc works. as does lore. bad news is, b4 times out every freaking time

07:18 <steev> i'm guessing i need to kill off the dkim check because if it doesn't get a response in 5 seconds it considers it a timeout and kills it

16:03 <bamse> steev: seems i screwed up one of the binding changes, but this should interest you https://lore.kernel.org/linux-arm-msm/20221028034155.5580-1-quic_bjorande@quicinc.com/ ...and i'm interested in testing :)

16:55 <clover[m]> nice, RAM go brr

16:57 <HdkR> Nice indeed

17:47 <steev> bamse: that was why i was complaining about b4 timing out

17:48 <steev> i saw it, and was v interested, have been using it today (i dropped the binding bit since yeah, don't need that to actually test :D)

18:06 <steev> mani's thermal stuff is also of interest :D

18:28 <steev> holy, i didn't realize the change was that much

18:31 <steev> bamse: https://paste.debian.net/1258626

18:40 <bamse> so what are you going to do with all that extra bandwidth?!

18:40 <steev> point and laugh at all the arch users who don't have it

18:41 <steev> gonna use it to do more work :(

18:41 <bamse> i wanted to run geekbench again...but i don't have johan's pcie patches in my current branch

18:41 <bamse> steev: https://www.geekbench.com/blog/2021/03/geekbench-54/ would you mind?

18:47 <steev> sure

18:51 <bamse> iirc we were 12% slower than windows before

18:55 <steev> this first one will be 6.0.5 with your patches on top (and a few other ones), will try johan's 6.1 rc2 with your patches on top after

18:57 <steev> https://browser.geekbench.com/v5/cpu/18284519

19:02 <bamse> nice!

19:02 <bamse> https://browser.geekbench.com/v5/cpu/compare/18284519?baseline=18076980

19:02 <steev> 6.1 rc2 test going now

19:05 <ajhalaney[m]> wow that's a nice increase

19:06 <steev> hmm, something seems off with the 6.1 rc2 results...

19:06 <steev> but https://browser.geekbench.com/v5/cpu/18284652

19:06 <steev> ah yeah, something about the timers?

19:07 <steev> that's just using the defconfig, let me slap my kernel config in

19:14 <bamse> pretty good score for a 0MHz core

19:15 <steev> Lol

19:20 <steev> bamse: do you want me to include those mybw numbers in my t-b email?

19:22 <bamse> steev: sure

19:23 <clover[m]> give us arch users a crumb

19:23 <steev> i gotta back out like 100 patches first before i can push that branch :(

19:23 <steev> they're unrelated to anything y'all would use

19:24 <steev> and wouldn't affect benchmarks either

19:24 <bamse> clover[m]: you should be able to just apply those patches onto whatever tree you have

19:25 <steev> yeah, just drop the binding patch because it won't apply cleanly (or with fuzz)

19:56 <steev> https://github.com/steev/linux/tree/lenovo-x13s-6.0-bwmon there's a branch with it applied... i think i got rid of everything that is still very much in flux

20:01 <steev> ajhalaney[m]: that reminds me - your commit mentions SECCOMP, and i tried enabling it here too.. and i simply can't get it to actually enable in the defconfig (or more specifically, it seems like it goes away no matter what in a savedefconfig)

20:02 <ajhalaney[m]> thanks I'd love if you'd pull that in. I saw it too, that's cuz SECCOMP is default y I believe (going off memory) so a defconfig won't list it explicitly steev

20:02 <steev> i did pull it in :)

20:02 <steev> they made sense, and they don't break things on debian based systems

20:07 <steev> i think it would help out the arch-y type peeps too cuz iirc they use ~~gummiboot~~systemd-boot

20:10 <ajhalaney[m]> for some reason fedora's grub just wouldn't work with the x13s, never looked into it deeply. I've come to like systemd-boot after being forced to use it! I'll play with that branch hopefully before calling it quits on the computers today :D

20:25 <steev> :D

21:11 <ajhalaney[m]> steev: boots well for me (way faster boot, not completely sure why haven't really looked at the diff between that branch and your 6.0.3 tag!), but I see you dropped this SECCOMP bit when applying my patch, _not_ having the "is not set part" is what gets CONFIG_SECCOMP to be set when running make laptop_defconfig:

21:11 <ajhalaney[m]> So I'll locally redo that and rebuild! If you could squash that in or fixup the patch that would be much appreciated as others I know running fedora use your branches right now on x13s too

21:11 <ajhalaney[m]> https://gitlab.com/ahalaney/linux/-/commit/32cafd9e435dd9380a6a9ef50f0d2fa13e30ea95#5d944845a757b7c7444702ef992568122d21ba33_122_122

21:13 <steev> hm, i don't quite follow - unlike every other option... having it is not set... sets it?

21:15 <ajhalaney[m]> The line I linked to from my branch is what makes it _get_ set when you run make laptop_defconfig. My naive understanding is defconfigs don't specify non-defaults, and CONFIG_SECCOMP is a default. So having "# CONFIG_SECCOMP is not set" in the defconfig is turning it off

21:15 <ajhalaney[m]> probably explained that poorly :)

21:17 <ajhalaney[m]> i.e. if you remove the "# CONFIG_SECCOMP is not set" line in your defconfig you should have CONFIG_SECCOMP=y after config generation, and that's what my patch had as well. Somehow when you cherry-picked it into your branch that part got dropped which results in no SECCOMP

21:19 <steev> ohhhh

21:19 <steev> got ya, okay

21:19 <steev> sorry!

21:19 <steev> working on some go packages at the moment, but will get that fixed up! and thanks for the explanation!

21:19 <ajhalaney[m]> No problem and absolutely no worries!