17:12 <steev> bamse: i left the flex5g running overnight with bottom (https://github.com/clementtsang/bottom ) running, and when i got to it today... there's an serror :/

17:31 <steev> i think it's ath10k moreso than qcom side

18:02 <steev> https://usercontent.irccloud-cdn.com/file/7EPjwBDU/IMG_5577.JPG

18:03 <steev> i guess it's not serror, just an abort

21:05 <steev> oh, but now i got one :(

21:05 <steev> https://usercontent.irccloud-cdn.com/file/C36GURhB/IMG_5578.JPG

21:24 <robclark> so, sync serror like the first one, gives you a more useful backtrace.. the backtrace on async serror tends to point to random innocent victim

21:31 <bamse> steev: that callstack actually matches very well the partial noc error that i've been able to capture

21:31 <bamse> steev: the ath10k_ce_enable_interrupt() one that is

21:32 <steev> it was off to the side building an image for a kali release... and i was actually at the store when it happened :(

21:32 <steev> oh

21:32 <bamse> unfortunately i only have a partial noc error report, because the detailed one needs to be dug out of the modem

21:32 <steev> yeah

21:32 <steev> i have no idea how to do that, or even if i would be able to

21:33 <bamse> you need the secret tooling :/

21:33 <bamse> but in line with your callstack, sometimes writing that register causes the wifi noc to return a noc error

21:35 <steev> yeah, i figured i wouldn't have the tooling for it

21:36 <steev> no idea what was being written to that register either, since it was just btm running (i'm assuming it has something to do with that thermal read sync stuff)

21:38 <bamse> you had wifi enabled, no?

21:38 <steev> yes

21:38 <steev> but it was just sitting there at tty1 running btm

21:38 <bamse> then you will write to that register all the time

21:38 <steev> oh

21:38 <bamse> iirc that's written every time something is added to the tx fifo

21:39 <bamse> to one of the tx fifos*

21:52 <bamse> robclark: any suggestion to why the first dev_pm_qos_add_request() in msm_devfreq_init() would fail as the passed request is "between kernel and userspace"?

21:52 <bamse> robclark: i.e. &df->idle_freq is an invalid address

21:54 <robclark> hmm, didn't I send a fix for that recently? I think that was the issue that we could hit a window where we have runpm enabled before everything is fully setup?

21:55 <robclark> hmm, maybe that was a different issue, but https://patchwork.freedesktop.org/patch/489337/ is what I was thinking of

21:55 <bamse> nothing in next-20220705 at least...

21:56 <robclark> yeah, might not be in next.. you can try merging in https://gitlab.freedesktop.org/drm/msm/-/merge_requests/11

21:59 <bamse> no, same problem

21:59 <bamse> although the faulting address was fffffffffffffff8 this time around

22:00 <robclark> hmm, not sure then..

22:01 <bamse> no worries, just wanted to see if it was a known issue

22:21 <steev> bamse: x13s arrived :D

22:22 <steev> at least this box CLAIMS it is

22:25 <bamse> steev: woho!

22:25 <steev> the tracking number still says it's invalid lol