00:01 <steev> calebccff: re the sensors... as someone without an android, what file(s) are typically loaded by that?

00:25 <agl7> steev, HdkR & ajhalaney[m]: I tried that with the IOMMU_DEFAULT_DMA_LAZY=y. Indeed, I have now no longer 34 MB/s but 231,8 MB/s * 8 = 1854,4 Mbit/s (pure data without the TCP/IP overhead)!

00:26 <HdkR> Huh weird

00:26 <HdkR> Maybe iommu.strict=0 behaviour is slightly different than IOMMU_DEFAULT_DMA_LAZY=y?

00:26 <agl7> With an 2,5 Gbit/s Ethernet <--> USB-C Adapter

00:30 <HdkR> Oh, I already had that option. wtf

00:38 <agl7> HdkR: In the help under the menuconfig for the IOMMU_DEFAULT_DMA_LAZY there are two parameters that need to be specified in the cmdline: "iommu.passthrough=0 iommu.strict=0"

00:40 <HdkR> Guess it doesn't really matter when I had the compile option already enabled anyway

00:40 <HdkR> But good to know

00:40 <HdkR> Sounds like I just need to route 2.5gbe to the thing and see if that resolves it

00:41 <steev> interesting that it defaults to lazy for only x86/ia64

00:43 <calebccff> steev: see etc/qcom and var/lib/qcom/sensors in this repo, the paths will definitely be different but you're looking for similar files with similar names https://gitlab.com/sdm845-mainline/firmware-shift-sdm845

00:44 <agl7> I have switched on IOMMU_DEFAULT_DMA_LAZY over menuconfig under the ThinkPad X13s. The two other Options must be disabled!

00:45 <agl7> In menuconfig you can only switch on one of the three Options!

00:45 <agl7> The other two are disabled.

00:46 <steev> calebccff: oh, if memory serves... some of those are on the ufs partitions

00:46 <calebccff> that sounds about right :D

00:47 <steev> but just booted my c630 into windows for the first time since august of 2022, apparently, since thats what it thinks the date still is

00:51 <calebccff> lol

00:56 <steev> qcsensorsconfigcls850.inf_arm64_a4738dda00d434ba

00:56 <agl7-x13s> HdkR: I have the ACASIS box with power, a SSD and a 1 Gbit/s ethernet adapter at the first USB-C port. There now the speed for putting e.g. a 6 GiB file is very high!

00:56 <steev> only has them as json files?

01:04 <steev> calebccff: https://paste.debian.net/1279132/

01:05 <calebccff> steev: looks perfect, wonder why you have msm8996 and 8909 stuff lol

01:05 <steev> that's just what all the c630 has in the drivers :)

01:07 <calebccff> the sns_reg.conf file is meant to be paths to some specific sysfs things the SSC wants to know, I see they're in there as files. platform_subtype, soc_id, etc... The daemon we have rewrites those paths anyway so you cna probably just borrow the one from axolotl and adjust the paths if the c630 firmware is different

01:09 <calebccff> the other stuff (var/lib/qcom/sensors) is calibration data which would get written so, so it might be somewhere else...

01:12 <steev> pretty sure that stuff is definitely in the partitions

01:12 <HdkR> agl7-x13s: Alright, got a type-c 2.5G/5G NIC coming, will see if I can replicate. Maybe these little Dell 1gbe adapters just suck

01:12 <HdkR> Although doesn't explain why I could replicate with an SSD

01:13 <steev> of course dell sucks

01:14 <steev> WE ARE A LENOVO FAMILY HERE HdkR, YOU'RE BREAKING YOUR FATHER'S HEART

01:15 <HdkR> hah

01:32 <agl7-x13s> hihi

01:42 <agl7-x13s> Here in Europe is it now 3:42 AM ... I'am going now to bed ... Good Night!

10:35 <agl7> HdkR: The Options for ...DMA_LAZY=Y must be set like the following:

10:35 <agl7> # CONFIG_IOMMU_DEFAULT_DMA_STRICT is not set

10:35 <agl7> # CONFIG_IOMMU_DEFAULT_PASSTHROUGH is not set

10:35 <agl7> CONFIG_IOMMU_DEFAULT_DMA_LAZY=y

10:35 <agl7> CONFIG_OF_IOMMU=y

10:35 <agl7> CONFIG_IOMMU_DMA=y

10:36 <agl7> STRICT and PASSTHROUGH Must be dissabled!!!

10:43 <HdkR> That matches my config

11:41 <jhovold> HdkR, agl7: fwiw, I'm also saturating my Gigabit switch with CONFIG_IOMMU_DEFAULT_DMA_LAZY or the equivalent command line parameters (e.g. 100 MB/s scp in both directions)

11:42 <jhovold> get about 12 MB/s with STRICT

13:28 <ajhalaney[m]> Ok, cool so maybe HdkR just is the ugly duckling in this instance :P

14:29 <agl7> jhovold: You can only see a significant throughput at ....DMA_LAZY=y and when you attach an SSD to one of the USB ports of the ThinkPad X13s, for example. Before I set the option, saving a 6 GB file took almost 2 minutes. After setting the option ...DMA_LAZY=y (via menuconfig) it took only 3 seconds!!!

14:29 <agl7> The same with a 2.5 Fbit/S Ethernet <--> USB-C adapter here were before setting the option only 34 MB / s of throughput. After setting the option, it was 232.8 MB/s (> 1800 Mbits/s, only data)!!!

14:31 <jhovold> agl7: yes, it's a known issue, but fortunately we have the DMA_LAZY workaround

16:16 <init_x13s> HdkR: I mentionned a couple days ago that I wasn't able to build mesa, even the ones that used to build due to a segfault in lto. well, turns out it was directly related to the bug fixed in 6.3.1 on vm_pgoff.

16:17 <init_x13s> no more segfault

17:17 <steev> well thats good to hear

17:20 <init_x13s> steev: how usable is your 6.3.y?

17:21 <init_x13s> i built a gonzo-patched version pf 6.3.1 just to test the build, but there was a lot of issues with my build.

17:21 <init_x13s> "test the mesa build"

17:21 <steev> uhh, i've been using it for quite a while?

17:21 <init_x13s> nice

17:21 <init_x13s> ill switch to it then

17:21 <steev> i don't push out stuff i haven't tested

17:21 <init_x13s> im running your 6.3.0

17:32 <steev> the newer 6.3.1 that i just pushed should allow less heat, there's a few more bug fixes in, but i still have orientation switching (v1) and not johan's fixes that v2 should be based upon, yet

17:32 <init_x13s> cool. not using an external screen anyways.

18:01 <steev> oh dang it, i just realized my push incorporates your change into one of my patches

18:01 <steev> i need to back that part out, and do it again

18:06 <init_x13s> if you're talking about the interrupt, the good news at least is that it's quite stable. I have been runnng with my patch since rc4.

18:06 <init_x13s> heh

18:08 <steev> yeah, i pushed it out, incorporating calebccff's suggested changes to you for it :)

18:09 <steev> https://github.com/steev/linux/commit/128535132ece63a562e69cd509f235110c5d6a09

18:09 <init_x13s> cool

18:32 <steev> you'd need to resubmit it though, although i'd wait for others to possibly chime in

18:35 <init_x13s> that was my plan

18:37 <init_x13s> I still don't think it's hyper valuable to fix the problem we're experiencing however.

18:37 <init_x13s> that might require a completely new driver, or it might even be unfixable.

18:38 <init_x13s> HID over SPI is not that common

18:48 <HdkR> init_x13s: Spooky bug

18:49 <init_x13s> surprisingly I had no other issues building anything except mesa.

18:49 <init_x13s> the bug fix mentionned that "some rpm failed to build"

18:50 <init_x13s> im just happy that someone found out quickly

18:55 <init_x13s> i seem to be missing hpnv21.b8c on steev 4.3.1, where can I grab this

18:55 <steev> the x13s-firmware repo

18:55 <steev> or your windows partition

18:55 <init_x13s> my package must be broken then.

18:56 <steev> oh

18:56 <steev> just rename/symlink

18:56 <steev> it was originally b8c, then renamed in the repo

18:56 <init_x13s> just saw this

18:56 <init_x13s> thx

19:10 <init_x13s> humm this is weird with no firmware load error, and no specific error in journalctl/dmesg. i have BT under 4.3.0 but not under 4.3.1 from steev/4.3.y

19:10 <init_x13s> wireless works

19:11 <init_x13s> Bluetooth: hci0: QCA Downloading qca/hpbtfw21.tlv

19:11 <init_x13s> looks good

19:11 <init_x13s> might be my config

19:11 <init_x13s> i use a config that I have been carrying for a while now

19:22 <steev> read the bt commit messages

19:22 <steev> or the channel backlog

19:23 <init_x13s> i dont have the backlog, im limited to the webclient. il check the commit

19:24 <steev> https://oftc.irclog.whitequark.org/aarch64-laptops/

19:24 <init_x13s> TIL