ChanServ 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>
please try to remember that you are also bridged with irc and those matrix features make messages near impossible to read
ellyq has joined #aarch64-laptops
<steev>
bryanodonoghue: fwiw, i'm having issues with camera with 6.12-rc3 as well; but mine seems cma related; [ 1877.350714] cma: __cma_alloc: linux,cma: alloc failed, req-size: 4000 pages, ret: -12
<steev>
[ 1877.350728] cma: number of available pages: 96@9888+96@13984+96@18080+96@22176+96@26272+2400@30368=> 2880 free of 32768 total pages
ellyq_ has quit [Ping timeout: 480 seconds]
enyalios_ has joined #aarch64-laptops
alexlanzano has quit [Quit: Connection closed for inactivity]
enyalios has quit [Ping timeout: 480 seconds]
amstan has joined #aarch64-laptops
<amstan>
Steve Cossette [Farchord]: pls listen to steev
<amstan>
no more replies like that
<farchord>
It's not a question of bad faith, but.... I'll do my best, but ignoring a major matrix feature in a matrix channel might be difficult
<amstan>
it's mainly an irc channel, we're only visitors from this other weird protocol
<farchord>
fair enough... as I said I'll do my best lol
<steev>
fwiw, this is what us irc users see when y'all do that
<farchord>
I know what they see, to be fair that's kinda the bridge's fault for formatting it like that lol
<farchord>
But I do understand
<abby>
and matrix refuses to improve it...
<farchord>
Matrix lacks in alot of things
<steev>
you aren't the only one, i wasn't meaning to call you out specifically, just saying it in general
<farchord>
Oh I understand and I didnt feel targeted
<farchord>
I'm trying to find a good comparative.... it's like you're used to handling a fork a specific way and you're being asked to handle it a different way because it's inconvenient to someone else. Fair enough question, but you've been using a fork for years this way, learning to handle it differently in a specific setting is a bit on the difficult side, if that makes sense. Again, I'm not trying to be combative :)
<farchord>
But as I said I'll do my best to remember
<amstan>
it's fine, i understand the temptation, but irc users have hated us for forgetting, i guess this is similar to top posting+html on lkml while using gmail
<steev>
yeah, i'm definitely not a matrix user, i tried it but just didn't see the advantages over irc
<steev>
amstan: heh that's fairly apt
<farchord>
Strange how I was thinking about that amstan XD
<amstan>
Steve Cossette [Farchord]: careful with message lengths too
<farchord>
>.<
<amstan>
unless you really want to do a pastebin situation (which is handy actually)
<farchord>
Oh well yeah I assume the triple backquote dont translate in irc either
<farchord>
and tbf, I don't think matrix is different than irc.... it has more modern features that's for sure, but it's sorely lacking in ALOT of domains
<farchord>
*better
<farchord>
I'm a moderator in a couple open source project channels.... and they're getting spammed with VERY unsavory content....
<abby>
matrix has lots of advantages over irc, like messages sometimes taking 15min to deliver, or <failed to decrypt>
<farchord>
Well, "failed to decrypt" messages only happen once in a blue moon, if you verified your client then you should be fine knock on wood
<farchord>
Disparity of features between all the different matrix clients is indeed a big matrix quirk
<farchord>
IRC clients are just.... irc. That's it, you want features? Load scripts lol
<farchord>
With that being said, I'm gonna head to bed, gnite
<abby>
well, there's also ircv3 capability negotiation, but one of the major factors in new capabilities are considering how to fallback gracefully for clients that don't support it
hipboi has joined #aarch64-laptops
tobhe_ has joined #aarch64-laptops
tobhe has quit [Ping timeout: 480 seconds]
hipboi has quit [Quit: hipboi]
hexdump01 has joined #aarch64-laptops
hexdump0815 has quit [Ping timeout: 480 seconds]
hipboi has joined #aarch64-laptops
hipboi has quit [Quit: hipboi]
alexlanzano has joined #aarch64-laptops
hipboi has joined #aarch64-laptops
alfredo has joined #aarch64-laptops
jhovold has joined #aarch64-laptops
alfredo has quit [Ping timeout: 480 seconds]
<JensGlathe[m]>
Hmm interesting. On the Snapdragon DevKit is firmware for x1e "hamoa" and x1p "purwa"
<maz>
jhovold: re my UART issue above, I've confirmed that reverting to 6.11 results in a working console.
<maz>
I'll try and bisect the stuff added to 6.12-rc3 to narrow it down.
<jhovold>
maz: hmm, interesting, I did not think those would be related to your reset
chrisl has quit [Ping timeout: 480 seconds]
<jhovold>
there was a few fixes that went into rc1 one as well and that could be involved here if this is indeed the serial driver triggering the reset
<jhovold>
JensGlathe[m]: does the uart console still work in EL2 on the sc8280xp devkit with 6.12-rc3? Assuming it has one...
<JensGlathe[m]>
Assuming it has one... I thought there is one. Will check
<travmurav[m]>
I think that old ms devkit is just a surface mobo in a box so even if there is one it's just testpoints i guess
hipboi has joined #aarch64-laptops
<maz>
jhovold: for what it is worth, the reset occurs independently of EL2 (it also fires at EL1).
alfredo1 has joined #aarch64-laptops
<JensGlathe[m]>
Hmm couldn't find the physical outlet, but it appears to be there
<Jasper[m]>
tobhe_: Yeah I mean, it's still Qualcomm's IP anyway
<Jasper[m]>
Ah crap I keep forgetting that I should stop using the reply function
<tobhe>
renders fine here :) probably just a problem with longer messages
<Jasper[m]>
Yeah + message threads
crisma has joined #aarch64-laptops
alfredo has quit [Remote host closed the connection]
hipboi has joined #aarch64-laptops
<jhovold>
Jasper[m]: last thing I heard was that things are still moving forward, slowly, on releasing the venus fw
<jhovold>
there's still some work that needs to be done to upstream the kernel bits on top, discussions regarding the legacy bindings we'd be using
<Jasper[m]>
I'd imagine it doesn't help that there's no legal™ way to actually use/test the kernel bits
<jhovold>
it's mostly that I'd prefer not to enable things before the hw is in place as depending on the kernel config that can result in people running the interconnects at full throttle, and losing a few hours of battery time
<jhovold>
s/hw/fw/
<jhovold>
and then someone needs to spend time on upstreaming the kernel bits of course
<Jasper[m]>
Absolutely fair, is there no way to implement fallback behaviour for that?
<jhovold>
there is a kernel config option for that, but people may not be aware of or use it
<Jasper[m]>
I think there may be a couple of people here that could enable it distrowide
<Jasper[m]>
If it is something you can enable without causing further trouble I mean
<Jasper[m]>
I know of Debian, Fedora, pmOS, (unofficial) alarm, probably more.
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
<tobhe>
out of interest: which option is that?
<jhovold>
Jasper[m]: yeah, that's the problem, it's not supposed to be enabled generally
<jhovold>
I'm talking about
<jhovold>
CONFIG_FW_DEVLINK_SYNC_STATE_TIMEOUT
<jhovold>
"You should almost always want to select N here unless you have already successfully tested with the command line option on every system/board your kernel is expected to work on."
<SpieringsAE>
I wonder how fast linux-firmware grows if stuff like this happens
alfredo has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
<Jasper[m]>
The json files shouldn't be too bad
hightower2 has joined #aarch64-laptops
<maz>
jhovold: unable to reproduce the UART crash I was seeing yesterday, so I'll punt it down the pile of "things to look at one time" and get on with actual work...
<maz>
could have been a consequence of the way the kernel was generated (initrd built in a VM and moved to the x1e box).
hipboi has quit [Quit: hipboi]
<jhovold>
maz: sounds good
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
srinik has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
SpieringsAE has quit [Quit: Leaving]
chrisl has quit [Ping timeout: 480 seconds]
<maz>
weee... the x1e devkit is pulling some serious watts. up to 110W when compiling the kernel. somewhat faster than my M2, but about using about twice the energy...
hightower2 has quit [Remote host closed the connection]
<HdkR>
Nice
<travmurav[m]>
I guess the question is how much does it take when it matches the perf, afaiu the "de" sku is "fully unlocked" wrt power usage?
<JensGlathe[m]>
revs like it, yeah
chrisl has joined #aarch64-laptops
<maz>
yup. I wonder how much energy goes into the last 10% of performance...
<JensGlathe[m]>
50W
chrisl has quit [Ping timeout: 480 seconds]
<maz>
it's quadratic, so yeah, something like that.
iivanov has quit [Remote host closed the connection]
<macc24>
diminishing returns :D
<JensGlathe[m]>
my x1e-78-100 is screaming fast with out the afterburner
iivanov has joined #aarch64-laptops
kalebris has joined #aarch64-laptops
iivanov has quit [Ping timeout: 480 seconds]
iivanov has joined #aarch64-laptops
iivanov has quit [Ping timeout: 480 seconds]
iivanov has joined #aarch64-laptops
<maz>
devkit FW, the turd keeps laying eggs. SCR_EL3.ECVEn must be left to 0 while the ID regs advertise ECV. as a result, KVM accesses CNTPOFF_EL2, EL3 takes a trap, the box resets.
<maz>
gunhya is primitive enough not to notice, I guess.
iivanov has quit [Remote host closed the connection]
* maz
goes and add arm64.nocntpoff...
iivanov has joined #aarch64-laptops
srinik has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
phire_ has joined #aarch64-laptops
phire is now known as Guest6992
phire_ is now known as phire
Guest6992 has quit [Ping timeout: 480 seconds]
srinik has quit [Ping timeout: 480 seconds]
SpieringsAE has joined #aarch64-laptops
alfredo has quit [Quit: alfredo]
<SpieringsAE>
god I'm hating living in the netherlands rn, none of the x elite machines I want are being sold here
<SpieringsAE>
I just got a response from asus that they wont be selling the 32gb ram variant of the vivobook that I want, and none of the places that sell it will ship to here :(
<JensGlathe[m]>
tried notebooksbilliger.de?
<SpieringsAE>
instead of the normal 32gb variant, we get one with a wacky german qwertz keyboard layout
<JensGlathe[m]>
zhe germanz prefer these
<SpieringsAE>
hmm that place seems to sell a different variant that is also 32gb, gotta verify its not qwertz though, thanks anyway for recommending that website
<robclark>
x1e is pretty good at compiling things.. kernel rebase that inevitably touches some headers indirectly included everywhere sucks much less ;-)
srinik has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
jhovold has quit [Ping timeout: 480 seconds]
chrisl has quit [Ping timeout: 480 seconds]
enyalios has joined #aarch64-laptops
enyalios_ has quit [Ping timeout: 480 seconds]
pstef has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
iivanov has joined #aarch64-laptops
iivanov has quit [Read error: No route to host]
chrisl has quit [Ping timeout: 480 seconds]
iivanov has joined #aarch64-laptops
iivanov has quit [Ping timeout: 480 seconds]
<freekurt[m]>
What is the best supported x1e laptop right now? Does anyone have a support matrix published somewhere?