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
<steev>
robclark: will do, i'm assuming just install apitrace, then run something like apitrace trace --api gl prismlauncher ? or should i call the minecraft binary it installs directly?
<robclark>
hmm, not too familiar with the launcher.. basically `apitrace trace` just LD_PRELOADS a thing and if the launcher doesn't interfere with that it should probably be fine.. but if you can run the binary directly that might be better
lun[m] has joined #aarch64-laptops
<steev>
ah, it looks like it does :/
malvi[m]1 has joined #aarch64-laptops
freekurt[m] has joined #aarch64-laptops
pz[m] has joined #aarch64-laptops
KhazAkar has quit []
DanaG has quit [Remote host closed the connection]
szclsya[m] has joined #aarch64-laptops
phire has quit [Ping timeout: 480 seconds]
strongtz[m] has joined #aarch64-laptops
sally[m]123 has joined #aarch64-laptops
hexdump01 has joined #aarch64-laptops
hexdump0815 has quit [Ping timeout: 480 seconds]
phire has joined #aarch64-laptops
<jbowen>
Has anyone in here tried to play with Fedora on the X13s?
iivanov has joined #aarch64-laptops
<steev>
i think maybe dgilmore
<steev>
or maybe he only has the c630
<dgilmore>
I have a x13s and a c630
<dgilmore>
I haven't tried the c630 in awhile
<dgilmore>
There are some cludges you need to do to get Fedora running.
iivanov has quit [Remote host closed the connection]
<jhovold>
Should not show up in 6.6 unless someone has backported the broken commits that triggered it though...
<HdkR>
From the discussion yesterday, the WD SN770M 2TB is single-sided, so it should work in the X13s. I just got some in for testing.
<Jasper[m]>
HdkR: Nice!
laine has quit [Remote host closed the connection]
jenneron[m] has joined #aarch64-laptops
resuenehparg[m]1 has joined #aarch64-laptops
KhazAkar has joined #aarch64-laptops
<neobrain>
jhovold: oh interesting. I can try reverting that one locally on my 6.7 build to see if that helps (because 6.7 seems to be broken even worse, but with the same message)
AlexMarty[m] has quit [Ping timeout: 480 seconds]
pz[m] has quit [Ping timeout: 480 seconds]
lun[m] has quit [Ping timeout: 480 seconds]
publicdiscourse[m] has quit [Ping timeout: 480 seconds]
shjim[m] has quit [Ping timeout: 480 seconds]
sally[m]123 has quit [Ping timeout: 480 seconds]
jenneron[m] has quit [Ping timeout: 480 seconds]
harvestz[m] has quit [Ping timeout: 480 seconds]
ArtyomK[m] has quit [Ping timeout: 480 seconds]
sz3m3k[m] has quit [Ping timeout: 480 seconds]
Las[m] has quit [Ping timeout: 480 seconds]
Nick[m]123456 has quit [Ping timeout: 480 seconds]
akawolf[m] has quit [Ping timeout: 480 seconds]
harvests[m] has quit [Ping timeout: 480 seconds]
EnigmaCurry[m] has quit [Ping timeout: 480 seconds]
malvi[m]1 has quit [Ping timeout: 480 seconds]
szclsya[m] has quit [Ping timeout: 480 seconds]
aigotchi[m] has quit [Ping timeout: 480 seconds]
emily[m]1 has quit [Ping timeout: 480 seconds]
ajhalaney[m] has quit [Ping timeout: 480 seconds]
wiizzard has quit [Ping timeout: 480 seconds]
owc[m] has quit [Ping timeout: 480 seconds]
Guest7887 has quit [Ping timeout: 480 seconds]
anarchron has quit [Ping timeout: 480 seconds]
Jasper[m] has quit [Ping timeout: 480 seconds]
hlr[m] has quit [Ping timeout: 480 seconds]
resuenehparg[m]1 has quit [Ping timeout: 480 seconds]
strongtz[m] has quit [Ping timeout: 480 seconds]
freekurt[m] has quit [Ping timeout: 480 seconds]
patzek[m] has quit [Ping timeout: 480 seconds]
iivanov has joined #aarch64-laptops
rfs613- has joined #aarch64-laptops
rfs613 has quit [Ping timeout: 480 seconds]
<neobrain>
oh hmm looks like the two lines added by the patch are already gone in my rc2 tree
<neobrain>
I can't actually find any of the patches in the kernel tree, so it looks like I'm misunderstanding which of the patches is the regression
<steev>
and you didn't order me one hdkr smh
averyfreeman[m] has joined #aarch64-laptops
Nao[m] has joined #aarch64-laptops
<HdkR>
steev: Sadly you'll need to buy one yourself. What a shame
Guest7819 has quit [Quit: WeeChat 4.1.1]
<steev>
easier said than done.... so many results are SN770 and not the SN770M (thanks for reusing model numbers WD!)
<steev>
looking like best buy is my only option for a 2TB
<HdkR>
Yea, It's best buy exclusive atm
<HdkR>
Amazon is getting it in January or February
<jhovold>
neobrain: commit bfcc3d8f94f4 ("drm/msm/dp: support setting the DP subconnector type") introduced the regression
<jhovold>
the link I posted was to the fixes
<jhovold>
you can either apply those or revert the offending commit, but again, this should only be needed 6.7
<jhovold>
unless opensuse backported the offending commit
<jhovold>
steev: just sorted out that pops and clicks backport:
<jhovold>
Turns out it had resulted in a bad merge in mainline too
<steev>
jhovold: aha! thank you!
<neobrain>
jhovold: managed to boot 6.7 with that patch reverted :)
baspar[m] has joined #aarch64-laptops
<neobrain>
Looks like that was a separate issue than my 6.6 problem. The regression completely broke 6.7 booting, but both 6.6 and (fixed) 6.7 still only manage to boot in 1 out of ~4 attempts
iivanov has quit [Remote host closed the connection]
<agl>
jhovold: I have set everything manually. Works perfectly fine. When the volume is at 100%, the sound is distorted. I have it set to 62% there it is clear and crisp.
matthew[m]12 has joined #aarch64-laptops
<jhovold>
neobrain: can you reproduce that with mainline (or my wip branches) to rule out anything opensuse specific?
<jhovold>
also, could post post the oops somewhere?
<jhovold>
and are you using an external display?
<jhovold>
agl: sounds like you may not be using the latest settings then, 100% is not very loud and no longer distorted here
<jhovold>
you may also need to remove the old alsa state after updating the ucm config
<jhovold>
(and prevent it from being recreated on reboot)
<neobrain>
jhovold: will try and see if I can get a mainline kernel built. Not sure how to get the oops log, should `journalctl -k -b-1` normally include it?
<neobrain>
welp looks to be resetting too early to make it into journalctl either way
<neobrain>
no luck with kdump either. Looks like I'll just have to try mainline first
Nei[m] has joined #aarch64-laptops
<jhovold>
neobrain: i thought maybe had a photo or something of the stack trace?
<jhovold>
and do you have an external display connected or not when this happens?
<neobrain>
jhovold: nope, no external display. For clarity, what I see happen is the "Loading Linux<...>; Loading initial RAM disk" messages are displayed on the screen, then the display turns off and the device auto-resets
<neobrain>
(without the quiet/silent options, it's printing 3 more messages about the EFI stub, but no difference otherwise)
<jhovold>
neobrain: looks good, except possibly for that dash after iommu.strict=
<neobrain>
Ah yes, just a typo since I had to manually copy it
<agl>
steev: Thank You!
<jhovold>
neobrain: you could try to add all the display dependencies to, or even better remove them from, the initramfs so that you can see what's going on when the crash happens
<jhovold>
i assume you only have some of them, which could cause the screen to be cleared and you won't get a console back until the missing modules have been loaded from your rootfs
<jhovold>
haven't heard of anyone having such issues and people have been using 6.6 (rcs) for months now
DocGalaxyBlock[m] has joined #aarch64-laptops
Sobek[m] has joined #aarch64-laptops
<neobrain>
the kernel-vanilla package (6.6) shows the same behavior, though it does manage to print this message to screen before reset: of_icc_get_by_index: invalid path = -517
<neobrain>
But that message is also in my dmesg when it does boot successfully
<neobrain>
Hacking up the initrds is a bit over my head I'm afraid
nscnt[m] has joined #aarch64-laptops
iivanov has joined #aarch64-laptops
<jhovold>
sounds like you may be missing some interrconnect module in your initramfs that causes that probe deferral (-517)
<jhovold>
if you can just prevent the "msm" drm from being included in your initramfs somehow, that should give you 30s of efi console which may be enough to see what goes wrong
<jhovold>
not sure how opensuse generates its initramfs though
<neobrain>
Figured out how to do that using dracut, but apparently opensuse is really weird and won't display that efi console even if I prevent the module from being included :D
<neobrain>
Found a related bug report though that seems to add "clk-rpmh dispcc-sc8280xp gcc-sc8280xp gpucc-sc8280xp nvmem_qcom-spmi-sdam qcom_hwspinlock qcom_q6v5 qcom_q6v5_pas qnoc-sc8280xp pmic_glink pmic_glink_altmode smp2p spmi-pmic-arb leds-qcom-lpg" to the list of modules for x13s specifically. Didn't seem to help for me but sounds like people are working on it
mynery[m] has joined #aarch64-laptops
NomadNaomie[m] has joined #aarch64-laptops
<jhovold>
neobrain: has your config got CONFIG_FB_EFI?
<jhovold>
the actual list of modules needed in initramfs depends on the config, and so far I think most people build the gcc clock controller driver into the kernel
<jhovold>
you could try building with johan_defconfig and if that works start narrowing down what config options / module may be involved here
<jhovold>
or just modify the opensuse defconfig to compile those drivers in, e.g. QCOM_CLK_RPMH and SC_GCC_8280XP
<neobrain>
jhovold: ah, no... CONFIG_FB_EFI is not set
<javierm>
neobrain: I think that opensuse disables it and enables DRM_SIMPLEDRM instead ?
<neobrain>
javierm: yup, looks like it
<javierm>
neobrain: you can also try booting with "iommu=off clk_ignore_unused pd_ignore_unused" in your cmdline
<neobrain>
no luck with iommu=off (which I added at the end, assuming that doesn't make a difference)
<neobrain>
I'll throw johan_defconfig on it next
<javierm>
neobrain: sorry, I missed that you shared your cmdline already
<javierm>
neobrain: I would remove quiet though
<javierm>
when I try to debug something, I want to be as verbose as possible :)
<neobrain>
yeah fair point
<neobrain>
How do I use the defconfig? if I throw it into the kernel tree and run "make oldconfig", it asks me about all the other options it doesn't set
<javierm>
neobrain: cp johan_defconfig .config && make prepare modules_prepare && make Image modules
<neobrain>
then make modules_install && make install like normally?
<javierm>
yeah
<neobrain>
it still prompts me for the other settings... the kernel versions don't exactly match up, but it's asking for really silly stuff like COMPILE_TEST and WERROR
<steev>
put it in arch/arm64/configs and then make johan_defconfig
<neobrain>
ah, now we're talking :)
<javierm>
that's another option too :) I think the difference is that the default values are picked for the undefined symbols?
davidebeatrici[m] has joined #aarch64-laptops
<neobrain>
Looks like I'm not really getting anywhere with this sadly... I think I'll sit it out for a few weeks to see if the opensuse folks are already onto this
<neobrain>
On the plus side I'm slightly more comfortable dealing with kernel things now, so that's good I guess :D
<broonie>
neobrain: make olddefconfig might be what you're looking for here?
iivanov has quit [Read error: Connection reset by peer]
quinine has joined #aarch64-laptops
<jbowen>
Thank you, dgilmore!
<dgilmore>
jbowen: you're welcome. I used my Arm desktop and tweaked the disk image to boot from USB. Then manually installed onto the NVMe drive. I am hopeful that we can get things so Fedora 41 will work out of the box
sporos11[m] has joined #aarch64-laptops
* jbowen
crosses fingers
<mynery[m]>
I am trying to follow https://github.com/ironrobin/archiso-x13s/wiki/EndeavourOS-Tutorial and I get pretty far and get to a grub, but I cannot really boot the system. I added the grub settings from fedora, but I just get "generating empty DTB" followed by "exiting boot services"
<mynery[m]>
huh, not sure this is the issue. I do have a / and a /boot with them correctly labeled in /etc/fstab and the generated grub.cfg seems fine.
<mynery[m]>
it references /vmlinuz-linux and /initramft-linux.img both present in the mounted /boot and the root partition is the correct uuid
<mynery[m]>
i will give it a go, but i have to check how to not overwrite it in later config generations if that's the issue
<mynery[m]>
that doesn't seem to be it
cenunix[m] has joined #aarch64-laptops
konradybcio has joined #aarch64-laptops
<mynery[m]>
no worries, it's harmless and still better than nothing :)
Bioxvirizm-x13s[m] has joined #aarch64-laptops
<Bioxvirizm-x13s[m]>
But your configs do look workable. i compare them to mine.
<Bioxvirizm-x13s[m]>
Maybe I can provide some of my own configs so I can compare?
<mynery[m]>
i sadly have no idea how i would attempt to find more information about it. was your suggestion a shot in the dark or is the empty dtb some form of hint?
<Bioxvirizm-x13s[m]>
And you're doing everything according to the manual?
<Bioxvirizm-x13s[m]>
I have installed on my laptop 2 times according to this manual, and the only place where I had a mistake was when I mixed up disks, which I wrote about earlier. So I recommend you to follow the manual very carefully with ironrobin repository connection.
<mynery[m]>
as far as i am aware. i tried using the plain archinstall script before and that's where i got the partitioning from, but i scraped that, because it was too much a hassle cleaning that up again from the non-x13s packages
<Bioxvirizm-x13s[m]>
хорошь тупить=)
<Bioxvirizm-x13s[m]>
mynery[m]: I don't know what you're talking about.
iivanov has quit [Read error: No route to host]
<mynery[m]>
i will try getting that file, which apparently can be fetched from some suse package. if that doesn't work, i will retry
<mynery[m]>
putting the file there and referencing it via devicetree command in grub _did_ work. i can boot now
LikeNeosMatrix[m] has joined #aarch64-laptops
danielt has joined #aarch64-laptops
emily[m]1 has joined #aarch64-laptops
agl has quit [Ping timeout: 480 seconds]
<steev>
yes, without a devicetree it won't boot; but you really should be using the one in your kernel, which is in arch/arm64/boot/dts/qcom/ after you've built it
anarchron has joined #aarch64-laptops
wiizzard has joined #aarch64-laptops
moria has joined #aarch64-laptops
moria has quit [Remote host closed the connection]
moria has joined #aarch64-laptops
svarbanov_ has quit [Remote host closed the connection]