02:27 <bamse> jenneron[m]: regarding audio, i believe vkoul looked at that a while back, but had some problems which sounds like they where resolved on sc8280xp

03:14 <HdkR> steev: Initial testing showing a decent amount of time in soft-irq on core 0, but lacking any long term testing it seems better

03:18 <HdkR> and this 5gbit NIC hasn't oopsed the kernel yet

03:24 <HdkR> 10% in __do_softirq, 13.35% in _raw_spin_unlock_irqrestore, bunch of clear_page, dcache_clean_poc and other things as well. Very interesting

03:34 <steev> bamse: ^

03:36 <bamse> HdkR: previously i saw cpu0 appraching 100% load when running iperf3 at 110mbit/s...now i can do 940mbit/s - but i don't have a convenient way to track the load during the test on that machine

03:39 <HdkR> I definitely need to recheck this 10gbit line to this laptop, I think it is only running at 1gbit for some reason. I might have swapped a cable on my switch

04:24 <HdkR> bamse: Alright, fixed the 10gbe connection so the laptop can have a proper 5gbit capable NIC. fio over the connection can now hit the 5gbit maximum, which does still have a decent softirq overhead on core0

04:25 <HdkR> I had switched the whole line to 1gbit while debugging other things, but now I can see Steam validating a game at 200MB/s which is nice

04:30 <HdkR> https://gist.github.com/Sonicadvance1/43ea87ab1289e80788a1531c89e05ce2 perf top -U -c 0 while running a fio bench

04:33 <HdkR> I'll leave the laptop idling and see if it manages to oops itself. Looks like that is fixed though

07:05 <travmurav[m]> hexdump0815: Cool, though it would be a bit hard for me to review and provide comments on a dedicated file, any chance you can create a branch on top of the 6.6 for example, with your dts commit (new dts and makefile change), and open a github PR into your own base branch, so I can leave review comments on line ranges via PR UI? Then we can polish it out into a patch you can just send :)

12:36 <jhovold> robclark, dianders: thanks for finding the missing dpu setting!

12:37 <jhovold> I posted some numbers here: https://lore.kernel.org/lkml/ZUD0lhStirf8IN8-@hovoldconsulting.com/

12:38 <jhovold> look like lazy iommu mode still gives better throughput, put notably adding the missing dpu settings *and* using lazy iommu is the only combination that appears to saturate my gigabit link

12:42 <robclark> jhovold: nice.. perhaps there is still some room for SoC specific udev rules like https://chromium.googlesource.com/chromiumos/overlays/board-overlays/+/refs/heads/main/baseboard-trogdor/chromeos-base/chromeos-bsp-baseboard-trogdor/files/98-qcom-nonstrict-iommu.rules so that dma masters without firmware can be non-strict

12:43 <jhovold> I've updated the latest wip branch so that it includes the DPU fix now: https://github.com/jhovold/linux/tree/wip/sc8280xp-v6.6

12:46 <jhovold> robclark: so it seems, at least for the time being

12:50 <robclark> I think the feeling is this sort of policy should be in userspace rather than the kernel.. but at least for CrOS what we landed on was that we were comfortable from security PoV using "lazy" mode for things that didn't have some sort of firmware (ie. not lazy for dsp/modem/etc.. but ok to be lazy for usb/emmc/etc).. but dianders was more directly involved, this is just my 2nd-hand recollection

12:59 <_[m]1> ok so new kernel on ubuntu (don't know which one, laptop-1005) - downloading dota -> crash (was also running update-grub)

13:00 <_[m]1> * running update-grub because removing the iommu)

13:00 <_[m]1> * running update-grub because removing the iommu), * ) - 1 reboot loop occured after fde

13:00 <_[m]1> * on ubuntu mantic (don't know, * running update-grub because removing the iommu), * ) - 1 reboot loop occured after fde

13:05 <_[m]1> ```

13:05 <_[m]1> 2023-10-31T13:57:57.087607+01:00 upowerd[2072]: g_udev_device_get_sysfs_path: assertion 'G_UDEV_IS_DEVICE (device)' failed

13:05 <_[m]1> 2023-10-31T13:57:57.087827+01:00 upowerd[2072]: g_udev_client_query_by_sysfs_path: assertion 'sysfs_path != NULL' failed

13:07 <_[m]1> 128Mbps down on steam over wifi which is neat

13:45 <dianders> robclark, jhovold: Yeah, the userspace / the udev rules were what was decided upon in the discussion several years ago as the upstream solution. If you follow some of the "for history" links on the udev rules that Rob points at you at you get a bunch of context, notably my longwinded discussion in <https://crrev.com/c/2986602> and a little more in <https://crrev.com/c/2991743>.

15:40 <bamse> HdkR, jhovold: the DMA-FQ takes the tlbsync out of the hotpath, so i can see why that still benefits us...

15:41 <bamse> HdkR: but if you can crash the kernel/system with DMA-FQ and pushing enough data, i'd say that indicates that we're postponing too much work...feels like a buggy state that the system should prevent us from entering

15:43 <robclark> btw, my x13s keyboard decided to take a vacation just earlier.. reboot "fixed" it.. didn't see anything too interesting in dmesg.. kinda strange

17:13 <jhovold> dianders: thanks for the links, i'll take a look

18:00 <clover[m]> 6.6.0 pushed for arch linux users

18:06 <steev> woo

18:24 <clover[m]> looks like we will be able to use upstream alca-ucm-conf soon, i see some of sriniks changes pulled into master branch

18:35 <clover[m]> also bumped the mesa and linux-firmware packages but i don't think x13s has any new stuff for those at this point

18:53 <steev> yeah, johan mentioned the merge request was accepted

19:03 <steev> that will be exciting

19:04 <jenneron[m]> bamse: so, do we need a udev rule? or is that patch enough

19:04 <jenneron[m]> also, it's fine to drop those cmdlines, right?

19:19 <steev> yes

20:40 <agl7> steev: Are you ready with version 6.6 of your kernel?

20:40 <steev> ?

20:41 <agl7> I mean have you patched the kernel 6.6?

20:41 <steev> yes, see the conversation from last night

20:41 <agl7> ok

20:42 <hexdump0815> travmurav[m]: good idea - i'll prepare such a kernel tree, branch and pr during the next days and let you know

21:13 <bamse> jenneron[m]: i find the patch alone sufficient...but HdkR's use cases are more demanding

21:14 <bamse> jenneron[m]: i got a patch for sc8180x as well, but apparently the sc8180x primus doesn't have working display/gpu in linux-next, trying to resolve that so that i can test the patch

21:40 <DanaG> Huh, apparently this is what's going on with the Surface Pro X in Windows, no wonder OpenGL stuff looks so garbled. But I don't think Linux is really in a usable state on the SPX. https://www.reddit.com/r/opengl/comments/1755c97/if_youre_using_opengl_with_qualcomm_snapdragon/

22:00 <Jasper[m]> <DanaG> "Huh, apparently this is what's..." <- Might be a bug in their translation layer

22:00 <Jasper[m]> They do OpenGL on D3D12 afaik

22:02 <DanaG> Yeah, it's translated... but supposedly it's only gen1/gen2 that have the issue, according to that post.

22:02 <DanaG> It's possible it's actually all of them, though. I don't have a gen3 to test.

22:03 <Jasper[m]> I could test on Volterra

22:03 <Jasper[m]> I have no program that does that though

22:05 <DanaG> If you have the data files for RCT2, OpenRCT2 (native arm64 build available) is a good test. Though when I installed it, it was missing a g2.dat file that I had to grab from the i386/x86-64 build.

22:08 <HdkR> bamse: Left the system running overnight and the 5gbit adapter didn't oops the kernel. Looks like whatever was causing the problem was fixed

22:15 <HdkR> I'll hammer it more today with my regular use case and see if something happens though

22:41 <agl7> steev: Kernel 6.6 runs. It seems all is OK.

22:43 <agl7> steev: Oh ... I have only the "Dummy Output" device for the sound :-(

22:44 <agl7> Have I updated the firmware?

22:44 <agl7> *update

22:46 <steev> no, nothing has changed on that front in a while