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
louist103 has joined #aarch64-laptops
<louist103>
I'm trying to build the device tree for the c630 with make -j sdm850-lenovo-yoga-c630.dtb but it just gives `make[2]: *** No rule to make target 'arch/arm64/boot/dts/sdm850-lenovo-yoga-c630.dtb'. Stop. make[1]: *** [/usr/src/linux-6.6.13-gentoo/Makefile:1384: sdm850-lenovo-yoga-c630.dtb] Error 2 make: *** [Makefile:234: __sub-make] Error 2`
<louist103>
I have dtc installed on the machine and already built the kernel with `genkernel`
<Jasper[m]>
throw a qcom/ infront of the dtb name
<Jasper[m]>
It mentions the path invalid in the error
<Jasper[m]>
* It mentions the invalid path in the error
<louist103>
So that fixes the build part but when I try to do dtbs_install I get a similar error:
<louist103>
make[3]: *** No rule to make target '/boot/dtbs/6.6.13-gentoo-arm64/arm/foundation-v8.dtb', needed by '__dtbs_install'. Stop.
<louist103>
and thats from: make -j dtbs_install qcom/sdm850-lenovo-yoga-630.dtb with or without the qcom/..... part
<louist103>
Oh I just needed to run `make dtbs`
<louist103>
But I don't really get why I need to still add the dtb manually to the grub.cfg
<louist103>
Well even after adding the dtb I still can't boot past "Determining root device (trying UUID=*long uuid*"
<louist103>
And there is no working keyboard or USB, and UFS is enabled and in the initramfs
<Nios34[m]>
travmurav: hexdump0815: I read about dtb thing yesterday but I've not quiet understood it yet. Can you point out how to do the cleanup thing?
hightower4 has joined #aarch64-laptops
hightower3 has quit [Ping timeout: 480 seconds]
mcbridematt has quit [Quit: Leaving]
<dgilmore>
robclark: rc7 does not allow hotplug to work here
mcbridematt has joined #aarch64-laptops
<robclark>
dgilmore, does it have `Revert "drm/msm/dp: use drm_bridge_hpd_notify() to report HPD status changes"`
<dgilmore>
robclark: I was told it made it into rc7
<robclark>
if it does, then AFAIU hpd should at least not be worse than it was prior to v6.8-rc.. idk if there might be other issues. It has pretty much been wfm this whole time, but ask on #freedreno (display folks seem not to be here) or file gitlab issue.. I've not been having bandwidth to follow display side of things as much but lumag or abhinav might have ideas
<dgilmore>
definitely is there
hexdump01 has joined #aarch64-laptops
hexdump0815 has quit [Ping timeout: 480 seconds]
KREYREN__ has joined #aarch64-laptops
KREYREN_ has quit [Remote host closed the connection]
KREYREN__ has quit [Remote host closed the connection]
louist103 has quit [Remote host closed the connection]
<travmurav[m]>
louist103: It might be possible that some important drivers are missing in the kernel config but to sanity check, you can probably boot with `earlycon=efifb keep_bootcon` and check if the first lines say "Machine model: Lenovo Yoga C630" so you know the kernel has picked up the dt
mani_s- is now known as identify
identify is now known as mani_s
iivanov has joined #aarch64-laptops
iivanov has quit [Quit: Leaving...]
iivanov has joined #aarch64-laptops
jhovold has joined #aarch64-laptops
martiert has quit [Quit: WeeChat 4.2.1]
martiert has joined #aarch64-laptops
<konradybcio>
jhovold so, i actually hit the hard crash on 6.8-rc7.. as usual, it happened randomly when i tried opening firefox, no logs at all
<konradybcio>
and trackpoint&touchpad buttons died again.. no ec related patches whatshowever
<konradybcio>
sad i'll have to overdischarge it again probably..
<jhovold>
konradybcio: ah, it'd during use, I thought you said you hit a reset on boot
<konradybcio>
previously yes
<konradybcio>
this time, during runtime
<jhovold>
we know that venus can trigger a reset (e.g. on ffmpeg transcode as I've reported to you), perhaps related to that
<jhovold>
so quite possibly unrelated to whatever you hit on boot, was that with rc7?
<jhovold>
please try to track down that known venus reset, which has a 100% reproducability using ffmpeg
<jhovold>
that should be higher prio than any performance/thermal work etc
<jhovold>
soemthing is likely accessing a register with clocks off, should be easy to fix
<jhovold>
konradybcio: hmm, and we also a bug in the efivar implementation that can trigger a reset, perhaps you hit that on boot depending on what your distro does
<jhovold>
qzed: have you had time to look into the efivarfs reset?
<jhovold>
i believe bamse was able to trigger that after minute or two by just reading out a variable through efivarfs in a loop
<konradybcio>
i now tried to umount efivarfs and the laptop died..
<jhovold>
konradybcio: works fine here twice in a row fwiw
ungeskriptet has joined #aarch64-laptops
<jhovold>
shouldn't be any TZ calls on umount IIRC
<qzed>
Sorry, I'm still busy with work. A deadline got extended from 1st to 15th, so hopefully after that.
<jhovold>
cool, thanks
<qzed>
If it's memory related, I think there should be older versions of the patches where I (pre-?)allocated proper dma memory, so maybe those could be adapted
<konradybcio>
jhovold what's the reproducible ffmpeg command?
<konradybcio>
i just compiled ffmpeg-git and ran ffmpeg -c:v h264_v4l2m2m -i bbb.mp4 out.mp4
<jhovold>
qzed: yeah, it seems like something like that may be needed -- do you know if that is done with the proposed new scm interface which seemed to make the issue go away?
<jhovold>
if so, we should merge a minimal fix for that so we don't have to depends on that series (which I think has been rejected for now at least)
<qzed>
I haven't looked over the recent patches in detail, but as far as I understood it specifically allocated memory for this.
<konradybcio>
jhovold so it looks like only the nv12 part is problematic.. this way i indeed get a crash
<konradybcio>
the default is yuv420p
ungeskriptet is now known as Guest2111
ungeskriptet has joined #aarch64-laptops
<konradybcio>
travmurav: any chance you could run the ffmpeg command that jhovold posted on 7180 on a 6.8-ish kernel ^?
<travmurav[m]>
could do in a couple of moments
<konradybcio>
thanks
Guest2111 has quit [Ping timeout: 480 seconds]
<_[m]123>
today, from resume by laptop lid close - no wifi no external screen, on reboot no screen on 6.8.rc7 and 6.7 through dock - had to change hdmi cable port on dock to get external screen, didn't find anything too meaningful in dmesg
<jhovold>
_[m]123: sounds like a problem with you dock if it doesn't come back after reboot
<jhovold>
dock or monitor
iivanov_ has joined #aarch64-laptops
iivanov has quit [Read error: Connection reset by peer]
<konradybcio>
jhovold: do we know whether this specific nv12 command worked on 6.5 or whatever, or should i check that?
<jhovold>
i don't remember, but my guess is that it has never worked
<jhovold>
just checked the logs; it was Segfault[m] that reported this on 2024-02-07
Guest1968 has quit [Remote host closed the connection]
craftyguy has joined #aarch64-laptops
<konradybcio>
jhovold, so i spun up sm8250 (a gen earlier) and running the same command segfaults instead of crashing
craftyguy has quit [Remote host closed the connection]
<konradybcio>
on pure next that is, let me now check against my patches that are on your branch
craftyguy has joined #aarch64-laptops
craftyguy has quit [Remote host closed the connection]
craftyguy has joined #aarch64-laptops
<konradybcio>
even on your branch, 8250 only segfaults ffmpeg
<konradybcio>
jhovold: cccccombo.. i just got a random runtime reboot followed by a failed boot
<konradybcio>
i'll try disabling efivarfs in kernel and running that..
<konradybcio>
or rather, i'll remove x13s from the qseecom whitelist
<travmurav[m]>
jhovold: konradybcio hm does that ffmpeg command supposed to work on 6.7? I was trying to sanity check it first but I think ffmpeg just hung now without doing anything...
<konradybcio>
travmurav: ffmpeg hung or the laptop did?
<travmurav[m]>
just ffmpeg
<travmurav[m]>
had to kill -9 it
<konradybcio>
ffmpeg --version | grep -i v4l2?
<travmurav[m]>
(it had no messages and didn't do any io)
<konradybcio>
and.. i assume you do have a big_buck_bunny_720p_h264.mov?
<travmurav[m]>
yes, had to download it xD
<konradybcio>
could you recheck the same atop jhovold/linux : johan/wip/sc8280xp-v6.8-rc7?
<travmurav[m]>
copy/copy works fine
<travmurav[m]>
well this is 6.7.0 as i said, not sure if it's /expected/ to be broken maybe?
<travmurav[m]>
(wanted to have a baseline)
<konradybcio>
that's what we're trying to figure out
<konradybcio>
8250 segfaults on this branch, 8280 just dies
<travmurav[m]>
mhm
<travmurav[m]>
well I've already built plain rc7 (no patches), do I need some extra series?
<konradybcio>
hm, not really, i think the 8250 test was enough to conclude my venus changes (found on jhovold's branch) don't cause the hard reboot alone
<konradybcio>
i'm wondering if this is caused by the hardcoded one-capabilities-table-for-all-socs...
<travmurav[m]>
k let me install the new kernel and see if it hangs the same
<travmurav[m]>
well, same thing - ffmpeg hangs
<travmurav[m]>
nothing in dmesg
<konradybcio>
hmm takes makes no sense xD
<travmurav[m]>
don't see any live from the process
<travmurav[m]>
tbh I think I never ever saw venus encoder working
<konradybcio>
you'll need gst-plugins-bad or something similarly named in your distro though
<konradybcio>
and plugins-good iirc
<travmurav[m]>
well fwiw $ ./ffmpeg -c:v h264_v4l2m2m -i ../../big_buck_bunny_720p_h264.mov -c:a copy -f null - works for me on -rc7 but using an encoder doesn't seem to work at all
<travmurav[m]>
and I guess ~6-7x decode speed for venus is quite nice compared to 35x with 100% cpu use
<konradybcio>
35? it's 3x on X1C lol
<jhovold>
konradybcio: regarding the resets you keep seeing with rc7; I assume you've dropped your thermal patches to rule those out?
<travmurav[m]>
konradybcio: just h264 decode into void
<travmurav[m]>
(note no -cv before input to force hw decode)
<konradybcio>
jhovold no, i've only done so now, will run thermal-patch-less for some time..
<jhovold>
konradybcio: I usually don't build the full defconfig, but I could also shave off a minute by just playing with the thermal poll parameters to reduce the frequency oscillation
<jhovold>
when I played with that a few months ago
<jhovold>
but my notes said I went from 14m14 to 13m18 with the arm64 defconfig
<jhovold>
i see now that you seem to say johan_defconfig takes 5 minutes to build?! I build that in 2.5 minutes here...
<jhovold>
oh, yes, you use that crappy clang compiler... i use gcc
<travmurav[m]>
hm nice seems like there is a lot of thermal zone spam on -rc7 for me now...
<konradybcio>
hm.. i have ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- LD=aarch64-linux-gnu-ld
<konradybcio>
and i now realized CROSS_COMPILE looks funny
<jhovold>
ok, i don't have time to look at this now, but weird that your build takes twice as long
<jhovold>
bamse was using clang and got much longer build times, perhaps your doing something else
iivanov__ has joined #aarch64-laptops
iivanov_ has quit [Ping timeout: 480 seconds]
iivanov__ has quit []
iivanov_ has joined #aarch64-laptops
<jhovold>
konradybcio: also makes sure your machine is at the same temperature when doing such comparions, otherwise the second run is always goig to take longer due to throttling kicking in sooner
<konradybcio>
yes i did wait for it to settle down
<konradybcio>
which took more than i expected
<jhovold>
good
<jhovold>
takes forever
<jhovold>
but sounds promising that the thermal_allocator governer is able to reduce the oscillation as intended
<jhovold>
with the thermal dt properties in place (otherwise it just fails to throttle at all which is quite broken)
<konradybcio>
yeah and it requires that you manually set the power_allocator thermal governor
<konradybcio>
which feels quite backwards
<konradybcio>
perhaps it could be altered such that when sustainable-power is found, power_allocator is chosen
<konradybcio>
similarly to how schedutil is chosen by default if EM properties are in place
iivanov_ has quit [Remote host closed the connection]
iivanov has joined #aarch64-laptops
<travmurav[m]>
konradybcio: hm do you say something wrt thermal-zones was changed since 6.7?
<konradybcio>
do you have CONFIG_CPU_FREQ_THERMAL and CONFIG_DEVFREQ_THERMAL?
<travmurav[m]>
and I assume it would expose them somewhere in hwmon/iio but I don't see them
<travmurav[m]>
both =y
<travmurav[m]>
I'm using pretty much chromeos defconfig for 7c fwiw
<konradybcio>
guess it's time to pr_err-bomb it.. then
<travmurav[m]>
<travmurav[m]> "and I assume it would expose..." <- meh i guess it also skips adding hwmon if thermal_zone is dead
<konradybcio>
well it failed to register so
<travmurav[m]>
pmic one failed to probe, tsens probed with no sensors afaict
<travmurav[m]>
as in, silently skipped all of them
<konradybcio>
"Failed to register thermal zone"
<travmurav[m]>
hm I guess I'm dumbing out a bit and you're right tsens tried to probe -> called register thermal zone -> it died -> tsens skipped the sensors (repeat for all sensors) -> driver probes with zero sensors
<travmurav[m]>
seems like it's something new in gov_power_allocator...
<travmurav[m]>
hm perhaps it was always broken but e83747c2f8e3 ("thermal: gov_power_allocator: Set up trip points earlier") added error checks to the thing that fails :/
<travmurav[m]>
eh
<travmurav[m]>
I guess it's because 7c has defined cooling-maps
<konradybcio>
so does 8280 with my patches
<travmurav[m]>
mhm
<konradybcio>
and the thermal zones pop up in sysf
<travmurav[m]>
hm no I think /all/ zones die not just the ones with maps
<travmurav[m]>
even those that are similar to what 8280 has :/
<travmurav[m]>
at least they have a different error between them
<travmurav[m]>
:/
<travmurav[m]>
well at least I think there is no other issues for me with rc7 afaict
KREYREN_oftc has joined #aarch64-laptops
echanude has joined #aarch64-laptops
KREYREN_oftc has quit [Remote host closed the connection]
KREYREN_oftc has joined #aarch64-laptops
KREYREN_oftc has quit [Remote host closed the connection]
KREYREN_oftc has joined #aarch64-laptops
KREYREN_oftc has quit [Remote host closed the connection]
KREYREN_oftc has joined #aarch64-laptops
KREYREN_oftc has quit [Remote host closed the connection]
KREYREN_oftc has joined #aarch64-laptops
hightower3 has joined #aarch64-laptops
KREYREN_oftc has quit [Remote host closed the connection]
KREYREN_oftc has joined #aarch64-laptops
echanude has quit [Ping timeout: 480 seconds]
hightower4 has quit [Ping timeout: 480 seconds]
echanude has joined #aarch64-laptops
KREYREN_oftc has quit [Remote host closed the connection]
<konradybcio>
jhovold: got another crash-on-boot, with your clean branch.. disabling efivars now..
<konradybcio>
also, i overdischarged the laptop and trackpoint&buttons came back..
KREYREN_oftc has joined #aarch64-laptops
KREYREN_oftc has quit [Remote host closed the connection]
KREYREN_oftc has joined #aarch64-laptops
<_[m]123>
I got a reset just while streaming dota
<_[m]123>
what keyword to serach for in journalctl -b ?
jglathe_volterra has quit [Remote host closed the connection]
<_[m]123>
> [ 6510.489302] [drm:dp_ctrl_link_train [msm]] *ERROR* max v_level reached
<_[m]123>
[ 6510.489360] [drm:dp_ctrl_link_train [msm]] *ERROR* link training #1 failed. ret=-11
<_[m]123>
still
<_[m]123>
just randomly
jglathe_volterra has joined #aarch64-laptops
<pstef>
I just got the x13s. When it comes to choosing the Linux distribution, does it matter whether it's Debian Sid, or Fedora Rawhide, or something else?
<Dantheman825[m]>
The laptop should handle rolling releases fine
<_[m]123>
I've also read at least 1 person running gentoo
<_[m]123>
and even the suse distro if I remember correctly
<steev>
nerdboy and someone else do gentoo
<steev>
the wiki for gentoo covers it pretty well, same for debian
<Dantheman825[m]>
So far, I haven’t touched anything beyond the Debian base. I considered Arch since it’s great on my main system, but I ended up just taking the convenient Ubuntu image, and settled in
<pstef>
Gentoo sounds tempting because I imagine I would be able to -funroll-loops and, to be more serious, -march=native
<enyalios>
yup its working great for me, i really like it because you dont have to use systemd and the rolling release model means i never have to reinstall
hightower4 has joined #aarch64-laptops
hightower3 has quit [Ping timeout: 480 seconds]
jhovold has quit [Quit: WeeChat 4.1.2]
jglathe_volterra has quit [Remote host closed the connection]
Amber_Harmonia_ has joined #aarch64-laptops
Amber_Harmonia has quit [Read error: Connection reset by peer]
djakov has quit [Remote host closed the connection]