02:16 <steev> my understanding is that they aren't reaching a point where they can ls it?

02:17 <steev> i believe you could try regulator_ignore_unused as well, perhaps it won't turn the display off

02:19 <bamse> does dtb= on commandline work these days?

02:19 <bamse> on sc8280xp it would just complain that secureboot was on (or something like that) and ignore it

02:20 <bamse> anonymix007[m]: try using your bootloader to load the dtb instead of the efi-stub

02:22 <steev> it should only complain that secureboot is on, if it's on

02:22 <steev> afaik, clover does it that way

02:27 <bamse> steev: well, i might have given it 2 seconds of attention, but that's what the log told me...

02:28 <steev> i don't actually know :( i put mine on the efi partition not on boot

02:28 <robclark> anonymix007[m], bamse: dtb on cmdline works.. that is what I use. it should be in esp and path is relative to esp

02:28 <steev> oh

02:28 <bamse> steev: i also have no idea which device this was on, so it might not be a relevant data point...hence my question

02:28 <bamse> robclark: cool!

02:28 <robclark> ie. put it in /boot/efi/foo.dtb and use dtb=foo.dtb

02:28 <steev> bamse: t14s iirc

02:29 <robclark> (I've been using dtb= cmdline exclusively.. no idea if fedora's grub supports doing it the other way)

02:29 <steev> robclark: if it's remotely modern it *should* support devicetree=/path/to/it

02:30 <robclark> idk if grub is still a massive pile of distro patchstack on top of upstream like it was a few years ago

02:30 <steev> grub itself supports it, but afaik unless you have a patchset, it doesn't set it up automagically (pmOS and ubuntu do iirc)

02:30 <robclark> but dtb= on cmdline is easy and simple

02:30 <steev> this is true

02:31 <steev> bamse: oh, i have a patch for you, i should submit it. just a minor thing to add wakeup-source to keyboard/touchpad for the flex because i was tired of shutting it and opening it back up to wake it up

02:31 <bamse> if you put DeviceTree=/boot/dtbs/xyz.dtb in your /etc/kernel/uki.conf...then as mkinitcpio generates the uki, it will include that devicetree

02:31 <steev> wtf is uki

02:32 <bamse> steev: it's a package of kernel + ramdisk + optional dtb + optional splash + optional siguature stuff...baked as an efi application

02:32 <steev> ahh

02:32 <bamse> steev: so, you inject all your pieces into one file...and just chainload that from your bootloader

02:33 <steev> https://www.reddit.com/r/debian/comments/1d409q8/secure_boot_for_a_fully_encrypted_disk_using_uki/ seems like debian *can* do it too... if i wanna bother figuring out that atrocious markdown of the post

02:33 <bamse> and per mkinitcpio.conf and uki.conf, as i install the kernel with pacman, it generates the uki, with the right dtb and it shows up in systemd-boot automagically

02:33 <bamse> steev: yeah, i don't do the secure thing...but it looks interesting

02:35 <steev> i was really hoping old.reddit.com would make that readable but somehow it seems worse

02:36 <bamse> so much manual craziness

02:36 <steev> i believe that's just for doing it as part of the installer

02:38 <bamse> steev: install systemd-ukify...so mkinitcpio has something to use...then you should have a /etc/mkinitcpio.d/*.preset for your kernel... this defines your default_image etc...comment out default_image, uncomment default_uki...then put "[UKI]\nDeviceTree=/boot/dtbs/foo.dtb" in /etc/kernel/uki.conf...your kernel commandline in /etc/kernel/cmdline...and run mkinitcpio -p <kernel-name> (the basename of the preset)

02:38 <bamse> out comes a .uki file in the default_uki path...then just chainload that

02:38 <steev> i may give it a whirl

02:39 <bamse> or if you're running systemd-boot, just place it in /boot/EFI/Linux and systemd-boot will find it automagically, not entries needed

03:14 <steev> that's spiffy

08:51 <jhovold> Here's an updated wip branch for the X13s:

08:51 <jhovold> - https://github.com/jhovold/linux/tree/wip/sc8280xp-6.11-rc4

08:51 <jhovold> Changes include:

08:51 <jhovold> - fix pmic_glink client registration race

08:51 <jhovold> - fix efivars regression differently (6.11-rc1 regression)

08:51 <jhovold> - johan_defconfig: enable zram

08:52 <jhovold> And here's an updated wip branch for x1e80100:

08:52 <jhovold> - https://github.com/jhovold/linux/tree/wip/x1e80100-6.11-rc4

08:53 <jhovold> Changes include:

08:53 <jhovold> - fix pmic_glink client registration race

08:53 <jhovold> - fix missing soundwire resets

08:53 <jhovold> - fix wsa soundwire port mappings

08:53 <jhovold> - fix backlight control on yoga

08:53 <jhovold> - fix efivars regression differently (6.11-rc1 regression)

08:53 <jhovold> - johan_defconfig: enable zram

10:14 <anonymix007[m]> bamse: this is what I already do, dtb is passed via grub's `devicetree=` parameter. Either way, it's quite painful to use a keyboard in grub since it constantly registers double clicks and doesn't even support holding keys.

11:05 <anonymix007[m]> jhovold: do you have any suggestions? Cmdline: https://github.com/anonymix007/arch-image-builder/blob/x1e-t14s/configs/target/x1e-t14s.yaml#L40

11:05 <anonymix007[m]> Mkinitcpio config: https://gist.github.com/anonymix007/0bba2d94335af07697044f5f5221445a

11:05 <anonymix007[m]> Kernel is your rc4 wip branch with t14s dts patches on top.

11:06 <anonymix007[m]> The issue is that after this screen just turns black and never comes back

11:45 <Jasper[m]> Has anyone had their Arrow order ship yet?

11:46 <Jasper[m]> <anonymix007[m]> "The issue is that after this..." <- Do you have FDE configured? Could you turn on a ssh service and remote in to fetch logs?

12:38 <anonymix007[m]> No, I don't. How would I do that? I don't have a usb-ethernet dongle and wifi probably won't work yet

13:20 <Jasper[m]> Ah the usb dongle would be a way to do it

13:38 <anonymix007[m]> Is there a way to set up RNDIS USB Gadget early and ssh into this machine from a second PC via USB?

15:48 <mlau> Hello, can anyone please provide a download for a working kernel for the lenovo yoga slim 7x ?

15:48 <mlau> my self built kernels based on jhovold-6.11 tree don't work very well

15:49 <mlau> ath12k throws lots of pcie aer errors, sound drivers are loading but don't register with alsa

15:51 <mlau> while nvme, usb, console and keyboard/touchpad do work quite reliably

16:12 <mlau> also I noticed that the probe of pcie4 itself causes lots of spontaneous reboots

16:13 <mlau> and is it normal that lspci cannot decode the ath12k pci device?

16:15 <kuruczgy[m]> mlau: Here is my prebuilt NixOS install ISO: https://kuruczgy.com/s/yoga_nixos_install.iso

16:15 <kuruczgy[m]> SHA256: 2a0650603f544cd21ee4362d99f077cfd4c31bb24945cfada38f4d05a59f2f0b

16:15 <kuruczgy[m]> For anyone looking at the IRC logs: I will delete this after a few days, but you should be able to build it from my repo, and the iso hash should be reproducible: https://github.com/kuruczgy/x1e-nixos-config/commit/175719dfde875c5dc7f14ae6cbe59ab72797f489

16:20 <mlau> thanks I'll try the kernel in the iso

16:21 <kuruczgy[m]> mlau: You probably also want to extract the modules from the initramfs. But first I would just recommend booting it normally, see if it works, before doing the extraction :)

17:15 <clover[m]> 6.10.5 pushed to ironrobin repos

17:19 <robclark> jhovold: btw mesa 24.2.0 is released now.. so I guess it would be ok to drop the gpu chipid hack

17:28 <alx___> someone seen this error before? pcie_3a_gdsc status stuck at 'off'

17:30 <steev> i've been seeing a *lot* of the wmi tlv parse failures yesterday and today

17:31 <steev> clover[m]: sorry :( i meant to push 6.10.6 yesterday and didn't

17:33 <clover[m]> No problem. I've been playing catch up. Just got back from a two week cruise in Greece

17:33 <steev> nice

17:34 <steev> there you go, 6.10.6

18:04 <FarchordSteveCossette[m]> Mmmm guess I can't download jhovold's kernel right now:... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/wEOlheHvmqdVbRJzeMolsIAK>)

18:04 <FarchordSteveCossette[m]> oh ill just download the zip I guess

18:43 <konradybcio> try git over ssh

18:43 <konradybcio> clone git@github.com:jhovold/linux.git

19:19 <steev> clover[m]: pushed 6.11-rc4 as well, based on johan's rc4, dropping the RELR change, since binutils 2.43 is out, and it only affected binutils > 2.42 and < 2.43, adding in the rgb sensor for the webcam, and using the power sequencer for the wifi, with the caveat that i *might* not enable the powerseq driver, and you might need to enable PCI_PWRCTL_PWRSEQ (not sure, i need to check)

19:20 <steev> enable/module (i have it as a module here)

19:20 <steev> sorry no, POWER_SEQUENCING_QCOM_WCN=m

19:52 <mlau> kuruczgy[m]: what source did you build this kernel from? the dtb is quite a bit larger than the one from my own builds

19:56 <kuruczgy[m]> Here is the derivation: https://github.com/kuruczgy/x1e-nixos-config/blob/175719dfde875c5dc7f14ae6cbe59ab72797f489/iso.nix#L144

19:56 <kuruczgy[m]> Even if you don't know nix, you should be able to make out the relevant parts, but ask if anything is unclear.

19:56 <kuruczgy[m]> NixOS does add a bunch of other random config options too over `johan_defconfig`, I can dump my `/proc/config.gz` if you want.

19:58 <kuruczgy[m]> Were you able to boot with my kernel? Did it resolve any of the issues you were having?

19:58 <mlau> Yes the nixos kernel boots, and even wlan seems stable.

19:58 <mlau> I'm at the moment trying to figure out where the differences are

19:59 <mlau> I took johan_defconfig, and made everything built-in, but that is really wonly

19:59 <mlau> *wonky

20:00 <mlau> i.e. pcie4 with wlan is unstable, and I noticed that the dtb in your iso is 20% larger

20:01 <kuruczgy[m]> But we are building from the same kernel commit? That sounds quite interesting... I don't think NixOS should do anything funny with the dtb

20:03 <mlau> oh, no, I use the 6.11-rc4 branch now,

20:05 <kuruczgy[m]> Here is my /proc/config.gz dumped if that helps with comparing potential differences

20:47 <mlau> kuruczgy[m]: this .config doesn't even boot when I build it

20:48 <mlau> i see nixos uses gcc-13.3, while I use 14.2

20:48 <mlau> i'll try that one next

21:05 <robclark> anyone tried asan on x1e thing yet? `LD_PRELOAD=/usr/lib64/libasan.so.8 ls` => SIGILL

21:14 <konradybcio> robclark any chance you can pin down the exact instr?

21:15 <robclark> it happens really early, before gdb can do anything useful

21:16 <robclark> from LD_DEBUG=all I guess it is in some constructor in libasan

21:17 <robclark> last bit of LD_DEBUG output:

21:17 <robclark> https://www.irccloud.com/pastebin/qwYMv4SG/

21:22 <konradybcio> does dmesg have anything interesting?

21:23 <robclark> nope

21:29 <konradybcio> and if you do something cheeky like debug exec with your program in arguments?

21:31 <robclark> I tried `gdb ls` and then `set environment LD_PRELOAD=...` and then `r` .. which I think should roughly amount to the same thing

21:38 <jannau> I can reproduce on fedora 40 / apple m2 pro. non LD_PRELOAD asan was working before

21:41 <robclark> does m2 have arm32 support? I'm kinda wondering if it is related to not implementing arm32 or maybe some other optional thing

21:41 <jannau> no 32-bit support in apple CPUs since before M1

21:42 <konradybcio> objdump -D $(which asan) | grep "r[0-9]"?

21:43 <robclark> hmm, doesn't seem to be any arm32 regs

21:44 <bamse> robclark: just do right instead...then you don't need sanitizers...

21:44 <HdkR> valgrind asan rather than llvm asan?

21:45 <robclark> I'm using llvm asan.. are there two libasan's?

21:46 <konradybcio> well oryon and hot/cold-codenamed cores are probably the only non-cortex higher-than-armv8.2 ones.. so there may be some assumptions in some point of the food chain

21:47 <HdkR> I guess valgrind doesn't call itself asan

21:47 <HdkR> if it captures under gdb that would be cool

21:48 <HdkR> Since I've used llvm asan a decent amount on these, haven't had a chance for Oryon

21:48 <jannau> fedora package version suggest libasan comes from gcc, should be the library though

21:48 <konradybcio> jannau: can m1n1 trap sigill and print out the details?

21:48 <konradybcio> well.. the architectural thing that invokes sigill anyway

21:50 <robclark> huh, libasan from gcc?

21:50 <jannau> not out of the box, same behavior as running on baremetal

21:51 <jannau> rpm -qf /usr/lib64/libasan.so.8

21:51 <jannau> libasan-14.2.1-1.fc40.aarch64

21:52 <HdkR> Couldn't systemd-coredump also get the SIGILL context in this state?

21:52 <jannau> yes, it does. just remembered this as well

21:53 <HdkR> p/x $_siginfo and disas $pc-64,+128

21:53 <HdkR> :D

21:54 <jannau> https://paste.centos.org/view/c51abf74

21:55 <HdkR> Smells like bad icache clearing or bad page permissions

21:57 <HdkR> si_code ILLOPC leans towards icache clearing

22:01 <HdkR> Oryon isn't very special there, it's 64B icache and dcache size. Surprising if they mess that up

22:02 <HdkR> Unless they hand-rolled something and forgot to dsb or something

22:04 <jannau> $pc and branch target address are in a RX section

22:05 <HdkR> woo icache clearing bugs

22:11 <jannau> no, it's bti. works with arm64.nobti in the kernel command line

22:12 <HdkR> oh, interesting

22:13 <HdkR> Oh right, that information is in ESR

22:15 <robclark> jannau: good call, arm64.nobti also "fixes" it for me

23:39 <robclark> jannau: https://bugzilla.redhat.com/show_bug.cgi?id=2306353 fyi