01:15 <steev> sort of

01:15 <steev> they're saying if you're a device manufacturer, you can hire them to do the widevine support

01:15 <steev> for your device*

02:38 <steev> https://developer.nvidia.com/blog/applying-generative-ai-for-cve-analysis-at-an-enterprise-scale/

02:40 <steev> For our workflow, we found that the model struggled to compare package version numbers such as version 1.9.1 coming before 1.10.

02:40 <steev> classsic llm

04:48 <JensGlathe[m]> <robclark> "zap shader just clears the GPU..." <- so when on EL2 we just don't need this? There's a firmware loaded in this dt node

04:52 <steev> in el2 the gpu is already kicked out of secure mode. in el1, the zap shader is used to kick it out of secure mode

04:54 <travmurav[m]> > Dylanger "I can understand the security risks [of EL2]

05:02 <travmurav[m]> steev: no remoteprocs? <- Yes, since qcom's hyp boots them, in EL2 linux needs to do a bit more work. There is a driver for CROS that almost worked for me when I tried to kick adsp on but I didn't get it to fully work. + there would need to be some soc-specific work, likely including some RE of the hyp to understand which resources to start for given rproc

05:03 <travmurav[m]> pcie works (worked? xD) after we mapped the iommu to it properly so it's only rprocs left afaik (so no sound, and I guess battmgr...)

05:39 <steev> that is, way above my pay grade. i'd still love to figure out what the hell is causing the frame reassembly failed message we get (sometimes? at least on first boot)with blueooth, but i really have no idea how to track it down

07:18 <steveej[m]> is there software for arm laptops to limit battery charging up to a certain %? something similar to tlp, or maybe tlp can be made work on aarch64?

07:56 <JensGlathe[m]> There is a working patch for the 6.10-rc1 update https://lore.kernel.org/linux-iommu/159193e80b6a7701c61b32d6119ac68989d457bd.1716997607.git.robin.murphy@arm.com/

07:57 <JensGlathe[m]> my repo is updated

08:06 <JensGlathe[m]> * There is a working patch for the 6.10-rc1 EL2 issue https://lore.kernel.org/linux-iommu/159193e80b6a7701c61b32d6119ac68989d457bd.1716997607.git.robin.murphy@arm.com/

13:34 <mynery[m]> okay, newer kernel with arm64.nopauth parameter does not get stuck after dtb, but it now just doesn't find the disk with the uuid, which it does perfectly fine with an older kernel

13:46 <JensGlathe[m]> You're booting from nvme?

14:23 <mynery[m]> I do, yes

14:24 <mynery[m]> Do other people not do that?

14:24 <jhovold> we are

14:24 <jhovold> you're likely missing something in your kernel config or initramfs

14:24 <jhovold> you didn't say which kernel and config you use

14:24 <jhovold> (or used to use)

14:25 <jhovold> but to sum up, newer kernel work just fine, there's just something wrong in your setup

14:29 <mynery[m]> i use a pre-built kernel. seems to be broken then. i might just try building one myself, but i have never done that and it feels a bit daunting

14:38 <jhovold> pre-built from where?

14:38 <jhovold> it's not necessarily broken, maybe configured differently from what you setup expects

14:38 <jhovold> your

14:48 <pstef_> Fedora installer formats root fs as btrfs, so your kernel will need that in

14:48 <pstef_> I don't mean a specific you

14:48 <JensGlathe[m]> compiled in

14:49 <pstef_> that's what I meant, but perhaps it could work as a module if it was included in initramfs

14:53 <JensGlathe[m]> I had this issue once, to mount as rootfs it needs to be compiled in afair

15:05 <mynery[m]> <jhovold> "pre-built from where?" <- https://github.com/ironrobin/x13s-alarm

15:07 <agl> jenneron[m]: Galaxy Book S (sc8180x): Do you know which driver acces the internal NVME-Disk? An NVME-driver (nvme) is not loaded. It seems the SoC access the NVME-disk.

15:07 <jenneron[m]> agl: there is no NVME, it is UFS

15:07 <jenneron[m]> it should work

15:07 <agl> ok

15:08 <agl> Thank you

16:15 <craftyguy> how do I type sysrq on the x13s? I thought maybe fn+prtsc but that doesn't seem to be it?

16:16 <jenneron[m]> craftyguy: can't really answer your question, but if there is no key that you need you can bind some hotkey with keyd

16:16 <jenneron[m]> we do that for chromebooks in pmOS

16:17 <craftyguy> ya I need to do the magic sysrq dance to sync/reboot, not sure how well a userspace thing would work for that

16:18 <travmurav[m]> craftyguy: probably just alt prscr s-u-b?

16:18 <travmurav[m]> without fn

16:19 <travmurav[m]> at least for me that works

16:19 <craftyguy> nothing either. I lost display so I can't see what's going on, maybe it's a hard hang

16:19 <travmurav[m]> since on aspire1 prscr is on the top layer, dunno about x13s

16:19 <craftyguy> prtscr on the x13s is top layer too

16:20 <travmurav[m]> if it didn't die on alt prscr b then possibly very dead (or sysrq is disabled)

16:20 <jenneron[m]> craftyguy: my lenovo laptop (yoga 5g) can be force-rebooted by pressing power button for 20-30 seconds if this is what you need

16:20 <craftyguy> magic sysrq is enabled in thr kernel

16:20 <travmurav[m]> can always poke the hole on the bottom xD

16:20 <travmurav[m]> and then ig check if the kernel reports the message in dmesg

16:21 <craftyguy> jenneron: ya I was hoping to at least sync fs before forcing it off :(

16:21 <jenneron[m]> ah yeah

16:21 <jenneron[m]> we (pmOS) don't do fsck despite doing journaling ext4

16:22 <craftyguy> yeah..

16:25 <craftyguy> jensglathe: ya that patch also fixes nvme boot on el2 for me too \o/

16:27 <travmurav[m]> cool so it was a global issue after all and would be fixed in next rc xD

16:33 <craftyguy> yeah, lucky for us :P

17:18 <exeat> craftyguy: this works for me: hold left alt, press and release prtsc, press s, release left alt

17:29 <craftyguy> robclark: is gpu 3d accel working for you on the x13s under qemu/kvm? (I'm trying with qemu -device virtio-gpu-gl, not sure if I should be using something else)

17:29 <craftyguy> exeat: ahh, ok I'll remember that for next time. thank you :)

17:32 <agl> jenneron[m]: I now have Debian/Testing(trixie) running on my Galaxy Book S. I'm using the kernel whose URL you gave me a few days ago. Everything works except WLAN and battery control. Also Bluetooth.

17:32 <jenneron[m]> yeah no idea what is wrong with wifi/bt

17:32 <jenneron[m]> maybe mismatch uefi firmware and firmware files i provide, idk

17:33 <jenneron[m]> wifi/bt worked a while ago

17:33 <agl> jenneron[m]: Bluetooth works, only wifi not.

17:34 <travmurav[m]> rmtfs? tqftpserv?

17:34 <travmurav[m]> agl: both services need to run for wifi + firmware blobs for the specific device

17:34 <jenneron[m]> travmurav: no

17:35 <jenneron[m]> it doesn't work in pmOS

17:35 <travmurav[m]> uh

17:35 <jenneron[m]> without any changes in firmware and userspace services

17:35 <travmurav[m]> oh so it broke at some point?

17:35 <jenneron[m]> i bet 10% that it is some kernel regression and 90% that something changed in uefi firmware after windows update

17:35 <travmurav[m]> I dont think firmware should matter since linux should kill/restart rprocs

17:36 <jenneron[m]> then i don't know

17:36 <jenneron[m]> i don't work on it anymore

17:37 <travmurav[m]> but yeah, I'd still suggest to at least check for obvious things in case it just works again xD

17:37 <travmurav[m]> thus suggested to make sure userspace bits are there

18:04 <jenneron[m]> right

18:11 <robclark> craftyguy: yeah.. but I had some qemu patches to enable native-context.. (the older slower virgl stuff should "just work" I think)

18:12 <robclark> should be something along the lines of https://gitlab.freedesktop.org/digetx/qemu/-/commits/fence-passing/?ref_type=heads

18:48 <steev> why it has to be named venus too :(

18:50 <robclark> iirc the new driver that was proposed was "iris".. which ofc also conflicts with a mesa driver name

18:52 <craftyguy> hmm ok, I get some errors when trying to start gnome-shell in a VM, I guess it's using virgl with the option I passed earlier?

18:52 <robclark> do you have /dev/dri/* in the guest?

18:57 <robclark> craftyguy: fyi, this is how I was launching qemu:

18:58 <robclark> https://www.irccloud.com/pastebin/ZjJMOOeu/

19:02 <craftyguy> ya /dev/dri/* exists. thanks for sharing the cli params, I need to step away for a bit but will compare what you're doing to what I am doing

19:05 <craftyguy> ok when using the same options for virtio-gpu-gl, it fails because /dev/udmabuf doesn't exist

19:15 <craftyguy> ok think I got it

21:54 <steev> does anyone else see the big cores setting themselves to 900mhz when setting the governor to performance?

21:54 <steev> on the x13s

21:59 <steev> i'm not even close to thermal

22:00 <steev> https://www.irccloud.com/pastebin/GZZxTv2L/

22:00 <steev> konradybcio: since i've seen you play with it a bit... ^^ how do i force the x1c's to go to 2.9

22:01 <steev> this is 6.10-rc2

22:02 <steev> and thermally, i'm only at 42C

22:03 <konradybcio> steev: im afraid that would necessitate a move to siberia or antarctica

22:04 <konradybcio> doing anything on the x1c cores causes the x13s to just get overran with heat, 8280 is not a fanless-friendly chip

22:06 <steev> i mean, i'd be fine with that... seems a bit silly to stick at 900mhz

22:06 <HdkR> It's always nice having a portable sun as a space heater

22:09 <steev> i'd like these python compiles to finish sometime this year :(

22:15 <HdkR> upgrade to a system with a fan :P

22:15 <steev> i don't think it would matter

22:15 <steev> 42C is a pittance. the c630 doesn't even consider throttling til 95C

22:19 <craftyguy> is it possible to set battery charging thresholds on the x13s? I didn't see any obvious "_threshold_" things in sysfs

22:20 <colemickens> any rumors on which elite x laptop will have a DTS earliest?

22:23 <HdkR> Maybe we can do horse race style betting on who implements their respective DTs the fastest.

22:27 <konradybcio> HdkR: such races usually dont end well :p

22:27 <colemickens> I'm torn between Yoga 7x / Surface Pro 11. I feel like the Lenovo might be better supported out of box, but Surface Pro seems to always wind up with a long-tail of users/supportt.

22:28 <colemickens> Surface Pro 11 with the new BT keyboard cover and/or my new portable split mech keeb could be kind of dope for remote work-y scenarios.