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
jgowdy has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<steev>
hm, yeah, i've applied the l0 patches to 6.7 and still seeing the aer; looks like it most happens when either suspending or resuming, not sure which one is the culprit
f_ has quit [Read error: Connection reset by peer]
f_ has joined #aarch64-laptops
todi has quit [Remote host closed the connection]
todi has joined #aarch64-laptops
Nios34 has joined #aarch64-laptops
<Nios34>
Thanks to the kernel by hexdump0815, I successfully installed Debian bookworm into the UFS storage.
<bamse>
you guys don't actually need to run eachothers' kernels...just build mainline defconfig and run that
<Nios34>
I didn't want to try that at first. But I accidently destoryed the NTFS partition... So I was left no choice lol
<Nios34>
bamse: Yeah, by hexdump0815's kernel, I mean the devicetree and patches ;-)
<Nios34>
hexdump0815, it looks like there is no longer needed to do that /boot/boot hack
<Nios34>
I just did `grub-install' and it works fine.
hexdump01 has joined #aarch64-laptops
hexdump0815 has quit [Ping timeout: 480 seconds]
Nios34 has quit [Ping timeout: 480 seconds]
krei-se has quit [Ping timeout: 480 seconds]
krei-se has joined #aarch64-laptops
jhovold has joined #aarch64-laptops
<jhovold>
steev: guess the AER you see with that NVMe is not related to L0s then, do you see it also if you disable aspm completely?
<jhovold>
and do you only see it on suspend/resume?
<steev>
jhovold: i think it's a change that's in 6.8 that isn't backported to 6.7, because i do not see it in 6.8 after suspend/resume cycles.
<steev>
and on 6.7 i'm pretty sure i only see it on suspend/resume cycles
<jhovold>
ok, but you had backported my ASPM fixes you said?
<steev>
yeah, pretty sure i have them correctly (they applied cleanly at least iirc)
<steev>
i don't think it's that big of a deal
iivanov_ has quit [Remote host closed the connection]
iivanov has joined #aarch64-laptops
<jhovold>
steev: me neither (the errors are correctable), but still good to know when you see this (and if possible why)
<jhovold>
which nvme controller are you using?
<jhovold>
does it even support l0s btw (I know l0s is disabled, but the one that came with my X13s does not support it)?
<Jasper[m]>
<jhovold> "which nvme controller are you..." <- The one in the sn770m probably
<jglathe__>
This is 6.8-rc6 so sometimes this comes up
<jhovold>
jglathe__: same nvme controller as steev?
<jhovold>
and with L0s disabled also for volterra?
<jhovold>
or is this with x13s?
<jglathe__>
I'll check
<jglathe__>
on Volterra, sorry, false alarm. I'll check again for X13s
<jglathe__>
jhovold it is *not* on X13s with 6.8-rc6. My nvme controller is "0002:01:00.0 Non-Volatile memory controller: Silicon Motion, Inc. SM2263EN/SM2263XT (DRAM-less) NVMe SSD Controllers (rev 03)
<jglathe__>
"
<steev>
jhovold: i've slept and resumed a bunch on 6.8.0-rc7, no aer - 0002:01:00.0 Non-Volatile memory controller: Sandisk Corp WD Black SN770M NVMe SSD (DRAM-less) (rev 01) - firmware rev is 731120WD (currently the latest)
<steev>
that was for jhovold since he asked for it :P
<HdkR>
The SN770M if I remember what I recommended? :P
<steev>
0002:01:00.0 Non-Volatile memory controller: Sandisk Corp WD Black SN770M NVMe SSD (DRAM-less) (rev 01) - firmware rev is 731120WD (currently the latest)
<HdkR>
nice
<adamcstephens>
i just did some testing with jhovold's 6.8 rc7 and after repeatedly plugging/unplugging my dock the x13s did not crash
<adamcstephens>
though it did stop communicating with the USB hub :/
<konradybcio>
no issues here, on the same branch
<konradybcio>
i have a pretty low spec dongle though
<adamcstephens>
i'm using OWC's TB4/USB-C dock
iivanov_ has joined #aarch64-laptops
iivanov has quit [Read error: Connection reset by peer]
jglathe_volterra has joined #aarch64-laptops
hightower4 has joined #aarch64-laptops
rmsilva- has quit [Ping timeout: 480 seconds]
hightower3 has quit [Ping timeout: 480 seconds]
<steev>
jhovold: actually, i was able to get an aer on 6.8 rc7; i *think* it was during an sbuild-create run, because i was trying to build an amd64 chroot on this thing for building packages
rmsilva has joined #aarch64-laptops
<steev>
but back to packing and not working
rmsilva- has joined #aarch64-laptops
rmsilva has quit [Ping timeout: 480 seconds]
<_[m]123>
ah fck I for some reason booted 6.5 lol - though I've seen pretty stable dpe - only one random disconnect and after 1 replug came back
<_[m]123>
I also noticed on KDE when I manually do sleep it breaks the unlock screen
<_[m]123>
but not on laptop lid close which is odd
mjeanson has quit [Ping timeout: 480 seconds]
mjeanson has joined #aarch64-laptops
jhovold has quit [Ping timeout: 480 seconds]
todi has quit [Remote host closed the connection]
hightower3 has joined #aarch64-laptops
hightower4 has quit [Ping timeout: 480 seconds]
<steev>
okay i'm bad at the whole packing and not working thing. it's not reproducable
hexdump01 has quit []
hexdump0815 has joined #aarch64-laptops
<hexdump0815>
Nios34[m]: that is good news - btw. you can always assume me reading this channel here via the web frontend, even if i'm offline :)
<konradybcio>
big brother
<konradybcio>
always reading
<hexdump0815>
Nios34[m]: i was about to ask you to write down some more details, but a few lines later you already had fullfilled that wish - thanks a lot for that
<hexdump0815>
konradybcio: doubleplusgood :)
<hexdump0815>
Nios34[m]: the remaining hardware i did not manage to get working yet, but in case you get anything working i would be happy to hear about it ... lets see - maybe over time we can get it a little further in small steps
<hexdump0815>
Nios34[m]: now that you have it working on ufs i'll most probably give it a try as well, also its good to know that grub now seems to work well on it
hightower2 has joined #aarch64-laptops
hightower3 has quit [Ping timeout: 480 seconds]
<Nios34[m]>
hexdump0815: Yeah, Windows really sucks.
<Nios34[m]>
or Windows on Arm
<Nios34[m]>
Actually, the LUNs are pretty interesting as well. It looks like it's something associated with the coprocessor.
<Nios34[m]>
I tried if one can make it safer by somehow remove /dev/sd[b-f]'. I did this by telling uvdev to call /sys/block/sdX/device/delete' but after that remoteproc started to complain something.
<Nios34[m]>
So... The coprocessor somehow uses that UFS drive.