01:00 <anthony25> bryanodonoghue: same thing, I tested and the camera is not listed

01:53 <bibikski> bamse: Apologies for the delay, I took some time to clear my head of the issue. So I installed the packages you told me and was able to finally generate the image. I burnt it to a usb and was able to kinda boot. I got an error on boot stating "../systemd/src/boot/boot.c:2560@image_start: Error loading \archarm\6.14.0-rc6-g426b4193b77\vm-linuz: Unsupported". But this was with the kernel that I compiled without using the

01:53 <bibikski> config zefi command. I still can't compile the kernel with those additional configurations.

02:16 <zdykstra> I haven't followed too closely, how is support for the OLED display in the T14s?

02:27 <steev> abel submitted a patchset to make it its own separate dts

02:28 <steev> i'm not a huge fan, but i don't think there is a good way to detect it, and someone did attempt to read edid from uefi, but it said it was unimplemented or something

03:39 <zdykstra> Hmm, so unique dts aside, brightness controls / backlight are good to go? I'm pondering picking one up, so I'm curious how usable as a daily driver it is.

05:12 <steev> that i don't know, our release still hasn't gone out, but my understanding is that the t14s is still a bit... rough

05:13 <steev> i have one here (with oled) and in windows (and wsl) at least, the screen is definitely gorgeous

07:09 <jhovold> steev: still no ath11k corruption?

07:25 <SpieringsAE> bamse: thanks for merging the usb-a and sd-card reader support for the asus vivobook, think I'm going to do a rebase for the bluetooth patch and add that todo comment this week

07:25 <SpieringsAE> hopefully that can get merged as well then

07:26 <albsen[m]> steev: I've the same laptop, the screen is amazing. I tried but simply cant use windows anymore... hopefully soon the support for the 64gb version gets better. currently its crashing almost every hour.

07:26 <SpieringsAE> then next step is add the ps8830s

07:38 <smoorgborg[m]> <albsen[m]> "steev: I've the same laptop..." <- Disable 32GB RAM, then it doesn't crash.

07:40 <albsen[m]> smoorgborg: disabling the 32gb allows to boot, correct. unfortunately, thats not the only hurdle. at the moment, on ubuntu with the most recent kernel 5g wifi disconnect will crash, if only using 2.5ghz there are still some other full system freeze scenarios I wasn't able to pinpoint.

07:41 <albsen[m]> i think the wifi one is soon fixed, saw some chatter here about that.

07:41 <smoorgborg[m]> OK, for me the kernel had crashes when copying from/to USB3 flash keys with 64G enabled, that is gone with 32G only enabled

07:41 <albsen[m]> smoorgborg: yes, that as well was my observation

07:42 <albsen[m]> but I get many more random crashes unfortunately

07:42 <albsen[m]> and wasn't able to pinpoint them.

07:42 <albsen[m]> there is another crash related to video decoding someone mentioned

07:50 <smoorgborg[m]> After switching to 32G I've hadn't had any crashes, other than the machine doing reboots when loading the CPU 100% for more than a few minutes.

07:51 <smoorgborg[m]> But it's not my daily machine, so it's only used lightly

07:51 <albsen[m]> was just about to ask that

07:51 <albsen[m]> yes, if I browse a bit and so on its fine

07:52 <albsen[m]> I tend to push the CPU/RAM with my work, alot.

07:52 <albsen[m]> running containers as well

07:53 <albsen[m]> when using it as my daily it keeps crashing after about an hour or so

07:54 <smoorgborg[m]> I managed to snag a X1 Carbon G9 a few weeks ago, and sure the OLED screen on the T14s is incomparable to the IPS on the C9, but otherwise they so similar - so I've switched to the Intel machine as a daily driver. Really a pity, I'd love to use the T14s but it just needs that tiny bit of maturity.

07:54 <albsen[m]> agreed

07:55 <smoorgborg[m]> It's really cool to see how fast stuff is moving though, considering the complexity of things and that everything more or less has to be reverse engineered by volunteers.

08:08 <albsen[m]> totally agree, thats why I'm hoping my random crash reports help somehow debug.

10:10 <JensGlathe[m]> For the friends of pre-built ubuntu-ish kernel packages, 6.14-rc7-0 is up: https://drive.google.com/drive/folders/1Lps5o3FXroAJFDiKj18vutJbC1uld49s

10:10 <JensGlathe[m]> https://github.com/jglathe/linux_ms_dev_kit/tree/jg/ubuntu-qcom-x1e-6.14-rc7

10:10 <JensGlathe[m]> basically rebased mine and jhovold's tree to v6.14-rc7

12:40 <steev> jhovold: 2 days 2:28 minutes uptime, no corruption

12:42 <jhovold> thanks!

12:48 <anthony25> robclark: I reverted the ACD patch, and no freeze anymore

12:49 <anthony25> I tried to remove the higher frequencies but it didn't help

13:32 <robclark> anthony25: any chance you could reply to the patch on list? I've not seen any issues, but it could be there is some variance from chip to chip

13:32 <anthony25> sure! I'll do that later today

13:33 <robclark> thx

14:04 <jhovold> Here's an updated wip branch for the X13s:

14:04 <jhovold> - https://github.com/jhovold/linux/tree/wip/sc8280xp-6.14-rc7

14:04 <jhovold> Changes include:

14:04 <jhovold> - fix ath11k ring-buffer corruption (differently)

14:04 <jhovold> - update pipewire fixes to v5

14:04 <jhovold> Note:

14:04 <jhovold> - please report any ath11k "unexpected rx length" warnings

14:04 <jhovold> Here's an updated wip branch for the T14s and X Elite:

14:04 <jhovold> - https://github.com/jhovold/linux/tree/wip/x1e80100-6.14-rc7

14:04 <jhovold> Changes include:

14:04 <jhovold> - fix lpg pwm calculations

14:04 <jhovold> - fix ath12k ring-buffer corruption

14:04 <jhovold> - add t14s backlight support

14:04 <jhovold> - add t14s-oled devicetree

14:04 <jhovold> - update pipewire fixes to v5

14:43 <tobhe_> thx! I think I might cherry pick those wifi fixes and see if that fixes the complaints I've seen

16:10 <JensGlathe[m]> My branch, rebased onto jhovold 's branch is up on github and packages on google drive now

16:56 <JensGlathe[m]> brightness settings with pwm-backlight end at 100%now, nice

17:45 <albsen[m]> I tried the version 17 Jens Glathe so far I've been able to boot, but it's still crashing when I connect to 5ghz wifi. haven't tested anything else yet. on the t14s

17:46 <JensGlathe[m]> @albsen 6.14-rc7-1?

17:47 <albsen[m]> sorry, yes not 17 rc7-1

17:55 <JensGlathe[m]> Well I must say I haven’t seen any ath12k fix in the part above v6.14-rc7

18:05 <bibikski> bamse: So i downloaded jhovold's new kernel and packaged it up. Still got the same vzlinux error. After some googling, I tried building and copying the Image file of the kernel and was able to get it to boot. This was the error I received though, EFI stub: Booting Linux Kernel...

18:05 <bibikski> (\n)EFI stub: Loaded initrd from LINUX_EFI_INITRD_MEDIA_GUID device path

18:05 <bibikski> (\n)EFI stub: Measured initrd data into PCR 9

18:05 <bibikski> (\n)EFI stub: Generating empty DTB

18:05 <bibikski> (\n)EFI stub: Exiting boot services...

18:06 <bamse> bibikski: did you remember the --devicetree argument to mkosi?

18:07 <bamse> bibikski: the "Generating empty DTB" indicates that nothing provided a valid .dtb file

18:09 <JensGlathe[m]> oh correction:... (full message at <https://matrix.org/oftc/media/v1/media/download/AR7gmsNlREl82McsIwvQONNNeSBcrgx5kIFuqigj9UvejZou68jchXbwXrGdcOvHrE_PP3xJSTPhCTvuDWRli_VCeV7WSZnwAG1hdHJpeC5vcmcvU21NS3NHdGJiaE5Ld0JLdHZwaHZhd05u>)

18:09 <JensGlathe[m]> it is there

18:09 <bibikski> bamse: I began to exclude that due to the fact when I was building the os with mkosi, I was receiving an error about duplicate dtb file specified. I had assumed that this was due to the building the kernel with jhovold's defconfig.

18:09 <bibikski> bamse: I failed to attempt to burn the usb with the devicetree param, could that be a likely cause?

19:10 <bamse> bibikski: the kernel package will contain all the dtbs for all the boards, the --devicetree argument to mkosi will cause systemd-boot in the generated image to load one specific .dtb into ram before jumping to linux

19:34 <bibikski> bamse: This is the output I receive when I try to specify the device tree (https://pastebin.com/vyq1Sn1w)

19:43 <kuruczgy[m]> HdkR: icecream95: According to htop and `/sys/devices/system/cpu/cpufreq/policy*/cpuinfo_cur_freq` it's 3.417 GHz, according to `perf stat -I 2000` it's more like 2.6 GHz

19:43 <kuruczgy[m]> So it seems the FW is definitely lying

19:50 <kuruczgy[m]> Thermal equilibrium seems to be 2.4 GHz. I can win 200 MHz by picking it up off the desk :)

20:01 <hexdump0815> kuruczgy: maybe putting it on top of a few ice cubes can push it even a bit higher ... at least for a short time :)

20:15 <kuruczgy[m]> I would be interested in somehow plotting the (perf/power) as a function of frequency curve though. I have heard that it is supposedly more power efficient at lower clock rates. That might also be helpful for setting up Energy Aware Scheduling properly. (Not sure how EAS works, whether the curve parameters need to be set explicitly, or if it just figures them out for itself.)

20:16 <HdkR> kuruczgy[m]: Huh. No idea what perf stat would be doing differently

20:18 <kuruczgy[m]> AFAIK it uses the cpu perf counters instead of some fw interface. (it literally counts the instructions and divides it by the elapsed time)

20:19 <bibikski> bamse: so I tried referencing the dts with both a local copy and the presumed output of installing the linux-upstream. No dice

20:19 <kuruczgy[m]> *cycles, not instructions

20:20 <HdkR> kuruczgy[m]: How does that account for stalls? :thonk:

20:21 <HdkR> X1E slurps icache through a straw, it's really easy to stall the frontend

20:23 <HdkR> Only 8-bytes per cycle if it needs to fetch from L2

20:23 <kuruczgy[m]> It has metrics like cycles, stalled-cycles-frontend, stalled-cycles-backend, branches, branch-misses, etc.

20:23 <kuruczgy[m]> So I am pretty sure it accounts for them

20:29 <HdkR> hmmm. Need to put my X1E on a hotplate to confirm :D

20:39 <kuruczgy> just remember to update firmware before, with previous fw it probably would overheat

20:40 <HdkR> I've never updated the firmware on the device

20:41 <HdkR> Yoga 7x stock firmwares. T14s gathering dust on the shelf

20:54 <icecream95> kuruczgy[m]: The command you used with perf will include time that the CPU is idle, so note that if not all cores are at 100% usage then the frequency shown will be lower

20:55 <icecream95> That's why I suggested measuring a specific command, then it only counts time when it's running

20:58 <icecream95> Energy Aware Scheduling is apparently only for big.LITTLE (see Documentation/scheduler/sched-energy.rst ), but better Energy Aware Cpufreq might be useful

20:59 <kuruczgy[m]> icecream95: It was at 100% the whole time so I guess in this instance it was fine.

20:59 <kuruczgy[m]> But so let me understand: perf stat measures the cpu clock cycles (including stall and idle which will be some sort of wfe instruction) over some time T, and gives the average frequency as f=cycles/T? So why does cpu usage matter?

21:06 <JensGlathe[m]> Sound has become useable again with X13s and 6.14-rc7-1 (pipewire)

21:07 <icecream95> I guess that during PSCI CPU suspend the core clock stops, so it isn't counted then?

21:07 <steev> JensGlathe[m]: that is my experience as well :) hopefully we can get more louder soon too

21:11 <icecream95> The firmware already exposes perf/power values, see /sys/kernel/debug/energy_model , though not all workloads will behave the same. Interestingly it differs between clusters, for me cluster 0 is the most efficient

21:31 <bamse> bibikski: dtb not dts

21:33 <bamse> bibikski: not sure why mkosi-qcom/qcom/x1e...dtb would be the same file as mkosi-qcom/qcom/x1e...dtb... those are supposed to live in different namespaces

21:34 <bamse> bibikski: that said, you don't need to put the dtb in the mkosi-qcom, if you "make pacman-pkg" and put the package in mkosi.packages mkosi will isntall the kernel and then go find the dtb there