ChanServ changed the topic of #aarch64-laptops to: Linux support for AArch64 Laptops (Asus NovaGo TP370QL - HP Envy x2 - Lenovo Mixx 630 - Lenovo Yoga C630)
<steev> calebccff: re the sensors... as someone without an android, what file(s) are typically loaded by that?
<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)!
<HdkR> Huh weird
<HdkR> Maybe iommu.strict=0 behaviour is slightly different than IOMMU_DEFAULT_DMA_LAZY=y?
<agl7> With an 2,5 Gbit/s Ethernet <--> USB-C Adapter
<HdkR> Oh, I already had that option. wtf
<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"
<HdkR> Guess it doesn't really matter when I had the compile option already enabled anyway
<HdkR> But good to know
<HdkR> Sounds like I just need to route 2.5gbe to the thing and see if that resolves it
<steev> interesting that it defaults to lazy for only x86/ia64
<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
<agl7> I have switched on IOMMU_DEFAULT_DMA_LAZY over menuconfig under the ThinkPad X13s. The two other Options must be disabled!
<agl7> In menuconfig you can only switch on one of the three Options!
<agl7> The other two are disabled.
<steev> calebccff: oh, if memory serves... some of those are on the ufs partitions
<calebccff> that sounds about right :D
<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
<calebccff> lol
<steev> qcsensorsconfigcls850.inf_arm64_a4738dda00d434ba
<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!
<steev> only has them as json files?
<calebccff> steev: looks perfect, wonder why you have msm8996 and 8909 stuff lol
<steev> that's just what all the c630 has in the drivers :)
<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
<calebccff> the other stuff (var/lib/qcom/sensors) is calibration data which would get written so, so it might be somewhere else...
<steev> pretty sure that stuff is definitely in the partitions
<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
<HdkR> Although doesn't explain why I could replicate with an SSD
<steev> of course dell sucks
<HdkR> hah
Erisa has quit [Quit: Ping timeout (120 seconds)]
<agl7-x13s> hihi
Erisa has joined #aarch64-laptops
<agl7-x13s> Here in Europe is it now 3:42 AM ... I'am going now to bed ... Good Night!
agl7-x13s has quit [Quit: Leaving]
hexdump01 has joined #aarch64-laptops
hexdump0815 has quit [Ping timeout: 480 seconds]
iivanov has joined #aarch64-laptops
<agl7> HdkR: The Options for ...DMA_LAZY=Y must be set like the following:
<agl7> STRICT and PASSTHROUGH Must be dissabled!!!
<HdkR> That matches my config
alpernebbi has quit [Quit: alpernebbi]
<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)
<jhovold> get about 12 MB/s with STRICT
alpernebbi has joined #aarch64-laptops
init_x13s has quit [Remote host closed the connection]
Bioxvirizm[m] is now known as Bioxvirizm-x13s[m]
<ajhalaney[m]> Ok, cool so maybe HdkR just is the ugly duckling in this instance :P
<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!!!
<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)!!!
<jhovold> agl7: yes, it's a known issue, but fortunately we have the DMA_LAZY workaround
agl7-x13s has joined #aarch64-laptops
init_x13s has joined #aarch64-laptops
<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.
<init_x13s> no more segfault
iivanov has quit [Quit: - Chat comfortably. Anywhere.]
<steev> well thats good to hear
<init_x13s> steev: how usable is your 6.3.y?
<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.
<init_x13s> "test the mesa build"
<steev> uhh, i've been using it for quite a while?
<init_x13s> nice
<init_x13s> ill switch to it then
<steev> i don't push out stuff i haven't tested
<init_x13s> im running your 6.3.0
<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
<init_x13s> cool. not using an external screen anyways.
<steev> oh dang it, i just realized my push incorporates your change into one of my patches
<steev> i need to back that part out, and do it again
<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.
<init_x13s> heh
<steev> yeah, i pushed it out, incorporating calebccff's suggested changes to you for it :)
<init_x13s> cool
<steev> you'd need to resubmit it though, although i'd wait for others to possibly chime in
<init_x13s> that was my plan
<init_x13s> I still don't think it's hyper valuable to fix the problem we're experiencing however.
<init_x13s> that might require a completely new driver, or it might even be unfixable.
<init_x13s> HID over SPI is not that common
<HdkR> init_x13s: Spooky bug
<init_x13s> surprisingly I had no other issues building anything except mesa.
<init_x13s> the bug fix mentionned that "some rpm failed to build"
<init_x13s> im just happy that someone found out quickly
init_x13s has quit [Remote host closed the connection]
init_x13s has joined #aarch64-laptops
<init_x13s> i seem to be missing hpnv21.b8c on steev 4.3.1, where can I grab this
<steev> the x13s-firmware repo
<steev> or your windows partition
<init_x13s> my package must be broken then.
<steev> oh
<steev> just rename/symlink
<steev> it was originally b8c, then renamed in the repo
<init_x13s> just saw this
<init_x13s> thx
init_x13s has quit [Remote host closed the connection]
init_x13s has joined #aarch64-laptops
<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
<init_x13s> wireless works
<init_x13s> Bluetooth: hci0: QCA Downloading qca/hpbtfw21.tlv
<init_x13s> looks good
<init_x13s> might be my config
<init_x13s> i use a config that I have been carrying for a while now
<steev> read the bt commit messages
<steev> or the channel backlog
<init_x13s> i dont have the backlog, im limited to the webclient. il check the commit
<init_x13s> TIL
init_x13s has quit [Remote host closed the connection]
hightower2 has quit [Ping timeout: 480 seconds]
derzahl has joined #aarch64-laptops
hightower2 has joined #aarch64-laptops
agl7_ has joined #aarch64-laptops
agl7-x13s_ has joined #aarch64-laptops
agl__ has joined #aarch64-laptops
agl7 has quit [Ping timeout: 480 seconds]
agl7-x13s has quit [Ping timeout: 480 seconds]
agl7-x13s_ has quit [Ping timeout: 480 seconds]
agl7_ has quit [Ping timeout: 480 seconds]
agl7 has joined #aarch64-laptops
agl__ is now known as agl-x13s
agl-x13s is now known as agl7-x13s
derzahl has quit [Remote host closed the connection]
derzahl has joined #aarch64-laptops