00:22 <steev> pretty much yeah

01:26 <apple-corps[m]> Hi folks, I am testing kernels provided by Jens Glathe and we think that I have system halting problems possibly caused by the ath12k wifi driver in my asus vivobook 15 - x1p 4200 variant. It was suggested I might reach out to valpackett who is seemingly not present atm. But I'm open to suggestions.

01:26 <apple-corps[m]> Right now I'm trying to use the system without using the onboard wifi. I noticed that if I disabled the wifi via rfkill that I was not able to use my usb networking device despite it seemingly being in the ip addr device list. Then for now I'm trying a run with the wifi disconnected to evaluate if my symptoms are still present.

01:27 <apple-corps[m]> apple-corps[m]: And to be clear by "system halting problems" I mean "pausing" not entirely identified but I did notice 1 CPU pegged and shared some log messages with Jens.

01:28 <apple-corps[m]> apple-corps[m]: If there's a suggestion on capturing more verbose logging information and filing a bug report to confirm it's related to existing ath12k issues or if I can help to report the issues somehow, please let me know.

02:19 <steev> you could modprobe.blacklist=ath12k_pci

02:19 <steev> on the kernel command line to blacklist the ath12k device

02:19 <steev> the 1 cpu pegging sounds like something i thought valpackett and bamse may have tracked down and there was a patch for

02:20 <bamse> steev: yeah, i sent a fix for the 100% cpu consumption regression in ath12k...

02:21 <steev> https://lore.kernel.org/ath12k/20250609-ath12k-fw-stats-done-v1-1-2b3624656697@oss.qualcomm.com/T/#u iirc

02:21 <bamse> steev: it was however only solving the immediate problem, and perhaps not in all corner cases...the wifi team had just fixed a similar issue on ath11k and had already started porting over those fixes

02:22 <steev> it could be that JensGlathe[m] doesn't have that patch though :)

02:22 <steev> i saw taht :)

02:22 <steev> i really need to get using my t14s

02:23 <steev> maybe this weekend i'll do so

03:52 <dgilmore> robclark: is there any known fregressions in 6.16?

03:52 <dgilmore> regressions even

03:53 <dgilmore> I was getting weird things on my t14s. wasnt sure if that was something to do with getting the screen replaced or not

03:55 <robclark> tbh, better question for jhovold.. I'm still on 6.15-rc plus msm-next backmerge plus a big stack of patchset that I'm working on

03:56 <apple-corps[m]> Thanks for the infos folks. I'm curious regarding the other networking IE usb networking seems to be unusable when I use rfkill or perhaps `ip link set <wifi-interface> down` . Then I would hope removing the module or blacklisting it would not make other interfaces unavailable. So far in my current setup not using the wifi but leaving the interface enabled and I don't seem to be facing the pauses. So it does seem to be related

03:56 <apple-corps[m]> to that specific driver. I do believe that Jens has been patching the kernel regarding those fixes.

03:56 <dgilmore> the x13s seems okay, though bluetooth is not working

04:39 <JensGlathe[m]> @dgilmore what does hciconfig say

04:41 <dgilmore> https://www.irccloud.com/pastebin/uEhJ8iQu/

04:41 <dgilmore> @JensGlathe[m] trying to set a public-addr fails

04:42 <JensGlathe[m]> hmm

04:46 <dgilmore> "Unable to send Set Public Address cmd" is the error I get, though thats hardcoded to be printed when something goes wrong

04:47 <JensGlathe[m]> I'm still using /usr/bin/bootmac -b -W wlP6p1s0 -p A04A5E here as it seems

04:48 <dgilmore> btmgmt -i 0 public-addr 28:3B:A7:00:5A:AD is what I am trying

04:52 <JensGlathe[m]> interesting its a different address than intended here, too

04:56 <JensGlathe[m]> dgilmore: https://pastebin.com/YZyEReva works when first powered off

04:58 <dgilmore> I will try that when I get on the plane

05:16 <dgilmore> Power off fails also

05:26 <dgilmore> all commands fail

05:30 <JensGlathe[m]> <steev> "it could be that Jens Glathe..." <- Hmm it says patch already applied, on 6.16-rc2

05:30 <steev> well, that sucks then :)

05:45 <dgilmore> downgrading bluez from 5.83-1.fc42 to 5.80-1.fc42 its working

05:45 <dgilmore> so there is some bug in bluez

05:45 <dgilmore> time to go filing a bug

06:31 <dgilmore> Well first I'll see if I can figure out where exactly it broke

07:04 <steev> https://github.com/bluez/bluez/issues/1319 maybe?

15:26 <dgilmore> steev: I think so

15:27 <dgilmore> https://github.com/bluez/bluez/commit/2d2bc715025caac8530982190fc4336fdfb6a50c is the referenced commit which has such a useful commit message

20:22 <JensGlathe[m]> Upgraded my SN740 1TB with the SN770 firmware: works as described.

22:42 <bonniek> JensGlathe[m]: I put windows back. DO you still need ACPI data from 21N10001US?

22:53 <JensGlathe[m]> I guess it won’t hurt. Need to cross-check with Ubuntu 6.14.0-35 though