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
enyalios_ has joined #aarch64-laptops
enyalios has quit [Ping timeout: 480 seconds]
craftyguy has quit [Remote host closed the connection]
craftyguy has joined #aarch64-laptops
craftyguy has quit [Remote host closed the connection]
craftyguy has joined #aarch64-laptops
craftyguy has quit [Remote host closed the connection]
craftyguy has joined #aarch64-laptops
Ablu is now known as Guest1299
Ablu has joined #aarch64-laptops
Guest1299 has quit [Ping timeout: 480 seconds]
hexdump01 has joined #aarch64-laptops
hexdump0815 has quit [Ping timeout: 480 seconds]
jglathe has joined #aarch64-laptops
<jglathe>
@jhovold [ 4601.651465] dwc3-qcom a4f8800.usb: HS-PHY not in L2
<jglathe>
^^^ do you mean this warning on suspend (comes twice), device appears to immediatily wake up again
<jglathe>
this is from Volterra
jglathe has quit [Remote host closed the connection]
jglathe has joined #aarch64-laptops
jglathe has quit [Remote host closed the connection]
<jhovold>
jglathe: no, I'm not saying that, I just noticed that I do not see that warning here (for that USB port)
<jhovold>
in fact, after the discussion yesterday with dgilmore there does not even seem to be an issue with immediate wakeup as it turns out he may have been able to suspend all along
<jhovold>
all that has been confirmed is that dgilmore's ath11k fw fairly often crashes on resume
paddymahoney has quit [Read error: Connection reset by peer]
<jhovold>
(and that you may be experiencing something similar on a machine different from the X13s)
<steev>
sometimes i see them, sometimes i do not (but the system is definitely suspended)
<jhovold>
good, I'm pretty sure it's unrelated
<Jasper[m]>
Nobody willing to spare some time to check out what's going wrong with nvme in el2? 😢
jglathe_x13s has joined #aarch64-laptops
enyalios has joined #aarch64-laptops
enyalios_ has quit [Ping timeout: 480 seconds]
<jglathe_x13s>
It will happen, but for now I'm a wage slave
<Jasper[m]>
Ah yeah me too
neggles has quit [Quit: bye friends - ZNC - https://znc.in]
<_[m]123>
ooh login to gnome just crashed 😲
schaeffer has quit [Quit: well, bye]
schaeffer has joined #aarch64-laptops
<_[m]123>
* just crashed laptop 😲
neggles has joined #aarch64-laptops
<_[m]123>
ok testing external tv 4k high end samsung - gnome crashed and can't relogin 🤷
<_[m]123>
kde works actually very well
<_[m]123>
just some jitter on external screen on the right - I thought this was the mutter bug?
<_[m]123>
bluetooth having still pops n clicks and interrupts even 😲
<_[m]123>
kodi can't change to second screen
<_[m]123>
it kind of bugs in place on main screen
<_[m]123>
probably not of super interest to most of you but who knows some endusers like me waiting for normal human activity readiness
<_[m]123>
doesn't find internal playback device on bt disconnect mm and still input lag
jglathe__ has joined #aarch64-laptops
<jhovold>
_[m]123: gnome login crashing with an external display sounds like the known mutter bug, yes
<jhovold>
_[m]123: i believe bamse use bluetooth audio regularly with mainline, so perhaps some compatibility or configuration issue in your setup?
<jhovold>
you seem to use steev's branch, so no idea if there any issues there, or which bluetooth firmware you use (i.e. the one from linux firmware or the one from the windows installation)
<jhovold>
and the jitter/corruption on the edge of the screen with some high-resolutions is also a known issue
<jhovold>
please take a look at the wiki where I track known issues:
<_[m]123>
ah yes I thought that was solved, I remember now that you have to change reso indeed
<_[m]123>
highly likely to be using bt from linux-firmware
jglathe has quit [Ping timeout: 480 seconds]
<jhovold>
_[m]123: there are some reports that bluetooth works better with the boardfile that windows uses
<jhovold>
you can copy it from there, rename the current file and add a synlink to the windows one and give it a try
<jhovold>
Effectively, replace 'hpnv21.bin' with 'hpnv21.b8c'
<jhovold>
you could also see if bluetooth works better with a different device, just to try to rule out compatibility issues
<albsen[m]>
<jhovold> "(⊙_◎): there are some reports..." <- I'll try that, where can I find that? just search for a file called hpnv21.b8c?
<albsen[m]>
I'm getting the bluetooth audio jitter as well, not a massive big deal
jglathe_x13s has quit [Ping timeout: 480 seconds]
<jglathe__>
@albsen[m] yes, it's unpacked in the DriverStore. I've put it in /usr/lib/firmware/updates/... and with the current tree it calculates this name if the hardware fits
<jhovold>
jglathe__: no, that's just a patch steev carries for now, it's not in mainline so better to use a symlink
<jhovold>
albsen[m]: I think it's under Windows/System32/DriverStore somewhere
<jhovold>
albsen[m], _[m]123: also which sound server do you use, in case that turns out to be the issue?
<Jasper[m]>
<albsen[m]> "I'll try that, where can I..." <- Try the bt drivers on Lenovo's site
<jhovold>
_[m]123: yes, 'hpnv21.bin' comes with linux-firmware, you can try renaming it (backing it up) and replacing it with (a symlink to) 'hpnv21.b8c'
<jhovold>
if you want to test if the windows firmware makes any difference, that is
<jglathe__>
@_[m]123, yes I've seen this for a while. Got fixed with the latest UEFI BIOS update, was resolved after the update.
<_[m]123>
<jhovold> "if you want to test if the..." <- ah yes, gotcha
<_[m]123>
<jglathe__> "@_[m]123, yes I've seen this for..." <- I have latest
<_[m]123>
yesss seems better for now
jglathe__ has quit [Remote host closed the connection]
jglathe__ has joined #aarch64-laptops
<jhovold>
_[m]123: so the bluetooth issues you noticed are all gone with the windows firmware?
<_[m]123>
yeah
<_[m]123>
at least the interruptions
<konradybcio>
jhovold speaking of windows firmware.. no apparent change with windows adsp fw
<konradybcio>
adsp_island still won't sleep, sound still works
<jhovold>
_[m]123: thanks for testing, I've been trying to get that firmware file released for over a year now, will continue trying...
<jhovold>
konradybcio: thanks for confirming
<jhovold>
konradybcio: did you find a changelog?
<dgilmore>
jhovold: so yesterday afternoon while I was out I was able to suspend and resume multiple times without the wifi going bonkers
<konradybcio>
the ADSP ver numbers from this changelog match the oem version strings inside the windows fw
<jhovold>
i saw some page, but had to be registered to access it I think
<dgilmore>
I did leave it suspended from 4:30pm t now (8:30 am) I forget what the battery was before but I believe it was a lot higher than the current 34%
<jhovold>
konradybcio: this changelog i've seen, it was for the adsp-specific download, i think
<dgilmore>
if there was a recent update in linux-firmware yes
<dgilmore>
though the system just crashed and rebooted
<dgilmore>
jhovold: I am currently running your tree to test it out, so maybe there is a patch in there over mainline that fixes it
<jhovold>
yeah, there are some reports of regressions like that with 6.8-rc
<jhovold>
there are fixes for some issues in 6.8-rc, but nothing that should affect wifi or suspend
<jhovold>
looks like there hasn't been a new ath11k fw for a year now
<jhovold>
dgilmore: are you using an external display?
<dgilmore>
I am not
<jhovold>
wayland?
<dgilmore>
yes
<jhovold>
there has been some reports that may be related to drm fences that affect wayland
<jhovold>
that are still unresolved
<jhovold>
the joys of running rc kernels... :)
<_[m]123>
waw sound is so good, might switch over or try at least, seems most else is userland stuff
<jhovold>
_[m]123: switch over?
<bamse>
jhovold: i've possibly seen that 1-2 times since the start of the project, but i don't think i've seen that...but it's not unheard of that the modem firmware do crash, there's code in windows and downstream to power-cycle the modem in such cases...
<_[m]123>
let's give FEX another go 🙂
<_[m]123>
jhovold: mb air m1 to x13s
<bamse>
jhovold: i do see the "sequence number glitch prev=35 curr=0" frequently, and they sometimes seems to correlate to my ssh sessions freezing...i believe there's a jira ticket for that
<jhovold>
yeah, i've seen that since the start on the CRD as well
<jhovold>
seems benign, and probably indicates a fw issue?
jglathe_x13s has joined #aarch64-laptops
<adamcstephens>
jhovold: I had multiple Wayland lock ups on rc1 but rc2 has been stable in this regard
<adamcstephens>
maybe that’s just luck though if not all the fixes are out yet :)
<jhovold>
adamcstephens: ah, thanks! I just skimmed the rc2 log and found this:
<jhovold>
Should have been fixed by 66dbd9004a55 ("drm/sched: Drain all entities in DRM sched run job worker")
<jhovold>
robclark, bamse: ^
<jhovold>
nice to be able to cross that one off the list
jglathe__ has quit [Remote host closed the connection]
jglathe__ has joined #aarch64-laptops
jglathe_sdbox2 has joined #aarch64-laptops
jglathe_x13s has quit [Ping timeout: 480 seconds]
<robclark>
ahh, nice
jglathe_ has quit [Ping timeout: 480 seconds]
<adamcstephens>
yeah, I had a feeling it was truly fixed because I ran rc1 for about a day and rc2 for much longer
<jhovold>
craftyguy: you hit this too, right? ^
<craftyguy>
I had some lockups on RC1, I didn't try RC2 and moved back to 6.7 because I'm not brave enough to deal with that at fosdem :P
<craftyguy>
I could probably give it another try though if it seems to be fixed!
<jhovold>
adamcstephens: and probably explains why i didn't have any issues when a tried running sway for a bit this week
jglathe_sdbox2 has quit [Remote host closed the connection]
<jhovold>
craftyguy: yeah, it seems pretty certain that the wayland lockup is gone
<_[m]123>
damn wtf everything works today or waht, new fex-emu build, could login fairly easy 😲
jglathe_sdbox2 has joined #aarch64-laptops
<_[m]123>
what do people use for generic play/pause ?
<steev>
jhovold: jglathe__: _[m]123: assuming new enough (6.6, 6.7, 6.8) branches, it *should* attempt b8c, and fall back to .bin if it doesn't find it
<jhovold>
steev: yes, but only with your branches, not mainline or my wip branches
<steev>
right
<jhovold>
until we determine that we need this, it's better to switch manually
<jhovold>
i'm trying to get confirmation from qualcomm, but the test data do seem to suggest we do
<jhovold>
and then they need to release the firmware...
<steev>
The main reason I wrote it was to test the windows firmware, because you and bamse both said Bluetooth worked great, but for me, it was absolute trash unless I used the windows firmware
<jhovold>
i only did basic testing, but yes, i got the impression that it has worked well for bamse with the linux-firmware version
<steev>
My very limited understanding is that the b* firmware are android
<bamse>
steev: speaking of that...exactly which file are we talking about?
<jhovold>
'hpnv21.b8c'
<steev>
hpnv21.b8c on windows
<jhovold>
qualcomm released 'hpnv21.bin' to linux-firmware, which is what the mainline driver uses
<danielt>
Hmnn... perhaps I'll do a little A/B testing before I go home (I just switched to the Windows firmware and it's all going well... but I changed kernel versions at the same time so I don't know which made it happy again).
<steev>
There is a function that reads the boardid, and generates the nvm name based off that that was added as part of qca2066, but if we use that, we get the (wrong?) boardid, we get “8c” and it should be “b8c”
<bamse>
so then we have an accompanying patch to cause the driver to read hpnv21.b8c as well?
<steev>
I’m wip-ing one yeah
<bamse>
ok
<jhovold>
you can just replace the linux-firmware one with a symlink for testing
<steev>
Or that yeah
<jhovold>
until we get confirmation that we really need it and qualcomm releases whatever it is we should be using
<steev>
I haven’t submitted it because it’s definitely a hack
<steev>
I suppose I could as a rfc
<jhovold>
so far i've heard of the windows fimware fixing both audio glitches and limited range issues, but I have not had time to try to reproduce or verify this myself yet
<bamse>
jhovold: but we want hpnv21.b8c in linux-firmware, or we want to rename it to hpnv21.8c and do we still need a statement from the bt team about the 'b' or feasibility etc of this?
<steev>
the latter
<jhovold>
i don't care about what we name it :)
<jhovold>
i want to know whether we should be using a board specific firmware, and whether the one windows uses it the one
<steev>
[Tim] correct, I does not know where you get the WCN6855 firmware, for our side, we will use different name rule for android and linux , for android , we will add "b" in the front of board id, for linux we will not add this bit.
<steev>
bamse: jhovold: ^^
<jhovold>
steev: that's possibly just a naming scheme, i don't think should get hung up on that
<bamse>
steev: okay thanks
<bamse>
right, i just didn't know where it came from
<jglathe_sdbox2>
so the Windows driver file is actually a repurposed Android file (or build debris in the package)
<steev>
jhovold: yes, but, in that thread, i mention, we get board id of 8c, but the board *family* is b
<steev>
chip_id 0x2
<steev>
chip_family 0xb
<steev>
board_id 0x8c
<steev>
soc_id 0x400c0210
<steev>
chip family* not board family
<jhovold>
Our board id is 0x8c, whatever fw file qualcomm hopefully eventually releases to linux-firmware should most likely have that suffix
<steev>
it's possible the windows bluetooth driver just has a patch to prefix all of them with b
<jhovold>
the question still remains, whether we should be using the windows patch file or not
<jhovold>
if that's intended for a different firmware, that may not be the file we want to use
<jglathe_sdbox2>
it works great onmy X13s
<danielt>
I saw that the BT firmware behaviour is being described as a little anedotal so I did some basic A/B testing. The test I tried was a reboot followed by connecting BT speakers and attempting to play 30s of audio playback using VLC. I'm running a GNOME desktop but didn't start any other programs. With "Windows" firmware I observe 1 glitch over three reboots (e.g. 1 glitch in 90s of audio). With the "Linux" firmware I observed 19 glitches
<danielt>
and a disconnect over the same three reboots.
<jhovold>
(cf. ath11k, which uses different fw for the windows and linux drivers)
<jhovold>
danielt: thanks, danielt, that certainly sounds like an improvement :)
<_[m]123>
no dedicated media buttons on the keyboard really sucks
<danielt>
jhovold: Oh yes, nearly forgot. All the above was using your v6.8-rc2 but my distro-ish kernel config.
<jhovold>
steev: still not sure about the 'b', tim pushed patch files to linux-firmware with suffix .301 and the names are generated from a 16-bit board id
<danielt>
I guess the main reason it's anecdotal is its still not perfect with the Windows firmware... merely much, much better. That's why I played count the glitches.
<steev>
jhovold: yep, that's why i was scratching my head
<jhovold>
the chip_family being 0xb could be a coincidence
<steev>
i don't have enough devices to tell if the chip_family is significant.. yeah
<jhovold>
we shouldn't have to guess, qualcomm should just tell us, this is all very silly...
<steev>
that's a listing of all the firmwares windows has
<steev>
at least, the ones that are hpnv21
<bamse>
i guess the only open question is if anyone has something other than board_id 0x8c
<jhovold>
i doubt that, also the crd has board_id 0x8c
<bamse>
like the 99% of WiFi devices which has the uninitialized 0xff board id :)
<jhovold>
we haven't come across any of those on an x13s, have we?
<jhovold>
sounds like such devices need to fallback to the generic file we currently use
<jhovold>
something like that appears to be implemented for QCA_QCA2066 (for board id 0 at least)
jglathe_x13s has joined #aarch64-laptops
<_[m]123>
oooh such hope !! it was starting dota but it keeps crashing on main menu
<jhovold>
dgilmore: I checked the wrong tree earlier when I said there had been no ath11k fw releases for a year
<jhovold>
there has been several
<jhovold>
you firmware is built on december 19 which may possibly explain some differences in behaviour
<HdkR>
_[m]123: dota 2?
<jhovold>
I use the same fw as you, but a new version was added to linux-firmware three days ago as well
<enyalios>
Dantheman825[m]: did you ever get audio working under 6.7.2?
<jhovold>
dgilmore: actually the update you got in December (or January) should have been the first one that actually made it into linux-firmware for a year
<jhovold>
so, yeah, definitely worth reverifying any potential ath11k fw related issue with the latest fw
<dgilmore>
jhovold: definetly going to give it a good test now
<steev>
what firmware version are you on dgilmore ?
<Jasper[m]>
<HdkR> "(⊙_◎): I believe this hits the..." <- Wasn't there that fix at some point? Or was that limited to x elite?
<_[m]123>
what's your fps
<HdkR>
_[m]123: Garbage since I was using a debug build
<_[m]123>
what laptop/desktop is that?
<_[m]123>
oh ok
<_[m]123>
lower reso ftw 😄
<HdkR>
Jasper[m]: a7xx increases the descriptor limit from 4 to 7 which is enough for Source 2. Also there is some hack in mesa where you can expose 5 on a6xx to work around the limit, but it requires some mesa app profile
<_[m]123>
seems to give no relevant errors in the FEXBash output
<HdkR>
_[m]123: Orin dev board plus Radeon Pro w7500 is in the overlay there
<HdkR>
Yea, Source 2 just does a crash when it hits the descriptor limit
<_[m]123>
there is hope 😄
<_[m]123>
ok
<HdkR>
It would crash in the same way in a non-emulated environment
<_[m]123>
ok - I do have an egpu and 1050ti laying around mm
<robclark>
try tu_dont_reserve_descriptor_set=true for source games
jglathe_x13s has joined #aarch64-laptops
<_[m]123>
in there? .fex-emu/Config.json
<HdkR>
nope, that's a mesa option
<robclark>
it can be an env var or in in driconf
mjeanson has quit [Remote host closed the connection]
<jglathe__>
hmm probably a dumb question, but the HSP firmware on the WCN6855 is not part of Kalle's repo.Apparrently it gets sometimes updated from Windows, since it's nnot from 2022 when I bought this box (.30, 2023-10-13). Do you just use the newest amss.bin, m3.bin you can get, and it's compatible? I updated all devices with the matching version of the HSP firmware from Kalle's repo and since then, no WiFi revolt.
<steev>
johan has mentioned this a number of times, the wifi used is **not** the windows firmware
<jglathe__>
I know, not talking about windows firmware here. But AFAICT, ```[ 4.388176] ath11k_pci 0006:01:00.0: fw_version 0x1106996e fw_build_timestamp 2023-10-13 07:30 fw_build_id WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30``` is what gets detected on the card? And its newer than what got shipped to me.
<steev>
that version number comes from the amss.bin file, so yes, updating that one would update the version it reports ( i do not know if the amss and m3 need to be updated in lockstep, but no point in not doing so) - that's how i updated it here, i took the files from the .37 directory and threw them in /lib/firmware/ath11k/WCN6855/hw2.0 (because on debian, the hw2.1 files are just symlinks into there)
<jglathe>
maybe something we can't influence except for ignoring it
<steev>
yeah, i'm just not a fan of showing messages if nothing can be done
<jglathe>
afuera, so to speak
hightower2 has quit []
hightower2 has joined #aarch64-laptops
<dgilmore>
steev: just half a dozen vlans, 4 switches(~90 switch ports), 2 internet connections, 5 access points.
<steev>
dang
<steev>
and here i am.... with not that
<dgilmore>
but no cert based auth
<jglathe>
need to upgrade :)
<jglathe>
90 ports?
hightower2 has quit []
hightower2 has joined #aarch64-laptops
<dgilmore>
jglathe: just over. 48 port switch with 4 X SFP/+ ports, 24 port with 2 SFP+, 8 port 10G switch, and 8 more ports + a SFP+ port on my router
<jglathe_>
I get the picture, I guess
<steev>
dang
<dgilmore>
40 ports are unused
<dgilmore>
I could probably get rid of the 48 port switch, but I have it
<dgilmore>
anyway
<jglathe_>
you just need expansion capability, for the eventuality
<jglathe_>
trying to minimize power consumption here
<jglathe_>
sorta
<dgilmore>
my rack pulls 260-285 watts, it includes 4 jetson nano's, an espressobin, a couple of appliances, the fibre OTN, ntp server, switches and router, APs, and some cameras powered via POE. and the UPS
<dgilmore>
I could probably cut it down some, but overall it is not too bad
<_[m]123>
robclark: yep it doesn't crash but it hang and froze
<_[m]123>
progress 🎉
Erisa has quit [Read error: Connection reset by peer]
Erisa has joined #aarch64-laptops
<_[m]123>
damn that setup huh 😲
<jglathe_>
that's pretty low power consumption. Need to measure mine, but consequently deactivated many of the X86 boxes most of the time
<_[m]123>
so the DP for now can only do 30hz?
<jglathe_>
? Had the impression it did 60Hz nicely on 2560x1440
<jglathe_>
What do you run on those nanos
<dgilmore>
jglathe_: I do not have an x86 box I regulary use. there are a couple that I turn on occasionally when I need to
<dgilmore>
the x13s working let me stop using an x86 laptop
<_[m]123>
that wattage lol that's where all the ARM cpus come in I guess
<_[m]123>
oh maybe need to lower the reso then
<jglathe_>
My day job requires it, still. A few NAS are Atom based. The WatchGuard box. The UnRAID box. What my wife uses. I guess 50/50 about now, only a few power hungry boxes left. Reduction in power consumption is clearly visible in the utilities bill.
<jglathe_>
and ARM64boxes are fun, too
<steev>
how dare you stop using the efikamx smartbook dgilmore :(
<steev>
did i mention that rtp has some patches for mainline? it's just for the smarttop but i plan to look over them and see about smartbook support too
<dgilmore>
steev: I still have it. But Fedora dropped all 32 bit support
<steev>
mine still runs gentoo :)
<_[m]123>
yep it works 60hz now YEEHAA
<jglathe_>
<party>
<dgilmore>
steev: I still have the smarttop also. sitting with a pile of other 32 bit boxes I no longer use
<_[m]123>
no joke, it works over my cheapo usb hub, where the macbook air m1 needed a dedicated usbc > hdmi cable WUT
<_[m]123>
or the info in the settings is wrong
<HdkR>
Sadly the kernel only gives us half the displayport lanes. Which isn't enough bandwidth for 4k60
<_[m]123>
darn you kernel !
<jglathe_>
bad kernel!
<steev>
work is ongoing iirc
iivanov has joined #aarch64-laptops
<HdkR>
You didn't /really/ want that extra bandwidth anyway right? :)
<HdkR>
Someone needs to gift the kernel devs working on that a Valve Index so I can get Beat Saber running on the X13s
<Jasper[m]>
HdkR: I think TravMurav was trying the same thing
<HdkR>
Nice
<Jasper[m]>
Well, on the Aspire 1 obviously
<Jasper[m]>
But he was having some issues with bandwidth and getting the rift s (iirc) on the right resolution and refreshrate
<HdkR>
The Index craves that higher bandwidth but also had some other issues
<konradybcio>
7180 has a limited bus
<robclark>
7180 can't really do 4k wide either way, so the # of lanes kinda does not matter ;-)
<gabertron>
can the x13s output 4 DP lanes?
<gabertron>
oh I see -- by default I guess only 2
Cub3 has joined #aarch64-laptops
<bamse>
gabertron: the hardware can do it, our software can not yet do it...currently we're running 2+2 usb+dp always
Cub3 has left #aarch64-laptops [#aarch64-laptops]
<gabertron>
ok cool thanks
KhazAkar has quit [Quit: Connection closed for inactivity]