02:25 <steev> lumag: v7 does seem to work for the most part, however.... (sorry there is always a however with me :( ) - it seems like every so often, there may be a race where it doesn't load properly. is dmesg output good enough for you or is there more info somewhere i should grab?

02:26 <steev> of pd mapper*

04:25 <lumag> dmesg is enough of _debug output

04:25 <lumag> steev, or a description of the issue

04:33 <steev> lumag: i've only had it happen once, but basically the battery showed up at 0% and the remote procs weren't started - actually, just rebooted 3 times and got it to happen again :)

04:33 <lumag> steev, which platform is that? And what is your .config? I'll try reproducing it here

04:34 <steev> https://paste.debian.net/hidden/d8205b95/

04:34 <steev> X13s - http://sprunge.us/CfcBgc is the config i'm using

04:35 <steev> i plan to test it on 6.9 shortly, but since i knew 6.8 was stable i was testing it on top of that

04:35 <lumag> steev, could you please add #define DEBUG to the top of the pdm driver and then try reproducing the issue?

04:35 <lumag> I don't think baseline matters

04:35 <steev> sure

04:37 <steev> it IS nice to see it working when it does though :D

04:37 <lumag> at least I don't see any errors in the log

04:37 <steev> around line 706 is where the remote proc seems to go wrong

04:38 <lumag> [ 4.499434] qcom_q6v5_pas 3000000.remoteproc: error -ENXIO: IRQ wdog not found ?

04:38 <steev> yeah

04:39 <steev> hwirq-194

04:39 <lumag> Wait...

04:39 <lumag> [ 4.471281] remoteproc remoteproc0: releasing 3000000.remoteproc

04:39 <lumag> [ 4.506518] remoteproc remoteproc1: releasing 3000000.remoteproc

04:40 <lumag> Let me take a look

04:41 <lumag> Just out of curiosity, if you see such issue, can you try manually starting the adsp?

04:41 <steev> how do i manually start it?

04:41 <lumag> echo start > .../remoteproc1/state

04:41 <lumag> echo start > /sys/class/remoteproc1/state

04:41 <lumag> ***

04:41 <steev> it doesn't exist

04:41 <lumag> echo start > /sys/class/remoteproc/remoteproc1/state

04:42 <steev> only remoteproc0 in /sys/class/remoteproc

04:43 <lumag> ok, reading the source now. releasing means that remoteproc is being destroyed

04:47 <lumag> steev, please pick up f011688162ec4c492c12ee7cced74c097270baa2

04:48 <lumag> steev, https://lore.kernel.org/all/20240219-remoteproc-irqs-v1-1-c5aeb02334bd@fairphone.com/

04:49 <lumag> z3ntu, oh, my, the patch isn't even marked as Fixes

04:49 <steev> will grab

04:49 <steev> that's a paddlin

04:52 <lumag> ?

04:52 <steev> ah, it's a joke

04:53 <steev> that's a paddlin is like, a spanking. for not marked as Fixes

04:53 <lumag> steev, my best theory would be that AF_QIPCRTR is n't available at the time of the first start attemt. This causes the call to return EPROBE_DEFER.

04:53 <lumag> And on probe deferral the IRQ comes into play

04:53 <steev> that makes sense

04:54 <steev> i grabbed the patch as well

04:54 <steev> fwiw, in next, it does have Fixes tags

04:54 <steev> bjorn added them

04:54 <lumag> That means that I should add a kind of MODULE_DEPENDENCY from pd_mapper onto qrtr

04:54 <lumag> steev, ok, good

05:39 <steev> lumag: so far, with f01168816 pulled in as well, i haven't been able to reproduce (and i stupidly have not been counting the number of reboots, but i know for sure i ran into it twice in less, before that commit :) )

05:39 <lumag> steev, thanks!

05:39 <lumag> It would be nice to check if you can trigger the 'releasing foo.remoteproc' message

05:39 <steev> aside from battery and audio working, is there any other tests

05:40 <lumag> with the ucsi series in place, you should have /sys/class/typec/port0 and port1

05:42 <steev> i can't recall if i do or not, will check after this reboot :)

05:44 <steev> aw, i don't. i have /sys/class/typec but nothing in there. will try to get that tested soon too

06:15 <lumag> steev, thanks!

06:15 <lumag> If you can respond with tested-by to the pd-mapper series, that would be great. Maybe after several more reboots

06:19 <steev> absolutely :)

06:20 <steev> i keep rebooting, logging in, checking dmesg for releas and then rebooting again, so far i haven't seen it

06:21 <lumag> steev, thanks! sounds great

15:14 <marc|gonzalez> bamse: jhugo: bryanodonoghue: I have changed the msm8998 MMCC commit message to include the output of mpv showing broken/unbroken

15:15 <bryanodonoghue> cool - how about the end of stream and critical err message from firmware ?

15:15 <marc|gonzalez> On it right now :)

15:15 <marc|gonzalez> I mean: trying to get the debug logs right now :p

15:16 <marc|gonzalez> I'm also seeing a probably related issue:

15:16 <bryanodonoghue> I suspect the critical err message is a result of HFI_3XX firmware not understanding a message sent to it.. ?

15:16 <marc|gonzalez> when the decode fails because the clocks are fubared, mpv hangs even if I specify a decode length

15:17 <bryanodonoghue> ah so you still get decode failure then /

15:17 <bryanodonoghue> hangs = the application hangs or the board hangs ?

15:19 <marc|gonzalez> I was unclear

15:19 <marc|gonzalez> I tested BEFORE/AFTER patch

15:19 <marc|gonzalez> BEFORE = clocks are fubared

15:20 <marc|gonzalez> BEFORE = mpv hangs when decode fails

15:20 <marc|gonzalez> Might not worth understanding why mpv hangs in an error situation

15:27 <jhugo> marc|gonzalez: saw it hit my mailbox. "upstream day" is tomorrow for me. I anticipate reviewing then

15:27 <marc|gonzalez> jhugo: code is unchanged FWIW ;)

15:27 <marc|gonzalez> Will try sending the associated DT changes this evening

15:29 <marc|gonzalez> bryanodonoghue: errrr, running venus with debug enabled rebooted my system...

15:30 <marc|gonzalez> digging...

15:31 <bryanodonoghue> marc|gonzalez what kernel are you running ?

15:31 <marc|gonzalez> 6.9-rc1

15:57 <marc|gonzalez> phh pointed out that the target is dumping so much stuff over the 115200bps console that it's probably keeping "something" busy too long and triggering a watchdog bite.

16:06 <marc|gonzalez> I'm going to need a MUCH bigger ring buffer...

16:55 <marc|gonzalez> log_buf_len=16777216 :)