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
ektor5 has joined #aarch64-laptops
fantom has quit [Read error: No route to host]
fantom has joined #aarch64-laptops
fantom has quit [Read error: No route to host]
fantom has joined #aarch64-laptops
tobhe has joined #aarch64-laptops
hexdump01 has joined #aarch64-laptops
hexdump0815 has quit [Ping timeout: 480 seconds]
tobhe_ has quit [Ping timeout: 480 seconds]
mani_s has joined #aarch64-laptops
alpernebbi has quit [Ping timeout: 480 seconds]
icecream95 has joined #aarch64-laptops
alpernebbi has joined #aarch64-laptops
<icecream95>
I've had the freeze+reboot issue twice in the past month (and I don't remember it happening before that), on vivobook with stock SSD and still on the ubuntu-concept 6.14 kernel
<icecream95>
I wonder how common it is with people who have never run Linux on their machines... since there'll be a rather low representation of that in this channel
mani_s has quit [Remote host closed the connection]
<robclark>
I've had similar recently (but with debug kernel).. nothing that looks too hw specific in journal:
<robclark>
but no idea if this is anything like what others are seeing.. I'm at least getting _something_ in journalctl
<robclark>
(that is also w/ a fairly large stack of patches of stuff I am working on.. but at least doesn't seem related to any of that)
<icecream95>
It's a pity that RAM is encrypted, since otherwise it could be possible to see if there is a pattern in what is happening just before the crash
eluks has quit [Remote host closed the connection]
eluks has joined #aarch64-laptops
weirdtreething has quit [Remote host closed the connection]
weirdtreething has joined #aarch64-laptops
weirdtreething has quit [Remote host closed the connection]
weirdtreething has joined #aarch64-laptops
icecream95 has quit [Ping timeout: 480 seconds]
weirdtreething has quit [Remote host closed the connection]
weirdtreething has joined #aarch64-laptops
jhovold has joined #aarch64-laptops
SpieringsAE has joined #aarch64-laptops
ungeskriptet has quit [Remote host closed the connection]
<alexVinarskis[m]>
kuruczgy: thanks for the tip, rebuilding now on rc3, lets see!
wizzard has joined #aarch64-laptops
<macc24>
Jens Glathe: i wouldn't call the wifi&bt module on slim7x removable
<macc24>
it's soldered down, just on a daughter pcb
<JensGlathe[m]>
Meneither
<macc24>
it's mentioned in a comment on your slim7x bluetooth support patch on lkml
<JensGlathe[m]>
I know. My primary objective is to get it upstream
<macc24>
is upstreaming the goal itself or means to a goal?
<macc24>
why send patches upstream with comments that have information you don't really believe in
<JensGlathe[m]>
I've seen the PCB photograph. Seeing is believing. That TODO comment doesn't hurt, I find this whole pwrseq/bt debate silly (and apparently I'm not the inly one).
<anthony25>
I dont get it aswell, maybe you can add that it's "removable (but soldered down)"?
<anthony25>
It might be to avoid any confusion if other laptops are using the same pattern but with an actual removable m.2 card
<JensGlathe[m]>
You need the definitions either way. What's the point
<alexVinarskis[m]>
Its typically removable, or soldered down, not both right? I didn't add comment in Zenbook or XPS, both are soldered/non-removable, if it helps
<JensGlathe[m]>
Okay I will comment it
luca020400 has joined #aarch64-laptops
<anthony25>
alexVinarskis[m]: it seems also overengineering to me to consider it as removable, but by removable I take it as: because it could technically be swapped with another card (and the manufacturer could easily do it in new revision) if you went to unsolder it
<anthony25>
But then the screen is removable, etc.
<alexVinarskis[m]>
hmmm true as well. Though then the same argument applies for almost all SoCs then with same pinout then?)
<alexVinarskis[m]>
i think the main debate here was about M2 cards specifically, since per my understanding the power sequencer is then onboard the m2 card, not on the motherboard, so one could swap entire power subsystem out, hence debate on if it even belongs to dtb then....
<anthony25>
Oh… OK I see
janrinze has joined #aarch64-laptops
<JensGlathe[m]>
My exoerience is otherwise, and it is odd. I have an Intel I226 NIC in the Snapdragon Dev Kit, but to reliably get it up I still need the wcn7850-pmu driver. This one does some interesting stuff re PCIe quirks when probing. Without it, no more than 30secs of NIC
<JensGlathe[m]>
And yes, the wcn7850 on the sddk is removable/replaceable, I have 2 port definitions in my dt (for disabling aspm for the i226). Works. Actually the only thing that reliably works.
<JensGlathe[m]>
slim 7x
<JensGlathe[m]>
oops, sry
hexdump0815 has joined #aarch64-laptops
<alexVinarskis[m]>
kuruczgy: on next-20250623 now, indeed no more freezes, but im getting frequent crashes/reboots that weren't there before...3rd one just now since the morning. Perhaps unrelated to the freezing problem, but overall it became less usable than before :0
ravikant_ has quit [Ping timeout: 480 seconds]
ungeskriptet has quit [Remote host closed the connection]
ungeskriptet has joined #aarch64-laptops
hexdump0815 has quit [Quit: WeeChat 3.8]
mani_s has joined #aarch64-laptops
<sgerhold>
JensGlathe[m]: For the Intel NIC, you should probably define the 3.3V supply with vddpe-3v3-supply like (&pcie5 in x1-crd.dtsi). If you don't hook the regulator up somewhere it will get disabled after 30 seconds
<JensGlathe[m]>
I tried that ofc. Several variants.
<sgerhold>
JensGlathe[m]: Is this some M.2 to pcie adapter?
ravikant_ has joined #aarch64-laptops
<JensGlathe[m]>
No. M.2 A+E card
<JensGlathe[m]>
It‘s getting pcie gen2x1 link, more than enough for 2.5GbE, so all is good
weirdtreething has quit [Remote host closed the connection]
weirdtreething has joined #aarch64-laptops
mani_s has quit [Remote host closed the connection]
hogliux has joined #aarch64-laptops
<hogliux>
deathmist: That's super interesting. kuruczgy: how much RAM does your slim 7x have (as you don't see the issue)? I have the 32 GB variant. Maybe it only occurs on the 32 GB variant?
<kuruczgy_>
hogliux: I also have 32GB RAM
<hogliux>
Hmmm Ok guess not. :-(
icecream95 has joined #aarch64-laptops
jglathe_angrybox has quit [Remote host closed the connection]
SpieringsAE has quit [Quit: SpieringsAE]
mani_s has joined #aarch64-laptops
icecream95 has quit [Ping timeout: 480 seconds]
ravikant_ has quit []
mani_s has quit [Remote host closed the connection]
weirdtreething has quit [Remote host closed the connection]
weirdtreething has joined #aarch64-laptops
hwpplayer1 has joined #aarch64-laptops
mani_s has joined #aarch64-laptops
mani_s has quit [Remote host closed the connection]
mani_s has joined #aarch64-laptops
jglathe_angrybox has joined #aarch64-laptops
<valpackett>
i'm still running next-20250612 and coming up on 6 days of uptime \o/
<valpackett>
still too early to conclude if i'm lucky right now or the bios update fixed the random freeze
<valpackett>
but it miiiiight've been the bios???
mani_s has quit [Remote host closed the connection]
<hogliux>
valpackett: Hmmm I've always updated to the latest BIOS as soon as they come out and kuruczgy is still on a very old BIOS
<hogliux>
valpackett: I'd be surprised if it is the BIOS - but who knows ¯\_(ツ)_/¯
<kuruczgy[m]>
Not sure why though, I do periodically run windows updates, seems it's just not updating the UEFI for me. Can try again though soon
<valpackett>
the changelog has only mentioned CVE fixes, so i should kinda be surprised too, but i'm beating my previous uptime record by almost 2 days right now..
<hogliux>
kuruczgy: same for me. Windows won't update it if the EFI parition was altered in any way, I think, not sure. I always install the updates from linux following these instructions:
<hogliux>
valpackett: I'm keeping my fingers crossed, but I had a run for almost a month without the issue
<hogliux>
valpackett: just randomly
<valpackett>
well then it might just be luck
<hogliux>
valpackett: Your description of it being anti-correlating with high load definitely fits to what I experience as well
<valpackett>
yeeah. i thought it might've been related to low power states but then i ran with the performance governor and it did freeze eventually
<hogliux>
valpackett: for me it happens a lot in visual studio code while I'm just writing code - but then again I use Visual Studio Code almost 90% of time
<hogliux>
valpackett: another hypothesis (I have many conflicting ones because I'm desperate by now :-D) is that it is related to GPU
<valpackett>
oof having to screw with windows update cabs.. i'm sure glad mine is not a lenovo :p
<hogliux>
valpackett: Visual studio code opens a lot of tooltip windows and it seems somewhat correlated to that
<hogliux>
valpackett: I can get it to happen much more often if I switch a lot between a virtual console and back to Wayland
<hogliux>
valpackett: also it seems to happen every now and then when I detach a chrome tab and make it a new window
<valpackett>
huh, mine have been just completely random, like literally while moving the mouse over nothing in particular
<hogliux>
valpackett: I've also have it happen when I wasn't even touching the machine. But when it happened I got a notification on my phone at roughly the same time which would have also opened a notification window on the laptop
<valpackett>
and yeah happened to me once when afk at night, just came back to a rebooted machine
<hogliux>
valpackett: but maybe moving the mouse might have triggered a tooltip window to open. The tooltip windows doesn't ever open as it crashes before then. Anyways just a theory. Probably not very solid. I've blamed the SSD, ESD, GPU, BIOS etc. by now. :-)
<valpackett>
lol, no, no tooltips here.
hwpplayer1 has quit [Read error: Connection reset by peer]
<kuruczgy[m]>
robclark: I asked in the wlroots channel, they said that they are aiming to use the upcoming "drm color ops" interface to supersede the current gamma adjustment protocol, and supporting CTM is not a priority.
<kuruczgy[m]>
What do you know about this interface, is freedreno going to support it (on X1E)? (I did not find any reference to this interface on lore.kernel.org, not sure where it's being developed/discussed.)
<steev>
isn't that the DRM_COLOROP_* stuff?
<steev>
i think it's on wayland side, not kernel?
hogliux has quit [Quit: Leaving]
mani_s has joined #aarch64-laptops
<robclark>
kuruczgy[m]: I'm not sure the odds are high for color ops support on current devices, the display team had some objections.. maybe lumag knows more
mani_s has quit [Remote host closed the connection]
sally has joined #aarch64-laptops
sally has quit []
sally has joined #aarch64-laptops
sally has quit [Remote host closed the connection]
<kuruczgy[m]>
I just applied them using b4 (which should have also applied the tagged prerequisite patches automatically), but when booting the screen goes black after initramfs, and does not come back even if I type my LUKS password blind.
sally has joined #aarch64-laptops
sally has quit [Remote host closed the connection]
jhovold has quit [Ping timeout: 480 seconds]
<sgerhold>
kuruczgy[m]: doesn’t work for me. You need to drop an incorrectly added assigned-clock-parents line in x1e80100.dtsi &mdss_dp3 (this will fix the screen) and add some definitions for mst
<sgerhold>
But then just errors when connecting a mst hub
<sgerhold>
I had the same problem on v1. Given the review feedback I guess it’s simply broken with usbc and works only with direct dp
<kuruczgy[m]>
sgerhold: Do you think the authors know that it's broken with usb-c, will a v3 potentially fix this, or should we let them know on the mailing list that we are testing this on X1E and seeing these issues?