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
<robclark>
fwiw, I don't have adsp fw in initrd and haven't had USB boot issues.. idk if that is confirmation
<colemickens>
I'm past usb boot issues afaict
<robclark>
\o/
<colemickens>
it's more than if I add firmware to my main system it gets auto-added to initrd. but I might make an option to change that, or to override what fw gets copied to initrd
<colemickens>
robclark: lol I fixed it by finding your irc messages from a week ago
<konradybcio>
dwc3-qcom is for your usb controller
<konradybcio>
controllers, plural
<konradybcio>
the phy modules you added are there so that these controllers and the usb device plugged into the connector can talk usb2
<FarchordSteveCossette[m]>
colemickens: See, I doubt the _sc8280xp modules are needed.... is it just me?
<FarchordSteveCossette[m]>
they seem to be for somethng else
<FarchordSteveCossette[m]>
My intuition tells me it's not needed for the x1e80100
<colemickens>
probably. I might try to iterate once I have an image that gets me to stage 2
<colemickens>
I decided to add a nixos option to override the firmware that get copied to initrd and need one piece of advice before I can rebuild
<colemickens>
the internet here is atrocious though
<FarchordSteveCossette[m]>
ahhh
<FarchordSteveCossette[m]>
well wifi works here. Slowly, but hey it works!
<steev>
FarchordSteveCossette[m]: there's a patch(set?) that soemoen mentioned the other night that should help with that (they asked johan to pull it in to his tree, but no idea if he has yet)
<steev>
and, while the sc8280xp modules may not be needed, sometimes they are (as things often get added with what hardware they were initially added to the kernel with, as an example) and there may be some cross dependencies (iirc the webcam on the sc8280xp thinkpad requires sm8350 or something's video driver to work correctly)
<colemickens>
to be fair these are just the initrd available kernel modules too
<colemickens>
the rest from the defconfig are available once we pivot to root/stage-2
<colemickens>
so this really only needs to be strictly whats necessary for a success usb "boot" that far
<adamcstephens>
your work motivated me to dig into this again so that we could initialize the gpu fully in stage1.
<colemickens>
nice, I could maybe move more of this out of nixpkgs then into a localized hack here
<colemickens>
oh the symlinkjoin and then overwrite /lib thing is cute too
<colemickens>
slick
echanude has quit [Ping timeout: 480 seconds]
<FarchordSteveCossette[m]>
btw, I've just done some tests, seems the qcom_q6v5_pas causes the drives to get reset, and causes the system to just go bonkers
<FarchordSteveCossette[m]>
so I don't know if there's a specific time where I can load it.... but the modules.load.d ain't it
<FarchordSteveCossette[m]>
or modules.conf.d w/e
<FarchordSteveCossette[m]>
but im gonna go get ready for bed, tty tomorrow
<colemickens>
interesting, I have that one in my initrd and I'm getting to our rootfs/stage-2
<steev>
the only way i could see it working is loading it before pivoting so the usb is re-inited first?
<steev>
while still in the initramfs
<colemickens>
possible.
<colemickens>
does the _pas thing need fw though?
<colemickens>
if so, I have the qcom fw disabled completely in the images I've gotten to pivot
<steev>
it's part of the remote procs
<colemickens>
that will change as soon as this horrid wifi does its job
<colemickens>
steev: I'm not 100% smart enoug to know if that means it needs fw or nnot
<colemickens>
probably not 90% either
<steev>
so, the mbn files are "firmware" but they're also kinda more than that
<steev>
originally it was modem firmware, but now it's anything that runs on the hexagon processors (remote procs)
<steev>
/usr/lib/firmware/qcom/sc8280xp/LENOVO/21BX/qcadsp8280.mbn: ELF 32-bit LSB executable, QUALCOMM DSP6, version 1 (SYSV), statically linked, no section header
<steev>
they are signed with a per device (probably per OEM device) key
<FarchordSteveCossette[m]>
Now that's what I can proprietary software
<steev>
there has definitely been some hexagon work out there
<robclark>
I think mbn (basically an elf file) is used wherever there is signing invovled
<robclark>
zap fw is most defn not something that runs on dsp.. it is basically signed bit of sqe fw that contains some embedded shaders and sqe code to setup draw/etc to clear gpu state (for windows/android it is used to clear gpu state when transitioning from secure/protected mode to normal mode, to avoid leaking any of that precious protected content)
<colemickens>
welp, I'm pretty sure blanket removing the udev rules broke my usb boot
<colemickens>
so I think I'm back to hoping one of you sleuths out the bad kernel module, or it just fixed in johan/upstream trete
<colemickens>
:(
<colemickens>
I guess I can force load all of the initrd modules I'm making available. lol.
<travmurav[m]>
Hi! I want to collect some smbios info for woa laptops currently in circulation, if you have one running linux, could you upload the output of "sudo fwupdtool hwids" for me? I'm particularly interested in devices available in linux-next (so vivobook and yoga)
<travmurav[m]>
Also your co-developed-by if you want to be attributed :)
<travmurav[m]>
I already have x13s and aspire1
<travmurav[m]>
robclark: I think you have a yoga 7x; Farchord (Steve Cossette) you have a vivobook
<travmurav[m]>
also maybe steev since iirc you have c630, if it still works?
<steev>
i do have a c630, and a flex5g
<travmurav[m]>
oh flex5g would be nice to get too then
<travmurav[m]>
heh, same board, with x13s one could have 21bx and 21by
<travmurav[m]>
Thanks!
<travmurav[m]>
I want to build a database for https://github.com/TravMurav/dtbloader use (and possibly anyone else who may want to use chids for anything like that, seems like no one wants to agree how to solve this problem nowdays, just sitting in analysis paralysis)
<robclark>
so I have the "vibe" that with oled panels, there isn't so much multi-src.. not sure what else would trigger a different board-id
<robclark>
travmurav[m]: thx for pushing this fwd, I think it is the best way to make these things look "normal" to an OS vendor
<robclark>
(I might be biased but I've also spent plenty of time on the "OS vendor" side of things)
<travmurav[m]>
yeah I also kinda agree that we should try to manage dtb out-of-band from the OS
<robclark>
+1
<robclark>
I hope someone can be convinced to work on the fwupd part of it to have a delivery mechanism for dtb ;-)
<travmurav[m]>
yes that would be the best
<steev>
travmurav[m]: https://paste.debian.net/hidden/f9852782/ - c630 it'll be a bit before i can find the flex5g (perhaps bamse has his nearby, i did see him post some sc8180x patches recently ;)
<steev>
which, i have apparently not updated since 6.7.0-rc7
<travmurav[m]>
heh
<steev>
hm, and now i can't see the patches that i swear i saw submitted the other day
hexdump0815 has joined #aarch64-laptops
<steev>
maybe i'll give 6.11-rc1 a spin and see whats up on it
hexdump01 has quit [Ping timeout: 480 seconds]
<travmurav[m]>
Pushed hwids files + generated code for all the devices, so only vivobook and few older devices missing compared to linux-next now, thanks again!
<travmurav[m]>
(I hoped I've put correct tags for co-authors)
laine_ has joined #aarch64-laptops
laine__ has quit [Read error: Connection reset by peer]
<steev>
mine looks correct enough. if you want the "steev" github account though, you have to use my gmail address (i don't care one way or the other)
<travmurav[m]>
tbh I didn't know there is a "steev" github account xD
<lumag>
and that repo maps to aarch64-linux.github.io site
jhovold has joined #aarch64-laptops
<lumag>
I'm not sure if I can accept PRs to github.io repo, but danielt definitely can
<lumag>
Distro installers are a completely separate topic. For example, for C630 + Miix630, which have good upstream support, I had to spend two weekends and several evenings to cook from-the-upstream Debian CD (and to get some bits and pieces to corresponding repos)
<lumag>
And I can not say the everything has been merged yet.
iivanov has quit [Quit: Leaving...]
iivanov has joined #aarch64-laptops
iivanov has quit [Remote host closed the connection]
iivanov has joined #aarch64-laptops
iivanov has quit []
iivanov has joined #aarch64-laptops
<jhovold>
colemickens: there's nothing to fix in the kernel here, you're all just dealing with distro issues, well and that quirky qcom adsp fw
<jhovold>
an alternative to not including the adsp fw in the usb boot initramfs, may be to blacklist the fw loader on the kernel command line:
<jhovold>
modprobe.blacklist=qcom_q6v5_pas
<jhovold>
no idea what that random udev rule is about, but it's certainly sounds fedora specific to me
<jhovold>
anonymix007[m]: haven't noticed any such issues with ath12k on x1e, so I'll wait and see what happens with that patch since it sounded like it needed to be reworked
<jhovold>
but thansk for the heads up
<anonymix007[m]>
jhovold: maybe it's just x86 then. You may try to reproduce it in the following way: create a big (1+ GiB) file, run http server (`python -m http.server 8080` will do), open that page on another device and try to download that big file. In a few seconds the download will stop and the WiFi card will become unresponsive
broonie has joined #aarch64-laptops
<FarchordSteveCossette[m]>
<travmurav[m]> "robclark: I think you have a..." <- Give me a bit of time and ill send this to you
<travmurav[m]>
hm also re-> collecting hwids for woa devices, I kinda forgot about it but I wonder if anyone would be able to share crd hwids too? Even though it's not retail available, would be nice to have everything
<FarchordSteveCossette[m]>
<travmurav[m]> "hm also re-> collecting hwids..." <- How do i get that?
<travmurav[m]>
nah someone with the crd (the red qcom x1e devkit laptop) would need to get the ids
<travmurav[m]>
Farchord (Steve Cossette): Thanks! What name/email should I put as co-authored-by?
<FarchordSteveCossette[m]>
Ah ok I think Jens Glathe has that
<FarchordSteveCossette[m]>
travmurav[m]: Steve Cossette (farchord@gmail.com)
<FarchordSteveCossette[m]>
Oh wait no jens has a devkit
<FarchordSteveCossette[m]>
Not the red laptop
<JensGlathe[m]>
not yet, I have WDK2023 and hopefully soon the SnapDragon Dev Kit
<travmurav[m]>
yes that's ms devkit you think of I assume, the red laptop is probably only available by some people who work with qcom directly
<travmurav[m]>
Pushed the s15, thanks again!
<FarchordSteveCossette[m]>
I guess ill have to build mesa on my raspberry pi lol
<JosDehaes[m]>
Why not on the vivobook? It boots no?
<FarchordSteveCossette[m]>
Yeah but i blacklisted kernel-headers
<FarchordSteveCossette[m]>
And it requires it
<JosDehaes[m]>
Ah
<FarchordSteveCossette[m]>
I mean, yes i could make it work on the laptop, but it’ll be easier on the orangepi, and less annoying
<FarchordSteveCossette[m]>
I decide to pick my battles 😂
<FarchordSteveCossette[m]>
huh seems the git rust needs rustfmt, interesting
juergh has quit [Quit: ZNC 1.8.2+deb2build5 - https://znc.in]
juergh has joined #aarch64-laptops
iivanov has quit [Remote host closed the connection]
iivanov has joined #aarch64-laptops
srinik has quit [Ping timeout: 480 seconds]
alpernebbi has quit [Ping timeout: 480 seconds]
srinik has joined #aarch64-laptops
echanude has joined #aarch64-laptops
echanude has quit [Quit: WeeChat 4.3.5]
<jhovold>
robclark, FarchordSteveCossette[m]: I remember seeing some odd fedora specific blacklisting that they claimed were needed to run fedora on the X13s:
<jhovold>
rd.driver.blacklist=msm
<jhovold>
perhaps you give it a try, sounds like it could be related to that udev rule issue you've identified
<FarchordSteveCossette[m]>
isn't msm needed?
<FarchordSteveCossette[m]>
but i can try
<FarchordSteveCossette[m]>
waiting for mesa git to finish building
<jhovold>
i think it only defers loading the driver somewhat
<jhovold>
some dracut fedora magic
<robclark>
hmm, I've never had to blacklist msm
<jhovold>
oh, and robclark and steev, there's no need to pass efi=novamap since a couple of years or so
<jhovold>
but you said you had to remove that udev rule, right?
<robclark>
ahh, ok
<jhovold>
perhaps the dracut blacklisting addresses the same underlying issue, just a guess
<FarchordSteveCossette[m]>
hmmm ill try it, im about to boot the laptop to update mesa anyway.
<FarchordSteveCossette[m]>
The only problem I have right now is with qcom_q6v5_pas driver
<FarchordSteveCossette[m]>
<jhovold> "perhaps the dracut blacklisting..." <- Nope… still fails, but… you know what? Restoring the udev rule gives very similar errors to when i try to run qcom_q6v5_pas…. Is it possible thats maybe the reason?
<jhovold>
have you tried blacklisting qcom_q6v5_pas when booting from usb as I suggested this morning?
<jhovold>
modprobe.blacklist=qcom_q6v5_pas
<FarchordSteveCossette[m]>
I just did and ya, i can boot with the udev rule in place
<jhovold>
that should be an alternate (better) way to be able to boot from usb, instead of removing the adsp fw
<FarchordSteveCossette[m]>
No battery status, but… shrug
<jhovold>
ok, so blacklisting qcom_q6v5_pas allows you to keep your default udev rules, when booting from usb?
<FarchordSteveCossette[m]>
jhovold: Yes
<jhovold>
good, you can always load the driver manually after boot, I mean this is just for usb installation right?
<FarchordSteveCossette[m]>
jhovold: No if i load the driver manually after boot, from the desktop environment, the system just dies
<jhovold>
robclark: did you have to remove that udev rule also when booting from nvme, or was that also just for usb boot?
<jhovold>
FarchordSteveCossette[m]: without any hint of why? machine just resets?
<FarchordSteveCossette[m]>
jhovold: I get alot of disk input/output error
<FarchordSteveCossette[m]>
Almost like if the usb got unplugged
<FarchordSteveCossette[m]>
And then i see kernel logs about the drive being plugged back in lol
<jhovold>
ah, sorry, yes, you can't load that one when running from usb, my bad
<jhovold>
you don't need to blacklist it once you have your system installed properly
<FarchordSteveCossette[m]>
Well it looks like the udev rule keeps trying to load it
<jhovold>
yeah, that disconnect issue is the whole reason why booting from usb on qcom hw is such a pain
<FarchordSteveCossette[m]>
So i either have to remove the udev rule or keep the blist lol
<jhovold>
blacklisting should be preferred, and allows you to have the adsp fw on disk
<FarchordSteveCossette[m]>
Yep
<jhovold>
ok, so, problem solved, it seems, enjoy running linux on your new toys :)
<FarchordSteveCossette[m]>
Btw i got mess updated but im still on llvmpipe is that normal?
<FarchordSteveCossette[m]>
Mesa
<jhovold>
i have a patch in my branch that overrides the gpu chip id, you probably need to revert that one if you want to try robclark's latest mesa changes for x1e
<FarchordSteveCossette[m]>
jhovold: Once sound is working yeah ill be able to think about getting an nvme ready for it
<FarchordSteveCossette[m]>
jhovold: Oh i installed from the actual mess git lol
<FarchordSteveCossette[m]>
Stupid autocorrect
<jhovold>
the gpu id hack allows you to run current mesa using zink
<jhovold>
current as in currently released
<FarchordSteveCossette[m]>
Ahh ok
<FarchordSteveCossette[m]>
Ah btw i tried to run the x1e80100 sound driver. Doesn’t work 😂 was worth a try!
* FarchordSteveCossette[m]
wonders why the ArchLinux image someone made him does have battery status when booting from USB, though....
<FarchordSteveCossette[m]>
Mind you that one was from the previous kernel you guys used
<jhovold>
perhaps there's some way to work around the disconnect, e.g. by using uuids and making sure the disconnect happens some time before mounting the rootfs
<jhovold>
I only need to boot from usb once when setting up a new machine, so sorting this out is pretty far down the prio list
<robclark>
jhovold: the chipid hack shouldn't really break things too much, it just means mesa will show the wrong gpu name
<jhovold>
ah, good to know!
<jhovold>
I should just be able to drop the zink override when switching to a later mesa then?
<robclark>
yeah.. but right now you need to build mesa from main since it missed the release branch
<jhovold>
which release do you think it'll be in?
<robclark>
24.3 later in the year
<robclark>
I guess I can ask about backporting but it isn't really a "fix". But arguably the fallback to zink doesn't really work smoothly
<JosDehaes[m]>
<FarchordSteveCossette[m]> "wonders why the ArchLinux..." <- > * <@farchord:matrix.org> wonders why the ArchLinux image someone made him does have battery status when booting from USB, though....
<JosDehaes[m]>
jhovold: Yes, I noticed too that your 6.11-rc1 branch doesn't have working battery status, while Abel Vesa's 6.10 base did. Even if I copy the qcom_battmgr.c from that branch, it still doesn't work
<JosDehaes[m]>
it shows a red empty battery in GNOME
<FarchordSteveCossette[m]>
Yup
<FarchordSteveCossette[m]>
With wifi working it's less important, but the system clock resetting to July 15th at midnight is also a bit annoying (OCD-wise) lol
alpernebbi has joined #aarch64-laptops
<JosDehaes[m]>
robclark: works fine here without the zink override (mesa main branch) much faster in glmark2 too
<robclark>
yeah, main has a7xx gl support.. that landed a week or so after the 24.2 branchpoint
<FarchordSteveCossette[m]>
JosDehaes[m]: I built mesa from main git (24.3.0) and I still show llvmpipe is that normal?
<JosDehaes[m]>
no
<jhovold>
JosDehaes[m]: battery works fine here on the crd, are you sure you've loaded the adsp fw?
<JosDehaes[m]>
should say:
<JosDehaes[m]>
```
<JosDehaes[m]>
GL_VENDOR: freedreno
<JosDehaes[m]>
GL_RENDERER: FD740
<FarchordSteveCossette[m]>
I'll have to look at the GPU then
<FarchordSteveCossette[m]>
Getting ready for my vacation, maybe later today :)
<jhovold>
JosDehaes[m]: ah, you're missing the pd-mapper, I didn't enable the in-kernel pd-mapper since it is broken (or exposes broken drivers)
<JosDehaes[m]>
jhovold: I think so yes
<jhovold>
you need to run the user-space pd-mapper, or apply the patch to enable the in-kernel pd-mapper yourself until that's resolved
<robclark>
JosDehaes[m]: btw if you have mesa main you can revert the chipid hack patch (GL_RENDERER should be Adreno x1-85)
<jhovold>
FarchordSteveCossette[m]: there is currently no rtc support, so just set the time using ntp on boot for now
<jhovold>
FarchordSteveCossette[m]: oh, and FarchordSteveCossette[m] you will not have sound until you load the adsp fw (no guarantees that it will work, but it definitely won't until then)
<FarchordSteveCossette[m]>
jhovold: Ah…
<robclark>
I assume we need some sort of ucm config update for audio.. I have adsp but `alsactl info` doesn't list anything
<robclark>
then again, I don't see anything about alsa or asound in dmesg so maybe I'm missing something else?
<jhovold>
robclark: I haven't had time to verify audio on the crd, but the sound card at least shows up here
<FarchordSteveCossette[m]>
Hey I don't expect everything to work, very happy we're even here!
<robclark>
jhovold: my config is based on merging abel's config and fedora(ish) distro config, so I assume I'm not missing anything (but I seem to need to modprobe things manually so could be that something I need is not loaded)
<jhovold>
robclark: guess it won't work until you have a topology file, but you don't even seem to get that far
<jhovold>
(or it would have shown up in dmesg)
<jhovold>
heh, looks like abel copied johan_defconfig for the x1e_defconfig, so i guess you'll everything in there already
<robclark>
it would be a nice if there was a list of just the extra config things needed for x1e, that distros could refer to
<robclark>
the minimal configs tend to miss a lot of stuff that fedora needs
<FarchordSteveCossette[m]>
robclark: I got an idea.... hold on
<colemickens>
Farchord (Steve Cossette): did you get the udev thing figured then? what exact kernel param/
<colemickens>
it seems like there's at least 2? or 3 ways, each of which might have diff behavior
<FarchordSteveCossette[m]>
colemickens: blist the q6v5_pas driver, and then the udev rule works
<colemickens>
Farchord (Steve Cossette): which kernel param though? there's an "rd" one, a modprobe one, and one that completely blocks the kernel from loading the module.
<colemickens>
or are you only blocking it in modprobe conf and not kernel param, and that's working?
<FarchordSteveCossette[m]>
I essentially split the config/values by the =, then compared them with what's in the fedora config
<robclark>
ahh, nice
<FarchordSteveCossette[m]>
The values with integers/strings might need to be audited manually, but we're talking about <10
<FarchordSteveCossette[m]>
Actually, 3 lol
<FarchordSteveCossette[m]>
there, added two more worksheets, "Need to add" and "Exists but has diff values"
<FarchordSteveCossette[m]>
(FYI I based this straight off the config in your GIT, not from my config)
<FarchordSteveCossette[m]>
as I added some stuff
<nirik>
still not getting a usb boot here. ;( I must be doing something wrong, but I am not sure what it is. ;( I did just try blacklisting that module, no change, can't find rootfs
<FarchordSteveCossette[m]>
Yeah that module wont help or hurt you at your stage
<FarchordSteveCossette[m]>
nirik: send me your initramfs
<nirik>
which one? ;) the one from the last attempt with your kernel?
iivanov has quit [Remote host closed the connection]
<FarchordSteveCossette[m]>
Huh... sorry man I got no idea
<FarchordSteveCossette[m]>
The only thing I can think of is that that GUID litterally doesn't match with your disk uuid
<nirik>
yeah, frustrating. :(
<nirik>
I did also try with /dev/sda there
laine_ has quit [Quit: (╯°□°)╯︵ ┻━┻]
<FarchordSteveCossette[m]>
odd, for me that's /dev/sdc
<FarchordSteveCossette[m]>
the root partition is the 3rd
<FarchordSteveCossette[m]>
sorry /dev/sda3
<FarchordSteveCossette[m]>
gonna go make food, bbiab
<nirik>
yeah, I meant /dev/sda3...
<FarchordSteveCossette[m]>
nirik: are you booting from nvme or usb? If usb, a or c?
<nirik>
usb. c
<nirik>
I can also pxe boot, but that doesn't do me much good without a rootfs somewhere.
<colemickens>
Did we decide if efi=novamap was still needed?
<nirik>
If my nvme enclosure worked with this nvme drive I got I could setup that and swap it in, but it doesn't. ;(
<robclark>
efi=novamap is no longer needed
<robclark>
I just confirmed that
<nirik>
ok, so perhaps I can stick this nvme in a x86 board, boot x86 live on it and copy the aarch64 image to the nvme and swap that in and see if it works. ;)
Caterpillar has quit [Quit: Konversation terminated!]
iivanov has joined #aarch64-laptops
<steev>
jhovold: that udev rule is from upstream udev, i have the same one here. good to know about efi=novamap not being needed, i thought that was only with a "linux" option like the thinkpad has
<steev>
jenneron[m]: it always failed for me, but travmurav[m] gave me one (but i went to bed and haven't tried it yet)
iivanov has quit [Ping timeout: 480 seconds]
srinik has quit [Ping timeout: 480 seconds]
iivanov has joined #aarch64-laptops
iivanov has quit [Ping timeout: 480 seconds]
mcbridematt has quit [Read error: Connection reset by peer]
mcbridematt has joined #aarch64-laptops
echanude has joined #aarch64-laptops
<JensGlathe[m]>
whats up with the enclosure. I have 2 rtl9210 based, and one new one...
<JosDehaes[m]>
jhovold: How do I re-enable the in-kernel pd-mapper? The module is already built (but lsmod says unused). I built the userspace pd-mapper (from AUR), but it fails to start
<FarchordSteveCossette[m]>
<JosDehaes[m]> "add this patch to jhovold's..." <- Would that also work for me to get battery status?
<FarchordSteveCossette[m]>
Oh wait no
<FarchordSteveCossette[m]>
I'm still missing that resetting module
<FarchordSteveCossette[m]>
<.<
<jhovold>
steev: should have checked if I had that udev file too, at least we know why robclark has to load all his modules manually all of a sudden ;)
<jhovold>
with the x13s linux uefi option you don't need to provide efi=noruntime
<jhovold>
JosDehaes[m]: why did the pd-mapper daemon fail to start? Perhaps you were just missing the qrtr dependency?
<jhovold>
qrtr-ns, used to be needed at least if only to start the service
<JosDehaes[m]>
AUR installed qrtr-git too
<JosDehaes[m]>
I didn't debug it, as I found the patch for in-kernel pd-mapper, so I removed the daemon again
<jhovold>
ok, may be good to have around as a fallback if you start hitting the issues I saw with the in-kernel pd-mapper, random errors every 3-4 boot here, including a NULL deref that hangs boot
<JosDehaes[m]>
oh yeah, I have stupid patch for that
<jhovold>
so you've hit this issues, but worked around it somehow? delaying service registration?
<robclark>
jhovold: so somehow I'm having some badness when I switch drm to modules (I had them =y before).. but failing to get any feedback on _what_ is happening.. is that working for you on crd? (And does crd have debug uart?)
<JensGlathe[m]>
integrated it , too. Looked sensible
<robclark>
yeah, but normal distro kernel will have it =m .. and I'd like to figure out and fix whatever it is that is happening, but seems like things die too early for any hint to end up in journal
<jhovold>
JosDehaes[m]: ok, that hack may help with one of the symptoms
<JosDehaes[m]>
I have no idea what I'm doing (not a kernel dev), but the oops pointed to that place and this fixed it 😅
<jhovold>
robclark: yes, I believe I've been running with drm as modules for the past few years now
<jhovold>
definitly hit some issues initially that I fixed up (e.g. related to probe deferral) but working ok now
<jhovold>
and yes, the crd has a uart console
<robclark>
hmm, I'm _guessing_ something bad happens with some probe-defer path.. like it shuts off some clk that something else is implicitly depending on or something like that
<jhovold>
I wouldn't be surprised if there are further issues like that
<robclark>
(at least now, after learning my lesson the hard way, have a kernel with different LOCALVERSION name for the =m config, so I can switch back to a working kernel more easily while trying things
<JensGlathe[m]>
I explicitly changed to DRM=y 'cause Ubuntu has it that way
<robclark>
took me most of the morning to recover from overwriting my one good boot entry
<robclark>
yeah, probably ok for DRM=y but DRM_MSM=m is I think enough to cause issues
<robclark>
or, well, probably DRM_MSM=m would be ok if panel driver and other things it depends on are =y
<jhovold>
that was one of the issues I had initially, but someone from qcom fixed up the panel probe deferral issue
<jhovold>
could be more related issues
<jhovold>
I have both drm_msm and the panel driver as modules now
<jhovold>
(and no forced loading of the panel driver before loading msm anymore)
<robclark>
oh, actually I am getting something in journal.. looks like msm just doesn't probe.. hmm..
<jhovold>
happy hunting, I'll probably check in tomorrow :)
<robclark>
this might all be down to my nerfed udev probing, maybe the panel isn't probing
<jhovold>
yeah, you definitly want to restore that udev rule
<jhovold>
if you havenät already
<robclark>
if only that didn't result in rebooting half way thru boot
<robclark>
jhovold: oh, to answer your early question about udev rule vs reboot.. it happens on both nvme and usb
<FarchordSteveCossette[m]>
Oh i think i just hit (a) jackpot
<robclark>
well, at least adding the samsung panel module to my modules-load.d hack gets the panel up
<FarchordSteveCossette[m]>
Look at the last command used (left)
<FarchordSteveCossette[m]>
And no crash
<JensGlathe[m]>
it loaded and registered apparrently
<robclark>
hmm, I think that was one I was loading from my modules-load.d hack
<JensGlathe[m]>
Farchord (Steve Cossette):
<FarchordSteveCossette[m]>
Yep
<JensGlathe[m]>
whats different
<FarchordSteveCossette[m]>
I loaded a bunch of stuff
<FarchordSteveCossette[m]>
I noted what i did and noted the grep’d lsmod
<FarchordSteveCossette[m]>
Now im backtracking
<FarchordSteveCossette[m]>
Ok so i rounded it down to 3 modules
<FarchordSteveCossette[m]>
Some of those 3 seem to bind to the sound system
<FarchordSteveCossette[m]>
And adsp
<robclark>
jhovold: is there a way to get a list of devices which don't have a driver bound? I guess I could try manually modprobing modues for those until the system reboots (on the theory that commenting that udev rule masks an issue by just avoiding to load some driver)
<FarchordSteveCossette[m]>
<robclark> "jhovold: is there a way to get a..." <- The driver is qcom_q6v5_pas for me at least
<FarchordSteveCossette[m]>
It seems to sometimes pass thru if you load a mix of 5 modules
<FarchordSteveCossette[m]>
After this, it sometimes works
<FarchordSteveCossette[m]>
Sometimes… often… its a bit janky
<FarchordSteveCossette[m]>
But i dialed it down to those 5. But if you add those 5 and then load qcom_q6v5_pas in the modprobe it’ll still crash. Maybe some time needs to pass?
<FarchordSteveCossette[m]>
Sorry i meant, in the modules.load.d
<robclark>
oh, do you manage to get a backtrace/etc when it crashes.. or does it just quietly reboot
<FarchordSteveCossette[m]>
robclark: Well the drive gets dismounted… so no logs unfortunately
<robclark>
I've seen elsewhere that qcom_q6v5_pas needs to be blisted for usb boot. I guess that is the dsp thing that controls the usb/dp/usb-c muxing and TCPC stuff
<FarchordSteveCossette[m]>
I think the reason why it crashes is just because the root drive disappears
<robclark>
so probably causes usb reset
<FarchordSteveCossette[m]>
Yeah
<robclark>
yeah, that makes sense
<FarchordSteveCossette[m]>
Except if you load the 5 modules i mention, the system may freeze a bit but it survives
<robclark>
interesting
<nirik>
I was hoping that was the cause of my woes... but blisting it didn't seem to help. ;( But I will try later tonight when I am back home again...
<FarchordSteveCossette[m]>
Note: dont try to load those 5 modules in the modules.load.d and add the pas module below. I think things are too fast and the system still crashes
<FarchordSteveCossette[m]>
nirik: You’re still crashing in the initramfs dont you? If so its not the same thing im afraid
<FarchordSteveCossette[m]>
nirik: i would even go as far as recommend removing all those kernel modules from the forced drivers list. I dont do any of that
<nirik>
it's unclear.
<FarchordSteveCossette[m]>
But still provide them in the initramfs
<FarchordSteveCossette[m]>
If that makes sense
<nirik>
I think it's at pivot from the initramfs to the real root, and it can't find that
<nirik>
yeah, can try various more things later. ;)
<jenneron[m]>
steev: you may need `apk add firmware-lenovo-yoga-5g` to get wifi and stuff working
<steev>
jenneron[m]: what i meant is i wasnt' able to successfully generate an iso - i only need it so i can reinstall grub
<steev>
because we still haven't come up with a good way for efivars on ufs devices
<steev>
FarchordSteveCossette[m]: i dunno if this would work at all, but maybe you could try building pas in
<FarchordSteveCossette[m]>
steev: Im sorry i dont understand, i did build the kernel with it in it
<steev>
i mean not as module
lool has quit [Server closed connection]
lool has joined #aarch64-laptops
Son_Goku has quit [Server closed connection]
Son_Goku has joined #aarch64-laptops
jluthra has quit [Server closed connection]
jluthra has joined #aarch64-laptops
<FarchordSteveCossette[m]>
Oh you mean change it from m to y?
apalos has quit [Server closed connection]
apalos has joined #aarch64-laptops
Ariadne has joined #aarch64-laptops
<steev>
right
<steev>
that would require the firmware be in the initramfs though
<steev>
i'm just wondering if there's a way to probe it *before* mounting the rootfs
sibis has quit [Server closed connection]
sibis has joined #aarch64-laptops
<anonymix007[m]>
Looks like t14s became "configurable" in some regions. The only real options are OLED and touchscreen. Still the lowest end 78 CPU and no 64GiB option, which is very disappointing
<Jasper[m]>
Kinda weird, psref says 64GB is possible
<\[m]>
1TB disk tho
<\[m]>
not sure if I'd need/want 64gb but I want higher cpu and matte screen
<\[m]>
no money anyway so all good 😄
<FarchordSteveCossette[m]>
anonymix007: to be fair, alot of the laptops right now use the 78 CPU, mine included
<\[m]>
300 euro more for oled screen and 500GB disk more
<FarchordSteveCossette[m]>
I know Samsung has the faster one
<FarchordSteveCossette[m]>
I think Microsoft does too
<vk6[m]>
i guess it's because the X1E-78 is the most power efficient, and the higher clock speeds on the X1E-80/X1E-84 don't give much more performance but cause it to use significantly more power
<FarchordSteveCossette[m]>
anonymix007: is it possible that it's not the OEM's fault, but Snapdragon? Maybe they're having so lower yields that the prices would be greatly increased if they took the 80+es?
<vk6[m]>
the X1E-78 is still crazy fast for my needs, for example a kernel compile i did took on it under 5 minutes
<FarchordSteveCossette[m]>
Yes speed-wise I'm happy with the 78
<steev>
doesn't let me configure it here in the US (nor on the F&F site)
<anonymix007[m]>
Farchord (Steve Cossette): yeah, probably. Maybe getting the dev kit just to swap out the CPU (maybe it's even unfused) isn't that crazy of an idea after all.