10:23 <mmind00> detlevc: am I seeing things right, that the media people applied patches 1,2,7,8 from your rkvdec series?

10:24 <mmind00> (neither my inbox, nor the mailinglist got any applied messages)

10:24 <mmind00> but I see them in https://git.linuxtv.org/media.git/log/

12:42 <diederik> <rant>It seems they don't do "Applied, thanks!" messages. Only way to find out is checking their repo</rant>

12:44 <TahomaSoft> Hi, I have a couple of strategy questions for using b4: (1) What do I do if it bombs {raise JSONDecodeError("Extra data", s, end) for example}; (2) If I need to manually advance the PATCH version because of my previous flubs, is there a way to do that?

12:44 <diederik> (so me testing it to provide a Tested-by tag was a complete waste of time)

12:46 <qschulz> diederik: nope because if you'd had discovered a bug, we would have known "Early" and could have worked on a fixup patch :)

12:47 <qschulz> TahomaSoft: I've never had this JSONDecodeError before... are you using b4 from your distro's package feed or from pip directly?

12:47 <qschulz> I would recommend the latter

12:47 <TahomaSoft> @qshulz using pip directly.

12:47 <a3f> Debian b4 is no good has been my experience as well

12:48 <qschulz> TahomaSoft: for the version, probably b4 prep --force-revision N

12:48 <qschulz> though you may need to delete the tag that b4 creates when it sends the series (or attempts to in your case?_

12:50 <TahomaSoft> Thanks qschultz on the --force-revision N. I'll give that a try. I setup a little sandbox to safely try this stuff out and only email it to myself.

13:12 <qschulz> TahomaSoft: that should be doable with b4 send --reflect?

13:31 <diederik> qschulz: there were no new bugs thus the unstaging didn't cause a regression ;-)

13:51 <detlevc> mmind00: Yes, All I got was an email from patchwork saying they were accepted

13:55 <mmind00> detlevc: ok, thanks for confirming my reading ... so I'll queue the dts patches ... and I guess "someone" will look at the core media patches at "some" time :-)

13:59 <diederik> robmur01: https://paste.sr.ht/~diederik/ade82c93a7df3357714773cfd2f92317f3c59680 serial output with locking details (patch Adrian linked to seems to fix the OOPS)

13:59 <detlevc> mmind00: there are already some changes that are soon ready to go (need some documentation updates) on the core parts

15:05 <robmur01> diederik: Ooh, fun! Looks like a slightly longer dependency cycle than the one you were actually hitting (where if register_netdevice_notifier() does get pernet_ops_rwsem it then immediately tries to take rtnl_mutex), but lockdep only reports the first issue it sees

15:07 <robmur01> at least the stacktraces are sufficiently similar to yours to demonstrate there's a real-world issue here

16:00 <TahomaSoft> qschultz Good idea! Thank you.

18:47 <diederik> robmur01: what I noticed later is that I didn't hit the hung task problem and I could therefor ssh into my NanoPi-R5S

18:49 <diederik> Do you understand what Adrian meant in his reply to me? https://lore.kernel.org/linux-rockchip/30cb2e71-5e0b-4fa0-b0e0-3263d9aa8712@intel.com/

18:50 <diederik> I understand that the last patch in that patch set removes the function as all clients have been removed, but that doesn't look like a requirement for drivers/mmc/host/sdhci-of-dwcmshc.c to me?