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
jhugo has quit [Server closed connection]
jhugo has joined #aarch64-laptops
<steev> or, don't bother, take the vacation and enjoy it and then think about it when you get back (or hope someone has solved it when you're back)
<steev> but also... are you heading to summercamp?
<steev> (this coming week is blackhat/defcon)
<steev> and bsides and diana initiative
<FarchordSteveCossette[m]> <steev> "but also... are you heading to..." <- Naaah, to a friend's house, it has a pool
<FarchordSteveCossette[m]> I'm gonna swim my arse off!
ardb has quit [Server closed connection]
ardb has joined #aarch64-laptops
pundir has quit [Server closed connection]
pundir has joined #aarch64-laptops
echanude has quit [Quit: WeeChat 4.3.5]
khilman has quit [Server closed connection]
khilman has joined #aarch64-laptops
echanude has joined #aarch64-laptops
Melody91 has quit [Server closed connection]
Melody91 has joined #aarch64-laptops
<steev> nice!
<steev> i really wish i was going to defcon, i've heard the badge will be interesting this year
<steev> not quite as interesting as the nfmi a couple years back, but still interesting
<FarchordSteveCossette[m]> I would like to go to a Linux convention next year. This year, I had a decent amount of expenses, and, well, I just couldn't pile one more in XD
leiflindholm has quit [Server closed connection]
leiflindholm has joined #aarch64-laptops
robher has quit [Server closed connection]
robher has joined #aarch64-laptops
echanude has quit [Quit: WeeChat 4.3.5]
bryanodonoghue has quit [Server closed connection]
bryanodonoghue has joined #aarch64-laptops
mani_s has quit [Server closed connection]
<steev> relatable
\\ has quit [Server closed connection]
\\ has joined #aarch64-laptops
mjeanson has quit [Server closed connection]
mjeanson has joined #aarch64-laptops
craftyguy has quit [Server closed connection]
craftyguy has joined #aarch64-laptops
jgowdy has quit [Server closed connection]
jgowdy has joined #aarch64-laptops
broonie has quit [Server closed connection]
broonie has joined #aarch64-laptops
hexdump01 has joined #aarch64-laptops
hexdump0815 has quit [Ping timeout: 480 seconds]
<JensGlathe[m]> First reviews of T14s said something about you can hear the fan wtf
<HdkR> I could definitely hear the fan in the Yoga 7x under load
<JensGlathe[m]> I am still fan-traumatized
<LucasTreffenstdt[m]> Yeah, it's audible under high load, but by no means bad.
<JensGlathe[m]> under load, like all cores, GPU that is oka
<JensGlathe[m]> I can hear the fan of the Volterra under load, too, but its quite unintrusive
<HdkR> Under full CPU and GPU load, the max CPU temperatures I hit on the 7x was 86c, and no throttling that I could see
<JensGlathe[m]> X13s is the champion in this regard, but gets throttked after 10mins or so
<steev> is that with my hotter patch?
indy has quit [Ping timeout: 480 seconds]
<JensGlathe[m]> 6.11rc1 isn't booting from USB-C (x1e merged or not) grr
<FarchordSteveCossette[m]> <sarcasm> Have you maybe tried the linus tech tips trick of putting your laptop in ice water? I heard it helps with temps! </sarcasm>
<FarchordSteveCossette[m]> Ahh well thats dumb, matrix stripped my sarcasm tags
<JensGlathe[m]> nice one. I guess Nitrogen is better
<FarchordSteveCossette[m]> See, my desktop has a noctua heatsink, the double tower one. Now THAT one is loud
<JensGlathe[m]> I have Noctuas all around here. Mostly NH-D15
<JensGlathe[m]> They're pretty silent most of the time.
krei-se has quit [Read error: Connection reset by peer]
krei-se has joined #aarch64-laptops
bluerise has quit [Quit: brb]
<steveej[m]> is there a chance that the bluetooth range on the x13s can be increased with a future firmware or kernel update? compared to all my other devices it's roughly half
bluerise has joined #aarch64-laptops
<\[m]> but logic, if the cpu is faster, it will heat less for same load?
<\[m]> right?
<travmurav[m]> if it's faster via ipc and not just power envelope
<\[m]> what do you mean
<\[m]> it's related to some physical layout
<travmurav[m]> as in, you can make something faster by optimizing the architecture or just by cranking the clock and voltage up
<\[m]> I thought those model numbers referred to exactly just higher clock?
<\[m]> more transistors stacked?
<travmurav[m]> if you mean x1e then i think yes, it's just binning
<travmurav[m]> so like "better" (in terms of defects) chips have higher number and thus can run on a higher clock
<\[m]> yeah x1e, I haven't and will not look at low level cpu design lol - but i think you can safely assume they won't redesign the cpu for cramming more transistors in the same model
<travmurav[m]> but I'd say it's mostly the second "clock/voltage", for which I'd expect the power consumption is not /that/ significantly less for higher bin chips
<\[m]> so yeah it needs less compute to process the same signals, which makes the heat creation lower
<\[m]> so depending on thermal thresholds in bios, should have fans less spinning up
<travmurav[m]> but no, what I mean is, all those chips take same amount of clocks to do the workload, just the better ones can have higher clock/power, and power consumption increases non-linearly with the clock speed
<\[m]> I've had my logic backfire at work, I asked for the biggest model available, and hpe shipped borked fckng bios, the basic running temp was right around the spin up temp setting in bios ☹️
<\[m]> travmurav[m]: power consumption is linear with your load, not your possible cpu clock speed / voltage needs, no
<travmurav[m]> so tbh I'd not expect the higher bin chips to be that much "more efficient", especially since ideally they should just cpuidle most of the time anyway unless under load
<\[m]> if I run the same load on the x1e 78 or the "faster" one, theoretically it should use the same wattage?
<travmurav[m]> \: I meant, assuming constant workload, increasing clock/voltage will increase power consumption
<\[m]> hmmm
<\[m]> so if it's doing the compute faster, eating more power, it will generate more heat but for less time
<travmurav[m]> and what I'd expect the difference is, that lower bin chips just aren't stable at a fast clock
<travmurav[m]> yes, faster at the cost of more power
<travmurav[m]> that's what I'd expect
<travmurav[m]> but this is only for the case of a full workload
<\[m]> myeah, I have no mental comparison model for the speed of these cpus really, I just want my fans to stfu 99% of the time 😄
<travmurav[m]> well assuming your cpu idles 99% of the time, the cores should be completely unpowered
<travmurav[m]> if cpuidle works properly
<\[m]> basically and likely, the speeds diff is irrelevant for most people maybe
<travmurav[m]> iow I'd expect that the power consumption will be the same-ish for all x1e assuming average usage scenario
<\[m]> I'm actually lying, I have the m1 7gpu and I had before the m1 8 gpus
<\[m]> that's kind of my baseline and without active cooling but wíth thermal pads the m1 8gpu was fast af
<\[m]> and if this cpu compares to m3 and those got faster like tens (10 20 30) % than the m1 than that's blazing really
<\[m]> ( I could play dota2 on lowest settings on a 4k 32 inch screen smoothly with that m1 8gpu without thermal pads even, which is my way of benchmarking :D )
<travmurav[m]> does gpu even depend on the bins?
<\[m]> it s in the same chip, I'm too noob to understand what it really means
<\[m]> but not only gpu is used when running a game
<travmurav[m]> I mean on x1e do they say that higher bin chips have better gpu or they all have same freq?
<\[m]> I guess cpu and gpu are still logically seperated inside
<travmurav[m]> seems like higher bins have a bit faster freq on the gpu
<travmurav[m]> but well, meh, wrt power consumption I think it's hard to tell how big the difference would be
<travmurav[m]> and wrt fan curve, lol I hope the fan is controlled from the os so could just set your own curve to silence it and let the chip throttle a bit xD
<\[m]> are such low level details even available? I guess the chip design is proprietary af
<travmurav[m]> what details?
<\[m]> like how it is physically designed?
<\[m]> how the gpu is integrated
<\[m]> ah okay, you're saying that at least the gpu is scaling too
<travmurav[m]> no but it's pretty easy to guess that it's just an IP block in the soc like it always has been
<travmurav[m]> but they advertized that the higher bin x1e has faster gpu, which is just binning again
<\[m]> SoCs are baffling really
<\[m]> > , which is just binning again
<\[m]> what does that mean
<travmurav[m]> binning == separating same chips into "better" and "worse"
<\[m]> but are you implying with the remark it is somehow less relevant than one would think
<travmurav[m]> so like, assume they test every chip and split: can run fast? => to a good bin; can't run fast? => to a worse bin; has one/two cpu cores not booting at all? => x1 plus
<travmurav[m]> yes, in terms of that the architecture is the same
<\[m]> so it's about the IP blocks containing faster chips, which is just lucking out in the production process?
<\[m]> I thought they literally just made it bigger and fit more transistors
<travmurav[m]> no, literally luck
<\[m]> lol that's news to me 😄
<travmurav[m]> "silicon lottery" is the widely used term
<\[m]> well, I'm not spirital, but I wouldn't mind the more lucky thinking special sand at my finger tops hahaha
<travmurav[m]> and to clarify, "IP block" is a logical part of a chip in this case, so i.e. "oryon cluster" is an IP block, "adreno gpu" is an ip block, "hexagon adsp" is one..., and thye're all added together and printed at a fab
<\[m]> so yeah I still think it will generate less heat, you won't idle 99% of the time imo
<\[m]> (sorry for edit)
<\[m]> this is m1 7g[us
<travmurav[m]> I think it will generate less heat when it's not on full load but more heat when it's 100% loaded but it's hard to tell and not like I'm an expert in chip power :P
<robclark> travmurav[m]: current dts for x1e, gpu opp's don't have any `opp-supported-hw`.. but I think that is just a patch not posted yet, https://www.qualcomm.com/products/mobile/snapdragon/laptops-and-tablets/snapdragon-x-elite implies the higher skus have faster gpu
<\[m]> oh ok, thanks for following through, going to read a bit more about it
<\[m]> it's phsyics right, FOLLOW THE LAW SILICON
<robclark> and yeah, there is some variance in Si, some dies come back "hotter" than others
<robclark> btw, what are all these /dev/nbdN devices? I don't remember seeing them on x13s https://usercontent.irccloud-cdn.com/file/HSEANaBz/image.png
<travmurav[m]> sounds like a "remote" block device thing
<robclark> right, but why do I have them?
<travmurav[m]> I think nbd is what pmOS uses to "network boot" with rootfs on the remote pc, but it'd be indeed weird to have a bunch of nbd devices out of nowhere...
<robclark> hmm, I do have "CONFIG_BLK_DEV_NBD=y" maybe I didn't have that on x13s
<spawacz> The audio jack in x13s is not working for me. I don't see any device detected in pavucontrol, whether I plug something or not, it's empty. How to diagnose the issue?
<spawacz> I'm running Debian sid
hightower2 has quit [Ping timeout: 480 seconds]
juergh has quit [Ping timeout: 480 seconds]
juergh has joined #aarch64-laptops
<jhovold> spawacz: start with making sure pd-mapper is running
<jhovold> steveej[m]: yes, there's still a chance we'll get qcom to release the missing bluetooth boardfile which will address the range issue
<jhovold> you can use the one from windows meanwhile, excellent range, almost too good
<spawacz> jhovold: I don't think it is running. Is it installable via apt?
<spawacz> There's pd-mapping package
<jhovold> that should be the one
<spawacz> should I see something running in htop or systemctl?
<jhovold> yes
<spawacz> Nothing like that is running. I think this package is something else than pd-mapper
<travmurav[m]> wasn't it called (more explicitly) protection-domain-mapper on debian?
<spawacz> There's protection-domain-mapper package
<spawacz> The service is listed as loaded, inactive (dead)
<spawacz> but there's nothing red, no log in journalctl
<spawacz> When I run it by hand, I see new "built-in audio" in pavucontrol, so I can start debugging the service issue
<spawacz> Huh it worked for some time, started cracking and now it does not play at all
<spawacz> pd-mapper does not start because qrtr-ns service is missing
<nirik> So, I made a bit of progress this morning. At least I get to userspace now... but then it reboots on me. ;( I do have journal logs on the usb... I see a odd panel thing in messages: https://paste.centos.org/view/8ef15cd7
<FarchordSteveCossette[m]> <nirik> "So, I made a bit of progress..." <- panel-edp is fine. lemme check the rest
<FarchordSteveCossette[m]> nirik: try just for fun to blacklist qcom_q6v5_pan (I think it's name was?)
<FarchordSteveCossette[m]> pas
<FarchordSteveCossette[m]> not pan
<nirik> yeah, done already
<FarchordSteveCossette[m]> Still not booting?
<nirik> so, your kernel still doesn't boot for me.. hangs looking for sda. robclarks kernel boots to userspace, starts a bunch of stuff, gets finished with zram and then reboots.
<nirik> and nothing in logs as to why it rebooted. no panic, just reboot.
<nirik> here's the full journal output from that: https://paste.centos.org/view/b5299752
<FarchordSteveCossette[m]> Have you tried to remove the drivers udev rule just for fun?
<nirik> yes, if I remove it it gives me this, if I re-add it, it cannot find root and panics.
<FarchordSteveCossette[m]> ahhh....
<nirik> (assuming you mean in the install, not initramfs)
<FarchordSteveCossette[m]> This may sound reaaaally dumb, but.... have you tried filming it boot with your cell phone's camera but in slowmo mode? lol
<FarchordSteveCossette[m]> Yeah
<nirik> thought about it, but it should be the same as this journal output...
<nirik> so, robclark's kernel has qcom_q6v5_pas builtin I think... so the blacklist doesn't help there.
<FarchordSteveCossette[m]> Depends, I noticed that journald only dumps to file once in a while
<nirik> hum, no... weird.
<FarchordSteveCossette[m]> Well, did you actually add it to /etc/modprobe.d in a config to blacklist it from userspace?
<FarchordSteveCossette[m]> it's blisted from the initrd, I saw that
<nirik> ah, I see it now. it's a module indeed.
<FarchordSteveCossette[m]> Yep
<nirik> yes, modprobe.blacklist is supposed to do that I thought.
<nirik> can try a modprobe.d
<FarchordSteveCossette[m]> I don't know lol
<FarchordSteveCossette[m]> I'm still new in this whole "custom kernel" thing
<FarchordSteveCossette[m]> My understanding is, if you set it in dracut, I THINK it only sets it in the initramfs
<nirik> yeah, but modprobe is not dracut, it's modprobe itself...
* FarchordSteveCossette[m] shrugs.
<nirik> here's a much more gigantic boot log with systemd debuging (3mb!) https://paste.centos.org/view/8ef15cd7
<colemickens> I've confirmed that I have the _pas module blacklisted, but that wasn't sufficient, I still get the reboot: https://github.com/colemickens/nixos-snapdragon-elite/blob/f772ebb4d21e780d08690db1f08f323cf0b5083c/snapdragon.nix#L46-L48
<FarchordSteveCossette[m]> Unknown, I'm afraid
<colemickens> I mean, I would assume not, you're using johan's defconfig right?
<colemickens> So you would have all the same modules available as me....
<FarchordSteveCossette[m]> Yes, with some added stuff
<colemickens> and you're only blacklisting modprobe conf, not a more aggressive kernel param?
<FarchordSteveCossette[m]> The config itself is largely the same, but I also did not force-load any drivers in the initramfs
<FarchordSteveCossette[m]> Correct
<colemickens> Thing is, I only get the reboot after I pivot rootfs, so I don't even think it's an issue of what modules I have available in initrd.
<FarchordSteveCossette[m]> Oh I get it, but when something unknown happens, usually I revert as much stuff back to "stock" and see if it works. If yes, then I slowly reintroduce stuff
<FarchordSteveCossette[m]> That's what I do usually
<FarchordSteveCossette[m]> *anyway
<FarchordSteveCossette[m]> tbf, my last attempt was to set qcom_q6v5_pas as a full module (*) not (M) and the system no longer boots, it just blackscreens.
<FarchordSteveCossette[m]> I didn't troubleshoot it further as I needed to get ready to leave
* FarchordSteveCossette[m] is currently using his X1E laptop in Windows mode.
<colemickens> nirik: I think we're in the exact same boat right now.
<colemickens> disabling 80-drivers.rules I think prevents it discovering/loading the right modules for usb, so it doesn't find our rootfs
<colemickens> with the 80-drivers.rules, we get the reboot
<colemickens> and I'm also blacklisting pas and still getting the reboot.
<FarchordSteveCossette[m]> that's odd though. Before, I could load in just fine with the 80-drivers thing
<FarchordSteveCossette[m]> Did the config change? Did they change the q6v5_pas driver to be a full build?
<FarchordSteveCossette[m]> i.e. * not M?
<FarchordSteveCossette[m]> ok
<colemickens> I wonder if the adsp firmware loads in stage-2 and yoinks the usb and then it reboots
<colemickens> I think I forgot, I thought we suspected that adsp firwmare was okay, as long as we blacklisted _pas but now I'm not sure?
<nirik> so, random, dumb question: how much memory do you have colemickens ?
<colemickens> nirik: 32gb
<colemickens> er
<colemickens> no
<colemickens> 16gb
<nirik> so it seems it doesn't matter what I blacklist in userspace... but need to block msm and q6v5_pas in initrd... if I don't block those in initrd it doesn't find the usb
<colemickens> I keep forgetting that I ordered the 32gb but have a 16gb loaner
<nirik> oh well, there goes that theory. I have 32 here, was wondering if it was a dtb issue with 16 vs 32 memory
<colemickens> Uh, hm, that's weird. I was definitely able to boot from usb into stage-2, with the _pas module in initrd and not blacklisted.
<nirik> I wish I could see why it's rebooting. :(
<colemickens> that may have been with the firmware removed though.
<nirik> are you blocking msm? or no?
<nirik> ok
<steev> spawacz: https://github.com/jhovold/linux/wiki/X13s#audio has some tips to try (or untry)
* nirik goes to mow. What fun... not sure what to try next to avoid the rebooting.
<steveej[m]> jhovold sounds promising! is there a doc on which firmware i need from windows? is it legal to redistribute it publicly?
<spawacz> steev: The playback is ok, cracking very rarely. Recording cracks. ALso when i run pavucontrol i hear loud cracking from the builtin speaker
<spawacz> besides, I cant select the internal speakers/mic, they are marked as unplugges
<spawacz> unplugged
<steev> That’s.. weird
<spawacz> does pipewire work?
<spawacz> i dont have pulseaudio, only pipewire and pipewire-pulse
<steev> that's what i'm using here (though i'm on "trixie"
<steev> admittedly, i've not use the headphones in a long time, only speakers
<jhovold> spawacz: pipewire support is known to be broken, crackling playback and recording (there's a workaround for playback, see the wiki entry steev linked to)
<spawacz> :(
<jhovold> steveej[m]: no, you cannot redistrubute it, but you can try it at your own risk, the file is named hpnv21g.b8c
<jhovold> works fine here, but as I said, the range is almost too good...
<steveej[m]> could that mean it gets overpowered? what's the risk?
<jhovold> rename it as whatever name the current linux driver loads (e.g. hpnv21.bin, or similar)
<jhovold> yeah, perhaps you shouldn't use bluetooth on a plane, no idea, just a hunch...
<jhovold> the range improved when using a board file for a previous build as well, which could indicate that the firmware is missing some sanity checks
<jhovold> colemickens, robclark: sounds like you're dealing with two separate issues, the known issue of adsp fw loading triggering a disconnect which can mess up usb boot, and whatever that hard reset you seem to be hitting is
<jhovold> perhaps you can instrument the kernel so that it prints the driver name before every device it probes, and waits a bit, so you can tell which driver causes the reset
<jhovold> you may need to disable async probing as well
<jhovold> i think there are kernel parameters for addiing waits between each print, for disabling async probe, and for enabling debug prints for each driver probed
<jhovold> but it may be easier to just add it yourself
<jhovold> btw, are you all trying to get the yoga to boot? and everyone using fedora?
<jhovold> no such issues with the crd, perhaps you can check with srini who also has the yoga (but who's not using fedora, i believe)
srinik has joined #aarch64-laptops
<colemickens> jhovold: yes yoga, no, nixos.
<colemickens> (With johan_defconfig)
<steev> jhovold: specifically the hpnv21g.b8c not just hpnv21.b8c? (i never tested the g variant in my testing)
srinik has quit [Ping timeout: 480 seconds]
<FarchordSteveCossette[m]> Food for thoughts, on the Asus Vivobook, the USBA ports are controlled by a Synopsys driver, which seems to be in the Linux Kernel (DWC3)
<FarchordSteveCossette[m]> Might have to see if it works out of the box
<FarchordSteveCossette[m]> On Windows, the path is ACPI\PNP0CA1 (Not sure if it helps)
<JensGlathe[m]> Hmm some of my observations trying to assemble an Ubuntu image that boots on SC8280XP via USB-C and should have some probability of working in x1e hardware:
<JensGlathe[m]> 6.11 fails to boot from USB-C (yet) with the same imae that boots flawlessly with the 6.10 kernel. This needs to be resolved first. The Kernel boots until system timer, then it resets (on the WDK). Since the differences between 6.10 and 6.11 regardin johan_defconfig are really small, I will check all these options. Must be something regarding clock.
<JensGlathe[m]> Re USB-A ports on the Vivobook: Would be likely that they are DWC3, as SC8280XP already has a DWC3 MP controller giving 4 USB-A ports. Would only cost extra to use a different chip. These ports need some pinctrl in the dt to get enabled (at least that's the case for the WDK, which has 3 USB-A Ports and the ethernet i/f on the fourth).
<steev> does anyone happen to know the mapping of security vulns at lenovo to something external? x13s is showing a 1.61 bios update that addresses "LEN-154756" but i can't find any actual info on what that is
<steev> they separately call out the big cve that was reported for intel chips (on a different bios update for a different device) *and* this one as well
louist103 has joined #aarch64-laptops
<louist103> Hi all. I've decided I haven't had enough gentoo so I got another C630 (for free again) I saw a few weeks ago there was an improvement wiht the embedded controller but I am not sure if that is as big as I think it is. I did save the OS when I went back to windows but I'm not opposed to starting over since tis been so long.
<louist103> The issue with installing is that I lost the kernel build config and the pasebin seems to have expired. I also couldn't use USB to install the windows drivers.
<steev> louist103: you can start with "defconfig" and add in the things you need for the gentoo side of things you run
<steev> if you want a kernel config that is full of overkill, https://dpaste.com/HP47FTJR6 is the kernel config i use on my c630+x13s
<steev> it's overkill because it's the debian kernel which makes pretty much everything and the kitchen sink a module
<louist103> I'll take overkill and fully working over slim and not working
<louist103> Well fully working minus the windows stuff
<steev> oh, that's for 6.10 - https://salsa.debian.org/steev/linux/-/tree/master/debian/patches/features/arm64?ref_type=heads are all the patches i apply on top, the only c630 specific ones start at 91
<steev> i wouldn't say it's fully working though, audio broke around... 6.8? 6.9?
<louist103> I see. Are those going to be upstreamed at some point?
<steev> those are upstreamed, or at least, submitted
<steev> i "backported" (read: applied) them to 6.10
<louist103> Do those patches fix audio on 6.10?
<louist103> Is is there a known fix for it?
<steev> i need to re-test jenneron[m]'s patch as i mentioned when i linked it
<steev> i broke my c630 the other day
<steev> i need to write the pmos usb to a usb key and fix the grub
<steev> oh wait, no c630 is fine i think
<steev> one other thing, you may need to modprobe.blacklist=ipa to get it to boot - something to do with having coresight and ipa enabled at the same time, not entirely sure; i haven't tested disabling coresight yet
<louist103> Ok noted. Can I use whatever the latest kernel is with your 6.10.2 config to avoid needing the patches?
<steev> you can try it yeah
<steev> 6.11-rc1 should have the ec patches applied iirc
<louist103> Ok. As long as mismatched configs vs versions won't cause too much trouble.
<steev> nah, should be fine, it might complain about debian signing keys, you can just disable those