robclark changed the topic of #aarch64-laptops to: Linux support for AArch64 Laptops (Chrome OS Trogdor Devices - Asus NovaGo TP370QL - HP Envy x2 - Lenovo Mixx 630 - Lenovo Yoga C630 - Lenovo ThinkPad X13s - and various other snapdragon laptops) - https://oftc.irclog.whitequark.org/aarch64-laptops
enyalios has quit [Remote host closed the connection]
enyalios has joined #aarch64-laptops
minecrell has quit [Read error: Connection reset by peer]
minecrell has joined #aarch64-laptops
leezu has quit [Ping timeout: 480 seconds]
<steev>
debian testing/unstable and kali (for 3 days in kali)
<abby>
I'm on 6.8.2 on an X13s and I have alsa-ucm-conf 1.2.11, but alsa isn't finding any soundcards
<abby>
I noticed that the ucm conf for sc8280xp looks for the dmi product family LENOVO.*ThinkPad X13s.*, which does not match what the dmi sysfs path says for me (it's not got LENOVO), but even after removing LENOVO from the regex there's still no soundcards listed
<abby>
is there something else I should look at to troubleshoot further?
<abby>
ah i misread the ucm conf, but the question stands
<abby>
i see a bunch of messages about deferred probes for sound-related things, could that be related? https://p.qrm.cat/fy87yA.txt
<zdykstra>
but I also have no sound devices available
<abby>
and i see it with or without it
M0133oracle[m] has joined #aarch64-laptops
hexdump0815 has joined #aarch64-laptops
hexdump01 has quit [Ping timeout: 480 seconds]
<steev>
abby: you're missing a module
<steev>
or possibly the firmware? (the firmware is in linux-firmware git but not in debian packages if you're on debian)
<abby>
do you know which? :)
<abby>
i'm on void, and we take the firmware from linux-firmware git
<steev>
let me unpack mine
<steev>
you should have /lib/firmware/qcom/sc8280xp/SC8280XP-LENOVO-X13s-tplg.bin which is a symlink to /lib/firmware/qcom/sc8280xp/LENOVO/21BX/audioreach-tplg.bin
<abby>
i have that
<steev>
you also will need qcvss8280.mbn in /lib/firmware/qcom/sc8280xp/LENOVO/21BX/ which comes from either the windows partition, manually downloading the exe from lenovo's site and extracting it, or from clover[m]'s github that has it (i think) for the video codec
<steev>
can you show me grep 8280 /your/kernel/config
<steev>
actually... you appear to get further than i do with 6.8.2
<steev>
and 6.7.11 for that matter
<steev>
neither of which are booting for me, at least, they aren't connectable via ssh
<abby>
heh
rmsilva- has quit [Remote host closed the connection]
rmsilva has joined #aarch64-laptops
jglathe_volterra has joined #aarch64-laptops
iivanov has joined #aarch64-laptops
<steev>
hm
<steev>
actually, it boots if i add clk_ignore_unused and pd_ignore_unused, which i haven't been using, guess i gotta figure out which one makes it boot
<steev>
but, i do get audio here (but i'm based on a debian defconfig)
<abby>
i was able to boot the debian nightly image without issues
jglathe_volterra has quit [Remote host closed the connection]
jglathe_volterra has joined #aarch64-laptops
jglathe_volterra has quit [Remote host closed the connection]
jhovold has joined #aarch64-laptops
<steev>
its' clk_ignore_unused; if interconnect is built in, it seems like that has to be passed, but if it's a module, you don't
<abby>
interesting
<abby>
CONFIG_INTERCONNECT_QCOM=y -> m?
<steev>
that'll only work if you have the qnoc-sc8280xp (i think it is) in your initramfs, and according to clover, it breaks encrypted rootfs
jhovold has quit [Quit: WeeChat 4.2.1]
<abby>
do you have a link to the repo for the qcvss8280.mbn btw?
<steev>
but the exe files on lenovo's site can be extracted with innoxtract or whatever it is, if you wanna make sure you have the latest (no idea if that one is old, just saying)
jhovold has joined #aarch64-laptops
<steev>
right, now i remmeber what i dislike about 6.8.2, it doesn't come back from suspend for me
jglathe_x13s has quit [Remote host closed the connection]
<abby>
that works for me, but it doesn't go to a power state where the led breaths
<abby>
breathes
jglathe_x13s has joined #aarch64-laptops
martiert_work has quit [Quit: WeeChat 4.2.1]
jglathe_x13s has quit [Remote host closed the connection]
jglathe_x13s has joined #aarch64-laptops
neg2led has quit []
jglathe_x13s has quit [Ping timeout: 480 seconds]
aram__ has joined #aarch64-laptops
aram_ has quit [Ping timeout: 480 seconds]
jglathe_x13s has joined #aarch64-laptops
todi1 has quit [Ping timeout: 480 seconds]
todi has joined #aarch64-laptops
zdykstra has quit [Ping timeout: 480 seconds]
todi has quit [Ping timeout: 480 seconds]
iivanov has quit [Remote host closed the connection]
iivanov has joined #aarch64-laptops
todi has joined #aarch64-laptops
todi has quit [Ping timeout: 480 seconds]
todi has joined #aarch64-laptops
<adamcstephens>
I’ve yet to test a Linux kernel which enters that deep of a sleep
<adamcstephens>
clearly there are things that still need to be powered down, such as the keyboard backlight on the x13s which stays on during suspend
zdykstra has joined #aarch64-laptops
systwi has quit []
<bamse>
jhovold: have you hit an issue that userspace freezes if you suspend an application with v6.9?
<bamse>
jhovold: i often ^Z my vim instance, to muck in the shell, and quite a few times now the x13s has frozen when doing so...hoping to capture some oops or something i did ssh thinkpad sudo cat /proc/kmsg from another machine, and that happily keeps running after the freeze
<bamse>
jhovold: i figured that perhaps if i ssh in and then cat /proc/kmsg i can ^C or ^Z that and get a shell to poke around, but as soon as i do that the ssh session frezzes as well
<bamse>
jhovold: if i the power-button, the freeze is over and the machine shuts down cleanly
<lollaritits[m]>
<adamcstephens> "I’ve yet to test a Linux..." <- cant wait for sleep mode
<adamcstephens>
i've wondered if sleep is actually saving that much power over just an idle system. :) surely it is, but it is still draining quite a bit
<jhovold>
bamse: haven't noticed anything like that here and can't reproduce it either
<adamcstephens>
i haven't noticed any freezes like that on 6.9-rc1 either
<jhovold>
adamcstephens: the biggest gain is from turning off the display
<adamcstephens>
👍
<bamse>
jhovold, adamcstephens: damn, was hoping i wasn't alone...now i have to debug it ;P
<jhovold>
abby, adamcstephens: we're still not hitting the lowest power states during suspend, until then you won't see any pulsing leds
neggles has joined #aarch64-laptops
<adamcstephens>
yeah i figured as much
<travmurav[m]>
bamse: I wonder if you can attach a debugger to the "frozen" process and see where it got stuck
<bamse>
travmurav[m]: i am not able to execute anything in userspace, either over ssh or locally
<bamse>
jhovold: i have tried to reproduce it outside wayland without success...
<travmurav[m]>
oh so like if you start some ssh session or something in tmux on a separate window, it dies too?
<bamse>
travmurav[m]: right if i ssh in from another machine, that session is frozen as well (except if that session runs e.g. cat /proc/kmsg)
<travmurav[m]>
(i was thinking ssh works-ish before you ever press ^z so open vim -> attach to it with gdb -> press ^z in vim -> see if gdb is alive)
<travmurav[m]>
this issue sounds very "fun"
<bamse>
travmurav[m]: worth a try
<bamse>
i was heading for a debug session with kdb over uart...if i can just figure out how to reproduce the problem on a machine with uart
<travmurav[m]>
bamse: hm just to confirm, if you run vim in ssh session and hit ^z it dies too? or its only on the desktop?
<travmurav[m]>
(I was trying to reproduce it too right now so checking if I'm doing wrong things)
<bamse>
travmurav[m]: haven't tried that
<bamse>
it's not that easy to reproduce...
<bamse>
but it happened 5-6 times over the weekend
<travmurav[m]>
ah so its not reliable? that sucks...
<bamse>
right
<travmurav[m]>
bamse: I think I just reproduced it
<travmurav[m]>
at least my device froze once I guess
<travmurav[m]>
it froze when I was trying to write this thing:
<travmurav[m]>
when ran out of a second pane of the tmux session, it would just fg^z repeatedly, but now after i rebooted the thing and sent it to churn it doesn't want to crash again
<travmurav[m]>
..it would churn in the first pane...
<travmurav[m]>
cool, crashed again but cant attribute it to the ^ script because I tried to run it again on the desktop session by hand -_-
<travmurav[m]>
cool, can run busybox sh (but not "real" sh) over ssh so the system is only half dead, but it's in total pain
<travmurav[m]>
and killing all instances of ash un-hangs it
Caterpillar has joined #aarch64-laptops
<jhovold>
Here's an updated wip branch for the X13s:
<jhovold>
- fix hypervisor resets on efivar access
<jhovold>
- usb dwc3 multiport support v18
<travmurav[m]>
bamse: so far I have an impression that anything that uses pty dies but if you ssh in "dumb" mode, shell works
<bamse>
travmurav[m]: interesting
<travmurav[m]>
but I think Ive hit it twice after starting ^^ loop over ssh and then doing ^Z once in a desktop terminal window
<travmurav[m]>
not sure if lucky or it helps somehow
<travmurav[m]>
bamse: I think I found a reliable reproducer: ^Z is hit when another thing was already ^Z-d
<travmurav[m]>
and killing all nvims that were hidden restores things back
<travmurav[m]>
* killing one of the two restores i guess
<bamse>
travmurav[m]: you're saying start one nvim ^z start another nvim ^z and it hangs?
<travmurav[m]>
yes
<bamse>
sorry, got curious and had to reboot...
<bamse>
100% reproducible both in wayland and console
<bamse>
thanks
<travmurav[m]>
at least this seems to be very reliable for me but exact setup: open tmux, create two panes, start nvim in pane 1, hit ^Z (it hides correctly), switch to pane 2, start tmux, hit ^Z (system hangs), ssh <host> busybox sh -> ps aux | grep nvim -> kill -9 <first pid> -> system unhangs, one nvim was killed, another nvim is still hidden and works
<travmurav[m]>
^^ was over shh
<travmurav[m]>
notably the screen also hangs fully
<bamse>
open a terminal, start nvim, ^z, start nvim, ^z boom
<bamse>
ahh, the case where i saw the kernel was still alive (other than it reacting to the power key nicely) is that when i do ssh thinkpad sudo cat /proc/kmsg i don't allocat a pty...
<bamse>
travmurav[m]: which kernel version are you on?
<travmurav[m]>
bamse: this was 6.9-rc2 that I've just built earlier today
<travmurav[m]>
(and the soc is msm8916 but I imagine that might be something very broad and not platform specific)
<bamse>
ahh, missed that part (8916) very good
<bamse>
yes, this is for sure some generic bug in v6.9 then
<jhovold>
can't reproduce the double suspend issue using regular vim (X and wayland)
<jhovold>
bamse: are you saying it's 100% reproducable by simply suspend neovim twice?
<bamse>
jhovold: yes
<jhovold>
nice, then it shouldn't be too hard to track down
<jhovold>
bamse: what shell do you use?
<travmurav[m]>
oh interesting, can't reproduce with normal vim too
<jhovold>
did you guys update neovim recently?
<bamse>
jhovold: bash it seems
<travmurav[m]>
NVIM v0.9.5 here, I used ash
<bamse>
travmurav[m]: hmm, i got 5 suspended vim sessions in my terminal now...no problem...
<travmurav[m]>
yes, I couldn't reproduce with normal vim, but nvim reliably hangs for me still regardless of the shell under it
<bamse>
would be nice if we could find something more lightweight than neovim to reliably reproduce it
<travmurav[m]>
ncdu hits it
<travmurav[m]>
or no
<travmurav[m]>
false alarm, my device just io hung for a second, sorry xD
<bamse>
"for a second" <3
<travmurav[m]>
but seems like most curses-ish applications don't hit the issue
<bamse>
i thought it might relate to the fact that nvim has child processes, while vim doesn't
jglathe_x13s has quit [Remote host closed the connection]
<travmurav[m]>
stopping running "parallel" with a bunch of sleep childs didn't hang the thing at least
<jhovold>
have you tried the reproducer on 6.8? e.g. in case it's a user space regression
<bamse>
jhovold: this is muscle memory for me...v6.8 is fine :)
<travmurav[m]>
though I think with parallel the childs are stoped too but nvim child is not
jglathe_x13s has joined #aarch64-laptops
<bamse>
jhovold: but i will certainly double check...just in the middle of some other stuff right now
<travmurav[m]>
I tried to run it on the different device running 6.8 and it didn't reproduce
<travmurav[m]>
but in any case killing /all/ ptys sounds like a big bug
<jhovold>
sounds like it's time for a bisection
<jhovold>
bamse: and you are on rc1 so it would be an issue in v6.8..v6.9-rc1 ?
<bamse>
jhovold: i never did v6.8...so i have to say v6.8-rc7..v6.9-rc1
<bamse>
jhovold: yes bisect time...althought it would be nice to have a smaller reproducer...i don't have nvim in my ramdisk
<jhovold>
abby: regarding your audio issue, sounds like the fw hasn't started, do you have pd-mapper running?
<jhovold>
abby: and sounds odd that the iommu would be involved in the hid-i2c issue, but promising that you got it to work
<jhovold>
vadikas[m]: are you saying that you have a perfect reproducer for the (pontential) ath11k ring-buffer issue?
<jhovold>
that may come in very handy if so
<jhovold>
vadikas[m]: which kernel are you on, and can you post a log somewhere from when you hit the issue?
<bamse>
jhovold: fwiw...regarding ath11k, since switching to v6.9-rc1 a week ago...my ath11k has hit the ring-buffer issue (system ok, log full of errors about indices being off) 4-5 times
<jhovold>
if it's a race, I guess random changes in timing could make it easier to hit
<jhovold>
oh, and then we have the unconfirmed hypothesis that ITS may be involved of course
<bamse>
well..that could very well affect the timing
<jhovold>
as that would increase parallellism
<jhovold>
but I've still only seen it twice, and with 6.6
jglathe_x13s has quit [Remote host closed the connection]
jglathe_x13s has joined #aarch64-laptops
<vadikas[m]>
<jhovold> "vadikas: which kernel are you on..." <- I'm on 6.7.10, it happens when I roam from one part of my house to another, so wifi adapter reconnects from one AP to another.
<jhovold>
vadikas[m]: and it triggers every time?
<vadikas[m]>
not every time, but often
jglathe_x13s has quit [Remote host closed the connection]
jglathe_x13s has joined #aarch64-laptops
<bamse>
jhovold: did you start any bisection?
<jhovold>
bamse: no, I assumed you would do it, I haven't even reproduced the issue
<bamse>
jhovold: i've started now, just wanted to avoid spending a the time unnecessarily
<bamse>
jhovold: and you should switch to neovim, it gives you much better syntax highlighting (and some other features ;))!
<jhovold>
vadikas[m]: if the error messages seems to match those in my bugzilla report perhaps you can add a comment there about how and when you trigger the issue:
<jhovold>
bamse: heh, I think I'm fine with vim for now
<bamse>
jhovold: it's just one bug ;)
<jglathe_x13s>
Hmm 6.8.2 doesn't boot on X13s, simply reboots very soon - with defconfig, laptop_defconfig.
<jglathe_x13s>
On Volterra it works, though
jglathe_volterra has joined #aarch64-laptops
<steev>
jglathe_x13s: it boots here if i enable clk_ignore_unused ; but it doesn't come back from suspend
<steev>
6.7.11 doesn't boot at all for me though
<jglathe_volterra>
I have clk_ignore_unused and pd_ignore_unused in cmdline
<steev>
i need to look at what was added in both 6.8.2 and 6.7.1
<steev>
11
<jglathe_volterra>
argh my bad as it seems
<steev>
didn't have clk_ignore_unused?
<jglathe_volterra>
for whatever reason I'm always too dumb to set a correct link for the dtb
<jglathe_volterra>
so no dtb
<steev>
oh
<jglathe_volterra>
no boot then, would be very surprising if it did
<jglathe_volterra>
that f*ckery with the images takes its toll, the link was right but the file was not there, I copied to /mnt/boot/dtbs/6.8.2+/
jglathe_x13s has quit [Remote host closed the connection]
jglathe_x13s has joined #aarch64-laptops
<jglathe_volterra>
okay its up now on 6.8.2, with unmodified laptop_defconfig - and it has sound
<abby>
jhovold: yes pd-mapper is running
jglathe_sdbox2 has joined #aarch64-laptops
<vadikas[m]>
<jhovold> "vadikas: if the error messages..." <- the messages are the same, but today it is stable, so can't blame ) yesterday it failed like 10 times minimum. will add to the bugreport
<clover[m]>
Steev you pushed 6.7.11?
<steev>
i don't think i did
<steev>
since it wasn't working for me, i didn't wanna push it out, but i can in a separate branch if you want to take a looksie
iivanov has quit [Quit: Leaving...]
jhovold has quit [Ping timeout: 480 seconds]
ema has quit [Quit: leaving]
ema has joined #aarch64-laptops
jglathe_volterra has quit [Remote host closed the connection]
<abby>
steev: the firmware from the alarm github didn't seem to do anything for me