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
KhazAkar has quit [Quit: Connection closed for inactivity]
KhazAkar has joined #aarch64-laptops
jglathe has joined #aarch64-laptops
Lucanis has quit [Ping timeout: 480 seconds]
hexdump0815 has joined #aarch64-laptops
Lucanis has joined #aarch64-laptops
hexdump01 has quit [Ping timeout: 480 seconds]
jglathe has quit [Ping timeout: 480 seconds]
jglathe has joined #aarch64-laptops
<jglathe> interesting, no WARN anymore
<jglathe> I will remove my patch to cross-check if it has outlived its usefulness
<jglathe> yep, no WARN after removing the patch - thank you @konradybcio
<jglathe> hmm https://drive.google.com/file/d/1W8B9bIo7bj4XYzfQ0WyWNkSVW_OVkzwk/view?usp=sharing looks like x13s is suspending and sometimes causing this WiFi failure
jglathe has quit [Ping timeout: 480 seconds]
jglathe has joined #aarch64-laptops
jglathe has quit [Ping timeout: 480 seconds]
jglathe has joined #aarch64-laptops
iivanov has joined #aarch64-laptops
<lun[m]> I'm getting a build error for ar1337 in steev's 6.7.0-rc8 branch, `linux> ../drivers/media/i2c/ar1337.c:349:68: error: passing argument 2 of 'v4l2_subdev_get_pad_format' from incompatible pointer type [-Werror=incompatible-pointer-types]` and then a pile of other errors later. Is that module known broken? I don't care about the webcam so I don't think I need it
<lun[m]> Using johan_defconfig
<jglathe> hmm can't confirm, I rebase my stuff onto steev's branch and it works. I'll check with laptop_defconfig
<lun[m]> I have a few extra configs set on top of johan_defconfig in case any of these look suspicious: https://github.com/LunNova/nixos-configs/blob/c8e68a83795b69fbafcf403fdcd2a30af0a76703/hosts/amayadori/x13s.nix#L26-L47
<jglathe> on first glance, no
craftyguy has quit [Remote host closed the connection]
craftyguy has joined #aarch64-laptops
martiert has quit [Quit: WeeChat 4.1.2]
<jhovold> dgilmore, robclark: are you seeing suspend failing due to the wifi acting up, or a failure to resume the wifi?
<jhovold> anything in the logs when this happens?
<jhovold> I've seen ath11k failing to resume about twice in a year, looks like the fw has crashed and MHI says something about not being able to set the device power state and then the error recovery code goes bananas
martiert has joined #aarch64-laptops
<jhovold> apart from the external display suspend issue, suspend seems to work quite reliably here
<jglathe> @lun[m] USB_XHCI_PCI is not in menuconfig, only USB_PCI
<Jasper[m]> <jhovold> "dgilmore, robclark: are you..." <- I've seen the latter often. Ever since I installed Linux on the thing
<jhovold> Jasper[m]: and is there anything in the logs when that happens?
<Jasper[m]> There is, haven't gotten a dmesg for it on hand though
<Jasper[m]> It'll happen if it's suspended for a while
<Jasper[m]> (don't know if suspended is the right word, I mean screen off, lid closed)
<jhovold> that should mean suspended unless you've overridden the default systemd config I think, the log should tell
<jhovold> to be more specific, unless you have an external display connected, closing the lid should suspend the machine it will show in the logs
<jhovold> s/it/and it/
<Jasper[m]> jhovold: Yeah that's it
<Jasper[m]> I remember there was some discussion around there being one lower power state, but I might be mixing things
<Jasper[m]> I'll throw it into suspend for now, I'll check up on it in a couple of hours
svarbanov has quit [Read error: Connection reset by peer]
svarbanov has joined #aarch64-laptops
<jhovold> Jasper[m]: yes, there are lower power states that we are currently not hitting during suspend, but it's still "system suspend"
<jhovold> exeat: gave pipewire a try, and sound is definitely broken with pipewire
<jhovold> reducing the quantum fixes the crackling noise with alsa apps, and too-fast playback with pulse-apps, but recording is similarly broken with both settings
<jhovold> Bioxvirizm-x13s[m]: since you reported issues with the mic I assume you use pipewire, so try switching to pulseaudio
iivanov has quit [Ping timeout: 480 seconds]
<Bioxvirizm-x13s[m]> jhovold: I have so far generally switched to Windows =)))no matter how painful it is. I want to be satiated with good sound, working microphone and a gorgeous camera in zoom calls)))))
<Bioxvirizm-x13s[m]> Good thing I made a recovery flash drive, turns out there are surprises in there.
iivanov has joined #aarch64-laptops
hexdump0815 has quit [Quit: WeeChat 3.8]
hexdump0815 has joined #aarch64-laptops
<exeat> jhovold: I see, I admit I'd only tried recording a couple of times, and with a BT headset rather than the built-in audio
<exeat> My plan (before running out of holiday time) had been to use sox or aplay to pipe some heavily attenuated audio directly to alsa, with the same buffer sizes etc, to see if pipewire could be exonerated or further suspected :)
<konradybcio> new bios update for x13s!
<Jasper[m]> Anything interesting?
<konradybcio> "fix bug" as usual
<konradybcio> and as usual, the update package is missing the ec firmware.. at least according to the inno file structure
<Jasper[m]> That's crappy. I may be behind on those I guess
<konradybcio> Manufacturer="Lenovo" DeveloperNation="Japan" CpuManufacturer="IntelOrAMD"
<konradybcio> hmmm
<Bioxvirizm-x13s[m]> =)))
<jglathe> @lun[m] QCOM_PD_MAPPER can only be set as module
<jglathe> @lun[m] QRTR too
<jglathe> @lun[m] building...
<jglathe> laptop_defconfig took 22mins on volterra
<jglathe> johan_defconfig with the adds of @lun[m] took 3m30s, wow that was fast
jglathe has quit [Remote host closed the connection]
jglathe has joined #aarch64-laptops
<jglathe> out of cutiosity I booted this kernel on volterra, no display.
jglathe has quit [Remote host closed the connection]
jglathe has joined #aarch64-laptops
<jhovold> exeat: sounds like a good plan if you can find the time
<jhovold> i noticed that the input device meter for the built in speaker was at a constant high level with pipewire, so not suprising that the recording turned out to be distorted
<jhovold> works fine with pulseaudio, i just reconfirmed
<jhovold> meter in pavucontrol, that was
Evaia631011 has joined #aarch64-laptops
<jhovold> and that was meant to say "built in microphone"...
Evaia63101 has quit [Ping timeout: 480 seconds]
Evaia631011 is now known as Evaia63101
<konradybcio> jglathe: if you rebase your kernel and drop/clean up "take back x" style commits, i can review some of your volterra changes and maybe we can get it upstream
jglathe has quit [Remote host closed the connection]
adamcstephens has quit [Remote host closed the connection]
abcdw has quit [Read error: Connection reset by peer]
abcdw has joined #aarch64-laptops
adamcstephens has joined #aarch64-laptops
adamcstephens is now known as Guest12845
<dgilmore> Jasper[m]: suspend doesn't work at all. It wakes up immediately. WiFi gets messy and eventually drops off.
<konradybcio> logs please, folks
<Jasper[m]> <dgilmore> "Jasper: suspend doesn't work..." <- It has for me, I generally need to tap the keyboard before it actually wakes up
<Jasper[m]> <konradybcio> "logs please, folks" <- Working on it
<juergh> My X13s frequently crashes with this: https://people.canonical.com/~juergh/images/IMG_20240104_133331.jpg I'm currently on 6.7-rc8 but it's been happening with pretty much any kernel if memory serves right. I have a devel/pre-production model, so could be that. Is there anything to be gleaned from the screenshot? I have a hunch it's related to clocks but don't have any evidence.
<konradybcio> juergh: that's a part of the bootloader log.. wondering how you even got there
<konradybcio> FWIW when the laptop crashes, it often reboots instantly, and that would be one of the first things that pop up on uart
<konradybcio> is your x13s from the lenovo store, or is it some preprod unit?
<juergh> konradybcio, it's preprod
<konradybcio> okay.. this shouldn't be an issue, but just to be sure, can you check /sys/bus/soc/devices/soc0/revision
iivanov has quit [Quit: Leaving...]
<juergh> 1.1
<konradybcio> okay same on my production one
<konradybcio> perhaps it's just crashing for $some_reason and it's dropping you to the bootloader log splash because your fw or fuses are configured in a way that makes it display these infos
iivanov has joined #aarch64-laptops
<juergh> That would explain why I seem to be the only one seeing this AFAIK. But it feels like the machine is crashing more often than others.
iivanov has quit [Remote host closed the connection]
iivanov has joined #aarch64-laptops
<jhovold> dgilmore: different issue then, anything in the logs?
<jhovold> juergh: I have a similar machine like you and also see that on access faults and similar so that the hypervisor watchdog kicks in
<jhovold> production machines just reboots
<jhovold> I assume your running Ubuntu's kernels on yours?
<jhovold> fwiw, not seeing that randomly here
<konradybcio> fwiw the ubuntu kernel does die randomly for me on a "normal" x13s..
<konradybcio> quite frequently, i might add
<jhovold> konradybcio: sounds like it could be related then
<Jasper[m]> <Jasper[m]> "It has for me, I generally..." <- For some reason this behaviour disappeared though which is interesting
jglathe has joined #aarch64-laptops
<jhovold> Jasper[m]: what behaviour?
<jhovold> wifi occasionally acting up on resume?
<Jasper[m]> jhovold: Normally when suspending, the screen stays black until I press a button on the keyboard. Now it starts up immediately on any input (touchpad, lid hall sensor, keyboard)
<Jasper[m]> I haven't yet gotten the wifi driver to mess up, but I'll come back on that when it does
<jhovold> Jasper[m]: ok, those have all been marked as wakeup sources since 6.1, perhaps you just didn't notice before
<dgilmore> that was booting the system, logging in and telling it to suspend
<dgilmore> the screen turned off, but nothing else did
<jhovold> dgilmore: ok, thanks, so this looks related to the apparent fw crash on resume:
<jhovold> mhi mhi1: Did not enter M0 state, MHI state: M3, PM state: SYS ERROR Detect
<jhovold> for some reason your machine decides to resume immediately, and that possibly confuses the wifi
<jhovold> are you seeing this with a mainline kernel also (or one of my wip branches)?
<dgilmore> Wifi is not working, but the 5g modem is
<dgilmore> I am using mainline, well fedora rawhide, 6.7.0-0.rc8.61.fc40.aarch64
<jhovold> so what's that, 61 patches on top of mainline?
<dgilmore> no, its the 61st 6.7 build of fedora
<jhovold> dgilmore: i suggest you try to track down what is causing the immediate resume, it may not be the wifi itself
<jhovold> have you checked the wakeup sources?
<dgilmore> I have not really dug into it
<jhovold> and if it is the wifi fw crashing and aborting suspend, does it make any difference if you disconnect before suspending
<dgilmore> the code should just be plain rc8
<dgilmore> with no patches
<dgilmore> let me reboot and try
<jhovold> odd that you seem to be the only one hitting this if it is the wifi, but perhaps some combination of AP and settings could trigger that
<jhovold> ok, good
<konradybcio> hm TIL the hole on the bottom of x13s is a reset button
<dgilmore> I put the laptop in airplane mode then suspended, it resumed immediately
<jhovold> dgilmore: cool, then something else appears to be waking the system immediately
<jhovold> you can compare /sys/kernel/debug/wakeup_sources before and after
<jhovold> dgilmore: do you have any usb devices connected?
<dgilmore> nothing is connected
<jhovold> modem connected?
<jhovold> or bluetooth perhaps?
<dgilmore> not in the last suspend, all wireless was turned off
<jhovold> dgilmore: it'd be best of you could diff those counts, but look like the wifi could be involved after all (mhi0)
jglathe_ has joined #aarch64-laptops
<jhovold> perhaps disconnect manually instead of relying in airplane mode
<jhovold> at least it looks like the wifi crashing on resume is a secondary issue
<jhovold> not sure about that modem sequence number glitch either, don't have a modem here
<jhovold> i'd disconnect manually there too, just to be sure
jglathe has quit [Ping timeout: 480 seconds]
<Jasper[m]> <jhovold> "Jasper: ok, those have all..." <- It genuinely hasn't worked for a while hahaha. I got the device around 6.4.
<Jasper[m]> <jhovold> "dgilmore: cool, then something..." <- Is this shown as the time a dmesg line appears?
<Jasper[m]> i.e. the time infront of pm: suspend devices took X seconds and pm: resume devices took X seconds
<Jasper[m]> those are about 0.3 apart for me
<Jasper[m]> *0.3 seconds
<travmurav[m]> I always had an impression that the dmesg timestamp is paused in suspend
<travmurav[m]> that is, is supposed to be
<Jasper[m]> Could be
<travmurav[m]> because for me it is, and my thing for sure sleeps really well
<Jasper[m]> I mostly wanted to know, because I'm running the exact same kernel and OS as @dgilmore
Kelsar has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
Kelsar has joined #aarch64-laptops
Guest12845 is now known as adamcstephens
adamcstephens has quit [Remote host closed the connection]
adamcstephens has joined #aarch64-laptops
<jhovold> Jasper[m]: as travmurav[m] mentioned time is paused during suspend, but you'd notice if your machine wakes up immediately (e.g. screen turning on)
<jhovold> you can also ssh in (usb ethernet) and suspend from there manually to make sure
<Jasper[m]> Using the "sleep" function from KDE leaves the screen off just fine
<Jasper[m]> jhovold: I'm assuming some systemd command will make it sleep?
<jhovold> echo mem > /sys/power/state
<jhovold> and wakeup sources can be disabled through sysfs, so perhaps something has changed in your distro to enable more than just keyboard wakeups
<Jasper[m]> <jhovold> "echo mem > /sys/power/state" <- Permission denied
<Jasper[m]> I'm guessing I need to use sudo systemd-sleep suspend
<Jasper[m]> Actually no, that doesn't exist
<Jasper[m]> hmmmm
<konradybcio> sudo required
<Jasper[m]> Does not work
<konradybcio> or well, superuser permissions.. if you're using sudo, do sudo bash -c "echo mem > /sys/power/state"
<Jasper[m]> konradybcio: Yeah that'd work
<travmurav[m]> echo mem | sudo tee whatever to write a file in sudo
<Jasper[m]> I opened an elevated session
<travmurav[m]> sudo echo will only write to stdout from root
<Jasper[m]> display stays off
<jhovold> I meant that you could log in over usb-ethernet, enter suspend manually, and make sure the ssh session is blocked until you press a key on laptop and resume
<jhovold> but it seems you really don't have any reason to suspect that your machine is resuming immediately
<Jasper[m]> No it's probably fine then, though like I said, I am running the same kernel and distro
<Jasper[m]> Actually no, a couple kernel builds behind, one sec
<Jasper[m]> Okay, same kernel, screen stays off so it seems fine
<Jasper[m]> I do get the same dwc3-qcom line as @dgilmore now which I didn't before on package version 59
<jhovold> Jasper[m]: not sure why that's there, I see something like thar for one of the ports on the multiport USB controller which isn't enabled in mainline
<jhovold> but this is for usb_1
<juergh> jhovold, yes, Ubuntu kernel. but it's a 6.7-rc8 based kernel so not very different. but lots more modularized, not sure if that could be the issue.
jglathe_ has quit [Remote host closed the connection]
jglathe has joined #aarch64-laptops
<steev> i really dislike trying to follow the conversation with the way matrix does the quoting
<Jasper[m]> I see it in the archive. I guess that's the limit of text only comms
<Jasper[m]> Or at least the way IRC does it
<robclark> matrix is kinda in the "uncanny valley" when it comes to IRC... it does it just enough different to be kinda annoying for non-matrix users ;-)
<konradybcio> and then it turned out it wasn't even turbo secure after all :(
<travmurav[m]> I'd say the main "problem" of matrix is that pretty much everything can be bridged into matrix without any loss of information, but almost never the other way around
<travmurav[m]> So people who are used to using matrix may easily be oblivious to the fact they are bridged and thus to the fact some of the things they do may not come across properly
<travmurav[m]> Reactions, message edits etc...
<Jasper[m]> travmurav[m]: I always thought their modus operandi was more to EEE other protocols instead of working together
<Jasper[m]> As in, "We are very cool, but if you really need to, you can use the other protocols using bridges."
<Jasper[m]> So them independently implementing some of those features seems not too weird
<travmurav[m]> I don't say the matrix spec is bad, more like that it allows people to forget those problems
<travmurav[m]> Like Unicode allows people to not care about encodings
jglathe_ has joined #aarch64-laptops
jglathe_ has quit []
jglathe_ has joined #aarch64-laptops
craftyguy has quit [Remote host closed the connection]
craftyguy has joined #aarch64-laptops
iivanov has quit [Quit: Leaving...]
<_[m]1> <steev> "i really dislike trying to..." <- we could use the even more obnoxious threads lol
<steev> really, it's that quoting feature and trying to figure out where in the chat it relates to
<_[m]1> steev: it shows the first message somehow
<steev> on irc we see
<steev> 14:32:13 <_[m]1> <steev> "i really dislike trying to..." <- we could use the even more obnoxious threads lol
<_[m]1> I really liked the zulip way or what it was called
<steev> i only used zulip back when the rust team insisted on it (not sure if they still do) - i was considering adding arm64 big endian support
<_[m]1> steev: without the URL linked to the full thing?
<steev> no, no url
<_[m]1> so you can't backtrack?
<_[m]1> waw, so how to use it in an irc friendly way
<steev> i have to look for the quoted text
<_[m]1> manually?
<_[m]1> that's fckd
<steev> i mean, i COULD just start using matrix
<steev> but, i like my irc
<_[m]1> had to
<_[m]1> I liked irc back when there were download bots hahha
<_[m]1> steev: test
<steev> there still are :D
<konradybcio> steev: what use do you have for arm64be
<steev> konradybcio: i don't, but the aircrack-ng dev came to me and asked for the cheapest big endian machine one could get since he was getting bug reports, and i said, well arm can do big endian.... so i threw one together (it has since gone away) for him to test
<konradybcio> next questions: what business do the bugreporters have for arm64be
<steev> heh, well the bug reports were from s390x (i think?) and i was like, why are they running aircrack on mainframes
<konradybcio> next question: why does aircrack-ng even support s390x
<steev> i guess you can still crack on it? just can't dump or replay?
<steev> i don't know, he doesn't know, and they weren't saying why they needed it
<konradybcio> yeah maybe but the mainframe in your pocket is 1000s times faster
<steev> i don't disagree :)
<steev> it was still a pretty fun exercise getting it working
<steev> i ended up doing it on a nanopi neo plus2, which was the only device i could actually get to boot arm64be
<steev> the odroid-c2 *should* have, but wasn't (and iirc i looked at kernel logs from the CI back then, and they were reporting successful boots, but if you looked in the logs, it was actually failing)
<steev> man, his ears must have been burning because he just pinged me
zdykstra has joined #aarch64-laptops
jglathe_ has quit [Remote host closed the connection]
krzk has quit [Remote host closed the connection]
krzk has joined #aarch64-laptops
jhovold has quit [Ping timeout: 480 seconds]
Erisa has quit [Remote host closed the connection]
Erisa has joined #aarch64-laptops
<dgilmore> steev: I like my IRC also