00:05 <steev> based on conversations though, it does seem like windows just uses the android stuff

01:38 <bamse> anonymix007[m]: that's fine, even if you copied existing content from another board...have yourself as author, yourself as signed-off-by (as you certify that the content of your patch is suitable for the kernel)...and then say in the commit message that you copied it from the crd dts

01:38 <bamse> anonymix007[m]: and as steev says, it's perfectly fine that the t14s hasn't landed, just mention the dependency (after the --- line, so that it doesn't enter the git history), and i'll take care of the ordering

02:35 <HdkR> Jasper[m]: Newer Source2 uses too many binding slots in Vulkan for sc8280xp. I think Mesa has a hack to get around it but needs an app profile to enable it? Adreno 7xx supports more binding slots so it works out of the box

02:36 <HdkR> 4 slots upgraded to 7. Which is still woefully under what NVIDIA and AMD get at 32 and UINT32_MAX

07:03 <Jasper[m]> <HdkR> "Jasper: Newer Source2 uses too..." <- Ahh alright, I'm guessing the windows driver just doesn't have this issue because it's not touching Vulkan?

07:04 <Jasper[m]> it == Source 2 games

07:08 <HdkR> Well, sc8280xp didn't ship with Vulkan drivers, so no idea what happened there

07:08 <HdkR> Not sure if Dozen works with the game

07:09 <Jasper[m]> HdkR: I think it was s&box that I tried

07:09 <Jasper[m]> And that did dx11

07:09 <Jasper[m]> haven't tested the Vulkan drivers that got released alongside the X Elite chips

07:11 <HdkR> Hopefully X1E GPU stabilizes a bit so I can test more games

07:12 <HdkR> It's a bit crash happy today

07:16 <HdkR> Or alternatively Thunderbolt starts working, would make my life easier

09:26 <pundir> Do we have a wiki somewhere to get Linux up and running on Yoga Slim 7x?

09:35 <kuruczgy[m]> <pundir> "Do we have a wiki somewhere to..." <- No wiki, though I wish we had one.... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/SnbwNUgOFKlrUAMTNCHcLlKm>)

10:05 <pundir> kuruczgy[m]: This will help. Thanks.

15:34 <craftyguy> I just booted Johan's 6.11-rc4 branch on the x13s and seems like nvme doesn't come up at all (load nvme module, no device detected). This worked fine on rc1.. did something chane recently in rc4 that might have broken it?

15:40 <JensGlathe[m]> Doubt it a little. Testing rc5 currently, actually up on rc4 (Volterra). If rc5 is de-bsod-ed I'll install it on the x13s too (currently rc3)

15:41 <craftyguy> ya I kinda doubt it too, but I haven't really changed anything else and now the nvme doesn't come up 🤷‍♂️

15:43 <robclark> HdkR: are you getting gpu crashes? I'm mostly getting _something_ segfaulting but not really sure how to tell where

15:49 <HdkR> robclark: Yea, running heavy things again causing GPU faults

15:50 <robclark> you could try extending the hangcheck timer duration in debugfs

15:50 <HdkR> `*** gpu fault: ttbr0=00000008c5318000 iova=00000001182a9360 dir=WRITE type=TRANSLATION source=CP (3736059565,3736059565,3736059565,3736059565)`

15:50 <HdkR> I assume that hangcheck wouldn't resolve those?

15:51 <robclark> no.. but devcoredump could be useful

15:55 <HdkR> I could probably get a devcoredump, wasn't going to bother since it's a new platform and problems are expected

15:55 <robclark> if no one reports problems there are no problems :-P

15:56 <HdkR> I figured they were frequent enough that even browsing would have encountered it :)

15:57 <robclark> I've not been seeing problems.. but I have been using ToT mesa (although 24.2 should be pretty close to ToT)

15:57 <HdkR> Interesting

15:59 <HdkR> Easiest way to see it is to run a source engine game. Half-Life 2 or Portal cause it. So if I get a moment I'll capture it

15:59 <JensGlathe[m]> X13s is up on rc4 now, it boots

16:02 <JensGlathe[m]> It gives an ugly zero pointer dereference crash in dev_pm_domain_detach() but it stays up

16:04 <JensGlathe[m]> and another one in usb_submit_urb - submitted while active

16:04 <JensGlathe[m]> it has booted from internal nvme though

16:05 <JensGlathe[m]> Linux x13s-jg 6.11.0-061100rc4-x1e-generic #20240818131727 SMP PREEMPT Sun Aug 25 08:41:08 UTC 2024 aarch64 aarch64 aarch64 GNU/Linux

16:07 <robclark> HdkR: portal demo thing "first slice" seems to run fine, the full version looks to want payment.. but when it exited it took down g-s

16:07 <robclark> https://www.irccloud.com/pastebin/7MKIRK9t/

16:09 <HdkR> Huh, I get a bunch of green rendering even with the intro logos

16:10 <robclark> I think it is using gl.. idk if you are using gl or dxvk?

16:10 <HdkR> Should be gl

16:11 <HdkR> I'll update my stuff before I created any dumps, maybe I hit a bad commit

16:11 <robclark> for mesa, I'm just using whatever is in last RootFS which I guess should be 24.2.0

16:12 <HdkR> Yea, I haven't updated the Ubuntu ones, so I'm still on the random mesa commit I grabbed

16:15 <robclark> if you are using an earlier version of the 7xx gallium MR you should defn update

17:00 <steev> craftyguy: i can't reproduce here :( rc4 boots fine on my x13s

17:47 <devianjefff[m]> If you're struggling for money, I have a couple of glitch  that pay and are legit. Got a couple instant ones too.  Either way you look at it,ask for more info and imma put you through the glitch... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/JfxBwyrnenxEkVrHxruxkqqY>)

17:57 <Jasper[m]> @amstan ^ or any other op (I think you can moderate from irc)

17:58 <amstan> Jasper: thanks

18:31 <JensGlathe[m]> rc5 is de-bsod-ed now as it seems. Same clock drivers as in johan_defconfig, blacklisting camcc_sc8280xp cause its loaded despite being disabled in the blackrock (Volterra) dtb.

18:32 <JensGlathe[m]> since camera is not in use on Volterra there must be some oddity

19:39 <JensGlathe[m]> X13s is up on rc5 now, no crashes in dmesg recorded, looks and feels fine

19:42 <JensGlathe[m]> Kernel packages are uploaded here: https://drive.google.com/drive/folders/1MR-ekRY5mPf0fB9i-xdAnOR-TeBKDQB4?usp=drive_link

19:43 <JensGlathe[m]> Source is here: https://github.com/jglathe/linux_ms_dev_kit/tree/jg/ubuntu-x1e80100-v6.11rc5

20:52 <abelvesa> robclark: sorry, for the late reply. The display artifacts look like square cut-offs from screen and, yes, they are visible in screenshots as well

21:23 <robclark> abelvesa: if visible in screenshot then I guess gpu and not display.. what mesa are you using (should be 24.2.x or ToT) and DE? I've not seen issues (gnome / fedora f40 / ToT mesa)

21:26 <agl> Does anybody know if there is a X86_64 Emulator for the x13s?

21:27 <robclark> fex-emu is what the cool kids use

21:27 <agl> Thank you robclark :)

21:28 <robclark> np

21:29 <agl> robclark: In the repositorities of Debian/testing is it not.

21:29 <agl> I will search with google

21:29 <robclark> https://fex-emu.com/

21:31 <agl> Thanks

21:42 <craftyguy> steev: thanks for confirming it's probably a "me issue" 😅

21:50 <steev> https://www.irccloud.com/pastebin/W8t2Okqj/

21:52 <craftyguy> ok good to know it should work. I'll have to debug it later

22:08 <Jasper[m]> I hit another particularly nasty ath11k crash

22:09 <steev> it starts spamming about wdev?

22:09 <steev> https://bugzilla.kernel.org/show_bug.cgi?id=218623 i've been hitting this one a lot more since 6.10

22:10 <Jasper[m]> steev: Don't think so?

22:10 <Jasper[m]> It's the HTC Rx Insufficient length spam

22:10 <Jasper[m]> connection dropped then

22:10 <steev> yeah, that's that bug

22:10 <Jasper[m]> a

22:11 <steev> no idea what causes it :(

22:11 <Jasper[m]> steev: Did you have a trace aswell?

22:12 <agl> Good night ... I'm going to sleep.

22:24 <steev> Jasper[m]: somewhere in my journal, probably, but it's rather spurious when i get it (usually the display is off, and i'm remoted in to it but idle, and i go to do something and the ssh session is unresponsive)

22:25 <Jasper[m]> Yeah I just had it happen under regular usage

22:25 <Jasper[m]> Threw the dmesg into a txt file

22:26 <steev> usually here the dmesg is so full of the wmi tlv parse failure and htc rx insufficient spam that the splat is just in the log

22:37 <steev> hm, from looking... i don't have a splat, and when it happened most recently, i was asleep (it was at 0507 my time) -

22:37 <steev> Aug 25 04:33:29 finn kernel: ath11k_pci 0006:01:00.0: msdu_done bit in attention is not set

22:37 <steev> Aug 25 05:07:37 finn kernel: ath11k_pci 0006:01:00.0: HTC Rx: insufficient length, got 1456, expected 1484

22:39 <steev> i actually don't get a splat til it randomly stopped working (it was spamming the logs since 5 AM but i didn't notice til 3PM heh), and i attempted to modprobe ath11k_pci -r

22:40 <Jasper[m]> Ah, well I did get a splat

22:40 <Jasper[m]> if that's useful

22:40 <steev> https://paste.debian.net/hidden/09acae3b/

22:41 <Jasper[m]> Yep, same thing

22:42 <steev> seems like the wifi device is getting stuck, and the remote proc needs to be kicked

22:42 <steev> except that i don't think the remote proc handles it on the x13s, only the c630/flex55g

22:47 <steev> ath10k and 11k have been quite unstable the past few kernel releases