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
<steev> interesting, now that i'm closer to the modem again, i get the msdu_done bit in attention is not set
Guest2481 has quit []
matthias_bgg has quit [Ping timeout: 480 seconds]
matthias_bgg has joined #aarch64-laptops
alpernebbi has quit [Ping timeout: 480 seconds]
alpernebbi has joined #aarch64-laptops
<bamse> jenneron[m]: sorry about that, we talked about the i2c-hid...other than that i think it looked good
<bamse> jenneron[m]: i'm out this week, will take a look as soon as i'm back
<steev> bamse: when you're back as well... do you remember the config option that makes all the device link failure messages go away?
echanude has quit [Ping timeout: 480 seconds]
<bamse> steev: i presume you're referring to fw_devlink=stuff...but you shouldn't touch that
<steev> okay
<bamse> steev: the last errors in the log went away recently, but iiuc the fix introduced regressions, so the errors where brought back
<steev> ah, okay, that's what happened, i swore i saw them go away
hexdump0815 has joined #aarch64-laptops
hexdump01 has quit [Ping timeout: 480 seconds]
iivanov_ has joined #aarch64-laptops
iivanov_ has quit [Remote host closed the connection]
iivanov has quit [Read error: Connection reset by peer]
iivanov has joined #aarch64-laptops
<jhovold> pstef: sounds like your distro has a broken systemd service that tries to enable the touchscreen
<steev> which, shouldn't be needed anymore anyway
<jhovold> you no longer need anything like that if you run one of my wip branches (even if you did have a touchscreen), so you can just disable it
<jhovold> _[m]123: yes, disable both those options and see if you still hit any resets at boot
<jhovold> please describe more in details when you hit the resets next time too, and please confirm that we are talking about resets
<jhovold> _[m]123: not sure what's up with those dpu_rm_reserve() errors, but it doesn't look good, perhaps robclark knows what it means
<pstef> jhovold: thanks for the hint, I'll try to learn how to disable it. The distro is Fedora (Rawhide)
<steev> pstef: it's probably a udev rule actually
<steev> or potentially not
<pstef> it is indeed, thanks!
martiert has quit [Quit: WeeChat 4.2.1]
martiert has joined #aarch64-laptops
jglathe_ has joined #aarch64-laptops
jglathe_x13s has quit [Ping timeout: 480 seconds]
<pstef> the rule file originates from jlinton's copr
<_[m]123> <jhovold> "\: yes, disable both those..." <- it's not at boot though, and I am sometimes afk from the laptop when it happens, e.g. when I cvheck it in the morning it's at FDE pw prompt
<_[m]123> nothing in the logs either, I checked last time when I wás on my laptop
<_[m]123> the exact timestamp
<_[m]123> it just freezes up and resets
<_[m]123> which is (esp for its frequency) new behavior
<jhovold> _[m]123: ok, thanks for the details, it doesn't like it's related to the efivar issue then (but now that you've disabled you can still see if it makes any difference until you rebuild the kernel next time or so)
<jhovold> is the machine suspended over night? or left on?
<jhovold> has it happened during use? any hints about what you were doing at the time if so?
<jhovold> _[m]123: and you didn't see this before 6.8-rc1?
<_[m]123> so far no reset 🤷
<_[m]123> <jhovold> "is the machine suspended over..." <- it's confusing, seemingly the samsung screen remains on even if off - so I think it is preventing sleep, sometimes I leave it downloading
<_[m]123> it's happened multiple times during use too, yes
<_[m]123> just browsing, streaming twitch on external, once was compiling kernel
<_[m]123> <jhovold> "\: and you didn't see this..." <- only happening since latest rc7 I believe?
<_[m]123> maybe I might have had it once before
<jhovold> _[m]123: systemd prevents my x13s from suspending if a have an external display connected by default (there's some setting somewhere)
<jhovold> can you confirm that it is still on when you close the lid by connecting over ssh (or ping it) perhaps?
<jhovold> you can also tell from dmesg when opening the lid again
<jhovold> that's not good at all if this is something that started with rc7, even if I guess it could be unrelated changes that started triggering an existing bug
<jhovold> sounds like what konradybcio also reported since around that time, not sure if he also saw it before rc7?
<konradybcio> not sure, i only started extensively using this release when rc7 was already out
<jhovold> yes, that's right
<jhovold> _[m]123: do you know which kernel you used before rc7? my rc6?
<vadikas[m]> <clover[m]> "Got it, ty for the update..." <- updated, nothing broke :-)
<vadikas[m]> sleep battery drain ~2.5%/hour
<_[m]123> <jhovold> "\: do you know which kernel..." <- I think briefly but with the dpe recession I went back to 6.7
<_[m]123> regression
<javierm> bamse: hello, did you have time to think on how to properly handle https://github.com/andersson/rmtfs/pull/19 ?
<javierm> I would really like to have WiFi working out-of-the-box in the HP X2 Chromebook with Fedora, but don't want to ship in the package a systemd unit file if upstream would solve it differently
<jenneron[m]> javierm: oh cool, would be also nice to have a systemd service in msm-cros-efs-loader repo
<jenneron[m]> i'm wondering, in postmarketOS we have a single openrc service and have a confd file shipping with it https://gitlab.com/postmarketOS/pmaports/-/blob/master/modem/msm-cros-efs-loader/rmtfs.confd?ref_type=heads. This way we have only one service and a simple config file altering parameters used in the service
<jenneron[m]> is it possible to do something similar with systemd?
<jenneron[m]> as you can see in the link msm-cros-efs-loader replaces the rmtfs confd file with required parameters
<javierm> I don't see where but maybe I'm just blind
<jenneron[m]> javierm: there is no systemd service, i'm just saying it would be nice to have it
<jenneron[m]> in the repo
<javierm> jenneron[m]: yeah, I got that part and agreed. What I asked is what component parses your config https://gitlab.com/postmarketOS/pmaports/-/blob/master/modem/msm-cros-efs-loader/rmtfs.confd
<jenneron[m]> javierm: this config is parsed by rmtfs openrc service
<jenneron[m]> altering command_args variable
<javierm> jenneron[m]: oh, I see. Then probably we could add that to the upstream rmtfs repo too and have a common config for both openrc init and systemd unit files
<jenneron[m]> javierm: well `*.confd` is something like openrc standard, i'm not sure systemd has anything like this
<jenneron[m]> or does it?
<javierm> jenneron[m]: I don't think it does but the rmtfs systemd unit file could have a ExecStartPre or something to parse it I think
<javierm> jenneron[m]: or have rmtfs itself to parse the config and then you wouldn't have to duplicate that logic
<javierm> then rmtfs could just been started without any options and do the correct thing depending on the rmtfs.conf
<jenneron[m]> javierm: yeah adding something like /etc/rmtfs/config file would work too
<jenneron[m]> indeed
PterKoczka[m] has quit [Quit: Client limit exceeded: 20000]
<javierm> jenneron[m]: I'll take a look to this, but probably next week
<javierm> jenneron[m]: will also propose a systemd unit file for msm-cros-efs-loader. That script is idempotent right? That is, is a no-op if is for example started as a dep for rmtfs
<javierm> only the first time the EFS files will be extracted and the next time it's safe to run it even if not needed AFAIU
<jenneron[m]> javierm: yes. first time it extracts files, next time just exists
<jenneron[m]> so yeah it is intended to be a dependency of rmtfs making sure those files are in place
<javierm> jenneron[m]: cool, thanks
<jenneron[m]> the only thing that probably doesn't work is when you have 2 different 7c chromebooks and use the same system with the same USB storage. we should validate files and replace if necessary
<jenneron[m]> but i don't have 2 devices to test this
<javierm> jenneron[m]: hmm, I see. Probably not a very common use case though
<javierm> usually people will use a SD card (or eMMC) to store their OS ?
<jenneron[m]> javierm: well the same problem for SD being used on 2 different devices
<javierm> I don't think people will use the same storage for different machines, but who knows :)
<travmurav[m]> javierm: hm, speaking of fun msm- scripts we have in pmOS, we have another one: msm-firmware-loader which isn't as useful on WoA but is really handy for android phones/tablets. We recently added simple .service files to it as part of the pmos+systemd work but I was wondering what's the best way to handle setting path to the executable for those? right now we just hardcode it to be simple and have no build system there...
<javierm> jenneron[m]: yes, I meant a SD card that is just left in the Chromebook and not taken out and put it in another Chromebook
<jenneron[m]> javierm: indeed it is a rare use-case, but if anyone tries this it will be unpleasant
<javierm> jenneron[m]: yeah, they can remove the /var/lib/rmtfs files though and then it would work the next time
<jenneron[m]> yep
<travmurav[m]> jenneron: I wonder if you can check some serial in the script and annotate the blob
<travmurav[m]> i.e. emmc/ufs serial or maybe there is something soc-unique
<travmurav[m]> would be generally nice to have given long-term we want to copy efs to the storage on all devices and it's an open question
<jenneron[m]> javierm: travmurav: i've opened an issue for this https://gitlab.com/postmarketOS/msm-cros-efs-loader/-/issues/1
<jenneron[m]> <travmurav[m]> "javierm: hm, speaking of fun msm..." <- > msm-firmware-loader which isn't as useful on WoA
<jenneron[m]> i think it would be quite useful because people have problems upstreaming firmware
<jenneron[m]> i probably even have some MR to msm-firmware-loader
<travmurav[m]> jenneron: ah yes I do remember you had a device which actually had firmware on the ufs partition from the factory?
<travmurav[m]> as in, not just in windows
<jenneron[m]> yes
<jenneron[m]> but even if device doesn't have one
<jenneron[m]> i was able to extract some files from UEFI capsule on galaxy book s
<jenneron[m]> so dumping UEFI capsule and extracting firmware from there might also be an option
<jenneron[m]> the main problem is: how to use msm-firmware-loader in initramfs
<jenneron[m]> do we run it once in initramfs and then bind mount to rootfs, or do we run it in initramfs, and then in rootfs again
<jenneron[m]> i'm not sure what is the correct way
<robclark> jhovold, _[m]123, failing to get dspp means userspace is trying to use CTM on more CRTCs than the hw has DSPP blocks, ie. userspace should handle the atomic test failure and try again without CTM.. is that sc7180 (which has two CRTCs but one DSPP)?
<travmurav[m]> jenneron: I think it might be simpler to kill the mountpoint when switchign root and run the service normally: then you only do it twice on devices that really need it (i.e. for usb) and the thing doesn't need to care about transfering the same mountpoint. linux doesn't continuously read those files anyway
<travmurav[m]> so, well, IMO the right way is the one that is simpler to implement and understand :D
<jenneron[m]> i see
<jenneron[m]> we will probably have an -initramfs subpackage for msm-firmware-loader which includes all the files and hooks to initramfs
<javierm> travmurav[m], jenneron[m]: do you really need the msm-firmware-loader to be run in the initramfs ?
<travmurav[m]> javierm: iirc it's the fun "no usb if no adsp" thing so you can't boot rootfs from usb after efi loads initramfs
<javierm> travmurav[m]: I see...
<travmurav[m]> we absolutely don't need it for all the devices, just for the "fun" ones
<jenneron[m]> this is how it is implemented currently
<travmurav[m]> and actually iirc x13s is the same thing?
<javierm> sigh
<javierm> all this stuff is so complex
<javierm> I haven't seen this level of fw complexity in other SoCs
<_[m]123> robclark lol I am with the "regular" folk I don't speak kernel dev
<robclark> tl;dr: issue is with the compositor
<robclark> if it carries on and lights up the display without CTM then things are working properly
echanude has joined #aarch64-laptops
<jhovold> robclark: no, that was with the X13s (which has four DSPPs it seems)
<jhovold> _[m]123: I'm sure I've asked before, but you use wayland, right? you too konradybcio?
<konradybcio> yep, w/ plasma5 and sddm
<_[m]123> same ^
<_[m]123> maybe it's a kde issue then?
<jhovold> possibly something triggered by kde at least
<jhovold> we had a regression rc1 (fixed in rc2) triggering lockups for wayland users
<jhovold> _[m]123: how long is that "freeze" you mentiond before the reset? is it always freeze + reset?
<jhovold> (when you've triggered it during use)
<_[m]123> it's subjectively long and seemingly varying in duration
<_[m]123> like you have time to go beyond the first, wtf my mouse not moving why, ctrl alt del to logout
<_[m]123> etc
<_[m]123> ofc 4-5th time you re like ok whatever this shit again
<_[m]123> let's say couple of seconds
<jhovold> ok, sounds like hypervisor resets then
<robclark> jhovold, _[m]123, you can use modetest from the cmdline to dump state, that will show which CRTC(s) have CTM attached
echanude has quit [Ping timeout: 480 seconds]
echanude has joined #aarch64-laptops
<jhovold> robclark: all three it looks like, is it just the presence of a CTM prop that tells?
<robclark> no, it is whether there is a blob prop attached.. can you paste it?
<jhovold> ok, then there's no blob here, let's see what _[m]123 has
<robclark> but if there are 3 CRTC and 4 DSPP... seems like you shouldn't hit that error (but also why does it have more DSPP than CRTC?)
<jhovold> right, seems like it. we only have three CRTCs enabled but the hw apparently has 4 DSPPs (see sc8280xp_dspp)?
<robclark> hmm, ok.. it's got 6 LMs.. not sure why we don't advertise more CRTCs
<lollaritshe[m]> <vadikas[m]> "have you see ironrobin's..." <- i cant fetch the keys from the keyserver
<lollaritshe[m]> Remote Key not fetched correctly from keyserver
<lollaritshe[m]> "No keyserver available"
<_[m]123> whoa I can get 120hz on lower res !
<jhovold> _[m]123, robclark: no blobs there either it seems, when exactly did you see those dspp errors?
<robclark> yeah, no CTM blob attached in that dump. What exactly is happening, and which compositor? It might be better to file a issue at https://gitlab.freedesktop.org/drm/msm/-/issues or ask on #freedreno since none of the display folks are on this channel
<_[m]123> no reset all day - though it did get fckd when I closed laptop lid to check if external screen turns off (it did)
<vadikas[m]> <lollaritshe[m]> "i cant fetch the keys from the..." <- is the time correct?
<lollaritshe[m]> yea
<lollaritshe[m]> apparently alarm has some signing problems
<lollaritshe[m]> found a solution online 🫠
ungeskriptet is now known as Guest2550
ungeskriptet has joined #aarch64-laptops
Guest2550 has quit [Ping timeout: 480 seconds]
rfs613 has quit [Ping timeout: 480 seconds]
rfs613 has joined #aarch64-laptops
<pstef> on x13s grub often won't give me a choice, even though I've set timeout to 25 seconds
<konradybcio> works fine for me, sounds like a misconfiguration on your side
<pstef> I'd expect it to reliably fail every time if that was the case, but I'm not in the position to rule out anything
<jglathe_> similar observation here... sometimes its 10 secs as I wanted, sometimes its 25... often on systemctl reboot or reboot from systemd-unit
<clover[m]> Sometimes the keyserver is down lollar. I've noticed waiting a bit and then trying again helps
<lollaritshe[m]> just not specificing mit server is enough
<lollaritshe[m]> it just uses another one
<clover[m]> Cool
<lollaritshe[m]> took 2 seconds instead of 10 minutes lmao
KREYREN_oftc has quit [Remote host closed the connection]
jglathe_volterra has joined #aarch64-laptops
<konradybcio> jhovold so far a day without crashes (with qseecom=n)
<_[m]123> <konradybcio> "jhovold so far a day without..." <- same ⛅️
<_[m]123> > <@konradybcio:matrix.org> jhovold so far a day without crashes (with qseecom=n)
<_[m]123> * same 🎉
<pstef> my workaround is to set the default kernel with grubby
<lollaritshe[m]> what do i do if my lspci output lacks the id?
<lollaritshe[m]> modem seems to be working
<lollaritshe[m]> and esim + phone nr is recognized
<lollaritshe[m]> but i cant connect to network
<lollaritshe[m]> searching for network gives me an error but i cant read it due to the window being to small (and not resizable) 🫠
juergh_ has joined #aarch64-laptops
juergh has quit [Ping timeout: 480 seconds]
<clover[m]> try this: sudo lspci -nn | grep Foxconn
<clover[m]> i guess newer version of lspci doesnt show id's by default
<clover[m]> this wiki could use an update
jhovold has quit [Ping timeout: 480 seconds]
echanude has quit [Ping timeout: 480 seconds]
<_[m]123> I wonder if the influx of new users here is representative of lenovo x13s sales - if yes than we might not be getting oryon cpu thinkpad amiright 😭
<lollaritshe[m]> <clover[m]> "this wiki could use an update" <- definitly 😶‍🌫️
<steev> clover[m]: 6.8 is just waiting on me to do the defconfig bits, so hopefully i'll finish tonight
<lollaritshe[m]> uhm
<lollaritshe[m]> any idea how i would delete the eSIM without having to boot windows?
<lollaritshe[m]> it does work but im switching providers next month and well
adamcstephens has quit [Remote host closed the connection]
adamcstephens has joined #aarch64-laptops
adamcstephens has quit [Remote host closed the connection]
adamcstephens has joined #aarch64-laptops
adamcstephens has quit [Remote host closed the connection]
adamcstephens has joined #aarch64-laptops