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]
<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
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
<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
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
<_[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]