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
<janrinze>
I'm lazy so I just dd the SDcard to the USB stick :D
<janrinze>
jenneron[m]: what is your build system?
<janrinze>
jenneron[m]: I'm using a M1 Ultra running debian :D
<jenneron[m]>
PC
<jenneron[m]>
xeon e5-2678 v3, 64 GB RAM
<janrinze>
Ah, I see. Qemu for Aarch64?
<jenneron[m]>
janrinze: pmbootstrap builds everything in alpine chroot which it installs automatically
<jenneron[m]>
some packages are built with qemu, kernel packages are built with cross-compiler
<jenneron[m]>
for you this all should be native though
<jenneron[m]>
this stuff gets enabled only when running pmbootstrap on x86_64
Jasper[m] has joined #aarch64-laptops
<janrinze>
LOL.. the usb drive was too small. got an error from dd
<jenneron[m]>
you could set UI to console in "pmbootstrap init" and use "pmbootstrap install --disk /dev/sdX" for usb storage
<jenneron[m]>
console image would be smaller
<janrinze>
no biggie. just need to use the original image and start over. :D
<jenneron[m]>
ah, i see
<janrinze>
16GB should be enough for testing for now.
<jenneron[m]>
yeah using original image would be good enough
<janrinze>
Okay, the USB stick survived and boots from the get-go.
<jenneron[m]>
janrinze: so the booting is completely fine on this one?
<janrinze>
jenneron[m]: So the issue was with the sdcard adapter to USB.
<jenneron[m]>
hmm, interesting
<janrinze>
Old crappy thing, apparently.
<jenneron[m]>
well, i'm glad it works
<janrinze>
Me too. and i'll be testing some other things now. Soon bedtime because it's getting seriously late.
<janrinze>
jenneron[m]: this MT8195 looks promising. It's plenty fast and hopefully getting full linux support soon.
<janrinze>
jenneron[m]: apparently cpu4-7 are 2.6 GHz and cpu0-3 2.0 GHz
svarbanov has quit [Ping timeout: 480 seconds]
resuenehparg[m]1 has joined #aarch64-laptops
danielt has joined #aarch64-laptops
pz[m] has joined #aarch64-laptops
Amber_Harmonia has quit [Ping timeout: 480 seconds]
aigotchi[m] has joined #aarch64-laptops
Nei[m] has joined #aarch64-laptops
f_ has quit [Read error: Connection reset by peer]
Dylanger[m] has joined #aarch64-laptops
f_ has joined #aarch64-laptops
EnigmaCurry[m] has joined #aarch64-laptops
AlexMarty[m] has joined #aarch64-laptops
Amber_Harmonia has joined #aarch64-laptops
hexdump01 has joined #aarch64-laptops
hexdump0815 has quit [Ping timeout: 480 seconds]
mcbridematt has quit [Quit: Leaving]
_[m]123 has joined #aarch64-laptops
harvests[m] has joined #aarch64-laptops
svarbanov has joined #aarch64-laptops
davidebeatrici[m] has joined #aarch64-laptops
Nick[m]12345 has joined #aarch64-laptops
sporos11[m] has joined #aarch64-laptops
konradybcio has joined #aarch64-laptops
jhovold has joined #aarch64-laptops
martiert has quit []
martiert has joined #aarch64-laptops
iivanov has joined #aarch64-laptops
mcbridematt has joined #aarch64-laptops
KREYREN_oftc has quit [Remote host closed the connection]
todi has quit []
KREYREN_oftc has joined #aarch64-laptops
iivanov has quit [Quit: Leaving]
iivanov has joined #aarch64-laptops
todi has joined #aarch64-laptops
iivanov has quit [Remote host closed the connection]
<janrinze>
jenneron[m]: second display over USBC works too. Touchscreen not, Boot over USB hub works (USB3 hub or dockingstation), No sound (dummy output) , Youtube video 2560x1440 plays well on second screen (166 dropped frames out of 24367) , Bluetooth works, Battery seems to report correctly, camera works (cheese for testing), 3D acceleration is working really well! (glmark2 and threejs.org/examples for testing)
<janrinze>
jenneron[m]: Call me impressed!
jglathe_x13s has quit [Remote host closed the connection]
jglathe_x13s has joined #aarch64-laptops
jglathe_x13s has quit [Remote host closed the connection]
<jenneron[m]>
janrinze: does `alsaucm reload` command result in error?
<Segfault[m]>
hey i'm sure it's been asked before but does anyone know exactly what's causing the high suspend power consumption on the thinkpad x13s? that and wifi not working on like 2/3 of bootups is all that's left stopping me from daily driving linux on this
<Jasper[m]>
Just to start, what OS setup are you running currently?
<Jasper[m]>
i.e. Distro, Kernel and source (if it's custom)
<Segfault[m]>
fedora rawhide, although even on custom kernels where i've verified everything works suspend power draw is still ~2W which is quite high
<Jasper[m]>
That's... still not bad considering the fact that power consumption has (afaik) not been tampered with
<Jasper[m]>
Otherwise the only tweak people have used is the aspm related kernel cmdline option. Not sure if that's still relevant though
<Segfault[m]>
i think that was fixed in 6.7
<Jasper[m]>
Yeah, I checked
<Segfault[m]>
2W isn't bad but it could definitely be a lot lower, in windows i was getting multiple weeks on a single charge even once i disabled hibernation
<Jasper[m]>
Yes
<Jasper[m]>
But so far, I think what you're reading is expected
<Jasper[m]>
The wifi thing is a new thing though, what are you experiencing?
<Segfault[m]>
yep, that's why i'm just curious where that power draw is, i'd like to know if it's fixable in linux and if so if there are any plans to
<Jasper[m]>
Any logs, dmesg?
<Segfault[m]>
Jasper[m]: it seems to be two separate issues, one where i think it was ath11k loading before adsp was started and failing to load, and another where the firmware fails to start, the former could be fixed by reloading ath11k, the latter needed one or sometimes multiple reboots and the usual things like re-probing pcie didn't help iirc
<Segfault[m]>
i don't still have logs, i'll try and get some
<jhovold>
Segfault[m]: suspend power consumption is a known issue, we're working on it
<Jasper[m]>
Segfault[m]: Afaik part of the problem is the reason why clk_/pd_ignore_unused are still needed
<Jasper[m]>
But I don't know the specifics, it was explained in @jhovold's presentation
<Segfault[m]>
jhovold: yep i've been following that for the last couple of months
<jhovold>
ah, good
<Segfault[m]>
jhovold: out of curiosity do you know specifically what parts are causing the power draw?
<Jasper[m]>
Segfault[m]: Interesting, I'm not having these issues. Do you have the sc8280xp related modules in your initramfs?
<jhovold>
we're not yet able to enter the lowest power state, something is keeping some resource on somewhere
<Segfault[m]>
interesting
<jhovold>
PITA to debug
<jhovold>
But I was under the impression that Windows did not hit that lowest state either, but was relying on hibernation
<jhovold>
perhaps whoever told me that had not found that hibernation switch you mentioned
<Segfault[m]>
i thought so too but on a clean install with just lenovos drivers added and with hibernation disabled (so power led blinking the whole time and instant wakeup) i was getting extremely low power draw
<Segfault[m]>
i forget exactly how low but iirc the battery life in that state was something like two weeks
<Segfault[m]>
that's what i get if i try to reload the module
<Segfault[m]>
jhovold: i forget where but i saw someone with a 21BY unit reporting it, i'm also using a 21BY so i wonder if that's relevant
<jhovold>
I've only seen it crash 2-3 times over the course of a year on resume, but I believe that issue may have been resolved with the latest ath11k fw
<jhovold>
yeah, you're not the only one, someone at linaro mentioned it last week as well
<Segfault[m]>
i saw the crash on resume issue, this isn't that though this is on bootup
<jhovold>
yeah i know, just saying it's the only issue i've seen myself
<Segfault[m]>
oh idk if you're aware but i also had some hard reboot issues with efivars and venus
<jhovold>
whick kernel?
<jhovold>
which
<Segfault[m]>
custom compiled ones from your repo as recently as 6.7-rc4 and fedoras 6.7 kernel (not venus on that one ofc)
<Segfault[m]>
efivars occasionally reboots the system and every time i tried to use venus with ffmpeg it'd reboot
<jhovold>
ok, thanks, haven't noticed anything like that, although I did have a couple of hard crashes with 6.8-rc1 (which I think may be external display related)
<jhovold>
just reading efivars?
<Segfault[m]>
even just running efibootmgr does it occasionally
<Segfault[m]>
it's quite rare though, i wouldn't be surprised if it was a firmware bug
<jhovold>
not good... qzed, any ideas of what may be causing the efivars crashes^
<jhovold>
yeah, it's all reverse engineered and built upon qualcomm's hacks, so quite possible
<adamcstephens>
I’ve had similar efi read crashes
<Segfault[m]>
jhovold: yeah i've noticed qcoms uh, lack of attention to detail :P
<Segfault[m]>
the x13s absolutely hated an ssd i tried to swap into it, in linux the pcie controller would occasionally freak out and in windows it'd bsod while trying to boot
<Segfault[m]>
i can't get the other wifi failure mode i mentioned to happen, if i run into it again i'll save logs and send them here
<qzed>
Can you get some logs from the efivars crash? I can have a look after I get home from work.
<qzed>
At the moment I have no clue
<Segfault[m]>
qzed: nope, it's a hard reboot as soon as you try to access them, i think from the hypervisor?
<jhovold>
maybe konradybcio has some ideas about the ffmpeg crash, can you provide some details on how you reproduce it?
<Segfault[m]>
just by trying to transcode a file with v4l2-m2m
<qzed>
Segfault: could be... Could it be that something isn't initialized properly?
<adamcstephens>
yeah I don’t think there are any logs from the efivars crash. as Segfault[m] said it reboots immediately. I’ve triggered it with efibootmgr and bootctl status
<Segfault[m]>
maybe? i haven't found any pattern with the efivars thing although it's so rare and inconsistent that i haven't really been able to start looking for one
<jhovold>
how reproducable is the ffmpeg/venus crash?
<jhovold>
i can play back using gstreamer just fine
<Segfault[m]>
jhovold: that one happened every time i tried to transcode or decode anything with ffmpeg, i didn't try gstreamer
<qzed>
Hmm no idea then, sorry.
<jhovold>
and I think firefox is using it for decode this days too, but i haven't rellay verified
<Segfault[m]>
i haven't tried venus since 6.7-rc4 because i switched to fedoras 6.7 build
<_[m]123>
oh btw, I also had 2-3 times reboot on logging into kde on 6.8.0rc3 jhovold, but only first login try
<qzed>
Did you try with the new tz allocator patches? Maybe it doesn't like something about the memory being passed in?
<jhovold>
ok, not sure if something has changed upstream since then in venus, haven't used the tested gstreamer playback in a while, but it worked when I added konrad's patches and is working now (with 6.8-rc3)
<_[m]123>
and lol on resume, I'm having some erratic screen behavior - usually the external screen doesn't come up or at least not immediately, I have had it not come up at all and then sometimes after a while it comes through and now on resume, only my external screen is coming up mm
<jhovold>
_[m]123: link training sometimes fails on resume for the eDP, very rare here, but the screen comes up all garbled
snydvaos has joined #aarch64-laptops
<jhovold>
can just suspend again to fix it
<Segfault[m]>
jhovold: alright when i'm able to i'll give it another try
<_[m]123>
jhovold: no garbling here but consistent issue
<Segfault[m]>
qzed: probably not? unless it's already in the fedora kernels then no
<_[m]123>
looking in dmesg, is it high speed usb?
<qzed>
Segfault: afaik not, maybe worth a try
<Segfault[m]>
qzed: have you got a link to the patches? i'm not very good at browsing the mailing list lol
<jhovold>
_[m]123: so what are you seeing, can you describe it again? nothing is displayed? on which screen? and this is after resume with 6.8-rc3?
<jhovold>
_[m]123: and if that happens again, can you check the logs? I had the internal display not come up at boot the other day, so there are definitely some regression there in 6.8-rc
<jhovold>
haven't tried or looked at it myself yet
<Segfault[m]>
oh on another note i think i ran into a path length bug in the x13s efi firmware lol, it gets stuck while handing off to the kernel if the filename is longer than ~120-130 characters :P
<jhovold>
sigh... :/
<Segfault[m]>
that was interesting to find out when trying to debug why specifically fedora silverblue rawhide wouldn't boot once installed, turns out a vmlinuz with a git commit in its filename that's stored in a directory with a uuid as its name makes a fairly long path
<_[m]123>
<jhovold> "(⊙_◎): so what are you seeing..." <- I've moved back to steevs kernel to have ipv6 working (for my vpn)
<_[m]123>
on resume only 1 screen (usually the laptop one) comes on, external screen is not displaying
<_[m]123>
today I resumed and only my external screen came up 😲
<jhovold>
heh, at least an improvement since 6.7 when neither screen came up ;)
<_[m]123>
I can boot 6.8rc3 later to see if it's the same
<_[m]123>
lol
<_[m]123>
any reason why you don't enable ipv6 btw?
<jhovold>
I've promised to file some reports about the DP hotplug issues I've noticed with 6.8-rc, there's just too many things that needs to be done at once (as always)
<_[m]123>
steev said for privacy concerns before, but enabled it in the end seemingly
<jhovold>
I thought ipv6 was enabled?
<jhovold>
I don't use it here, but I left it enabled in johan_defconfig on purpose for others who might
<jhovold>
perhaps some secondary config option is missing (e.g. netfilter)
<jhovold>
_[m]123: there's some usb device failing to resume in there (fifth port of your hub)
<jhovold>
how is your external display connected? not through the hub I assume?
<jhovold>
that wouldn't work of course
<jhovold>
_[m]123: try disconnecting everything but the external display, and see what happens, you may be running into some of these new DP hotplug issues
<jhovold>
_[m]123: so ipv6 is enabled, just as in the arm64 defonfig, but laptop_defconfig has some more ipv6 related options
<jhovold>
if you can figure out which one is needed I can enable it
<jhovold>
if it seems like something that is generally useful, i mean
<adamcstephens>
jhovold: thanks I’ll check out that TZ patchset. I’m using your rc3, so I should assume that’s not applied there?
<jhovold>
adamcstephens: right, it's not in my wip branches
<_[m]123>
yeah through the hub, i tried yesterday to connect directly but it didn't come up either
<_[m]123>
it works when I boot like this
<_[m]123>
also lol my external screen was working through the hub on resume and my internal display remained off - which is bonkers lol
<_[m]123>
I just rebooted, kind of want to use both atm
<jhovold>
_[m]123: indeed, but confirms that the DP hotplug rework in 6.8-rc1 is not quite ready yet...
<_[m]123>
I'll do some more plugging soon ™️
<jhovold>
just remember to check the logs when the displays fail to come up
<_[m]123>
booted rc3 now 🙂
<_[m]123>
wtf it only enabled the external display
<jhovold>
I saw the followinh the other day and was left without any display on boot:
<jhovold>
[drm:drm_bridge_attach [drm]] *ERROR* failed to attach bridge /soc@0/phy@88eb000 to encoder TMDS-31: -16
<jhovold>
[drm:dp_bridge_init [msm]] *ERROR* failed to attach panel bridge: -16
snydvaos has quit [Quit: Leaving]
jglathe_x13s has joined #aarch64-laptops
<_[m]123>
ok something got really fckd now, hard reset
<_[m]123>
connected directly now
<_[m]123>
nice, fs corrupted
<janrinze>
jenneron[m]: alsaucm reload
<janrinze>
ALSA lib confmisc.c:165:(snd_config_get_card) Cannot get card index for -1
<janrinze>
ALSA lib parser.c:2830:(uc_mgr_import_master_config) card 'hw:-1' is not valid
<janrinze>
ALSA lib main.c:1554:(snd_use_case_mgr_open) error: failed to import hw:-1 use case configuration -19
<janrinze>
alsaucm: error failed to open sound card hw:-1: No such device
<jenneron[m]>
janrinze: try `strace alsaucm reload` and upload it
<jhovold>
_[m]123: yeah, we need to figure out what's causing those crashes, I think it is related to the external disaplay but there could be more than one issue at play here
<jhovold>
_[m]123: did it just reset on boot, or after connecting the external display?
iivanov has joined #aarch64-laptops
<_[m]123>
last time it was looking like filesystem full but can already have been the fs corruption ☹️
<_[m]123>
maybe my external nvme got disconnected again and the torrent client filled my disk
<jhovold>
Segfault[m]: forgot to ask you about your observation that that ath11k failing to start could be related to starting the adsp
<jhovold>
the adsp always starts first here, and I don't see any such ath11k issues
<jhovold>
in the log you sent the adsp is indeed started really late, would be good to confirm if this is just coincidence or not
<Segfault[m]>
i had a couple of instances that i can't replicate at the moment where the log output was different and reloading ath11k_pci would fix it, in those logs iirc it looked like ath11k_pci was loading before remoteproc finished for adsp but i don't have a copy of any of those to check
<jhovold>
ah, ok, so that was some other issue
<Segfault[m]>
jhovold: i'm using fde and i don't think i added all the adsp stuff to my initramfs, the long delay will be me entering my password :P
<jhovold>
ah, right
iivanov has quit [Quit: Leaving]
<jhovold>
how often roughly do you see ath11k failing to start? i may send some patches your way if you can reproduce that fairly reliably (as I don't seem to be able to here)
<jhovold>
i see you wrote 2/3 boots...
<Segfault[m]>
with a log looking like the one i sent earlier? probably about half of all boots
<Segfault[m]>
i haven't measured but it's a lot
<jhovold>
should be good enough to test things then
<Segfault[m]>
i'll get a 6.8-rc3 build with the patches from your tree going tomorrow, then i can test extra patches
<jhovold>
great, thanks!
<_[m]123>
ok got the system up again waw - I don't see anything of bridge in my dmesg but the extenral monitor is not working
<adamcstephens>
i ran a loop with bootctl+efibootmgr for about 15 minutes without problems. it only took a minute or so on your rc3 wip branch
<_[m]123>
microphone is working though 🥳
<adamcstephens>
*a minute or so to crash
<jhovold>
adamcstephens: that's really good news, thanks for testing!
<jhovold>
I'll try to take a closer look at that series soon, looks like it may be a hard sell to get it backported, though
<jhovold>
qzed: ^
<adamcstephens>
it’s not super important to me if it gets backported. I’ll probably keep it applied as long as it does so cleanly, but reading the efivars isn’t something I do frequently. I only even noticed it when converting my install to secure boot which had a few steps to check the state.
<adamcstephens>
I guess in theory it could happen while installing Linux, but if nobody has reported such then it’s probably not an issue
jglathe_ has joined #aarch64-laptops
jglathe_sdbox2 has quit [Remote host closed the connection]
jglathe_x13s has quit [Ping timeout: 480 seconds]
todi has joined #aarch64-laptops
hexdump01 has quit []
hexdump0815 has joined #aarch64-laptops
KREYREN_oftc has quit [Remote host closed the connection]
KREYREN_oftc has joined #aarch64-laptops
jglathe__ has joined #aarch64-laptops
jglathe_ has quit [Ping timeout: 480 seconds]
<clover[m]>
<_[m]123> "microphone is working though 🥳" <- on what kernel do you have a working microphone?
<Bioxvirizm-x13s[m]>
<_[m]123> "microphone is working though 🥳" <- Oo Seriously, has the microphone become full-fledged?
<_[m]123>
I just had a one hour call so :shrug
<_[m]123>
s/:shrug/🤷/
<_[m]123>
I'm back on 6.8-rc3 now to check the resume dpe issues but not reproduced yet
<clover[m]>
do you have to use pulseaudio?
<_[m]123>
I am now, yes - not sure if that was a necessity
<_[m]123>
I also was having some weird kodi issue - the "kodisink" audio line always gets dropped to 0% (still the case btw) but did some reinstalling / cleaning