07:46 <geertu> arnd: saw https://lore.kernel.org/all/trinity-3d43505a-735f-402f-8b14-90a32b289a0c-1652773898430@3c-app-mailcom-bs07/? #y2038

07:47 <milkylainen> 5.18 vanilla dts, stm32mp1: stm32_rtc 5c004000.rtc: error -ENXIO: IRQ index 1 not found

07:47 <milkylainen> anyone?

07:47 <milkylainen> It's the dk2 board to be more specific.

07:52 <arnd> geertu: no, I did not see that. Not sure if 2038 support in glibc is complete enough to allow this. Maybe he was using some library that was built without time64 support. Otherwise it's probably an application bug.

07:53 <geertu> arnd: I noticed because his ping ended up in gmail spam ;-)

08:43 <ardb> arnd: tmlind, not sure whether this explains anything, but all the NMI backtraces shared by Yegor point to omap3_noncore_dpll_program()

10:17 <Xogium> huh, scary business

10:17 <Xogium> etnaviv-gpu 59000000.gpu: MMU fault status 0x00000002

10:17 <Xogium> etnaviv-gpu 59000000.gpu: MMU 0 fault addr 0xff957000

10:18 <Xogium> etnaviv-gpu 59000000.gpu: recover hung GPU!

10:21 <Xogium> first time I see that.. I just touched some random places on a touchscreen and boom

12:02 <arnd> ardb: indeed, that does not seem to be an accident. so in each case, the timer interrupt comes in somehwere in the middle of omap3_noncore_dpll_program(), but not the exact same place

12:02 <arnd> and at that point it's been around 2600 ticks since the previous GP

14:41 <arnd> ardb: at least we have a confirmation now that "ARM: implement THREAD_INFO_IN_TASK for uniprocessor system" caused the stall, rather than just assuming it was

14:57 <ardb> arnd: indeed. and given that the stall does not occur on !SMP, it should be related to the SMP_ON_UP patching in some way

14:58 <ardb> although i'm not sure how exactly

14:59 <arnd> ardb: could the problem be __ldst_va? The comment says that it only works for 256MB offsets, and I wonder if something might cause a module to be loaded further away that than. vmalloc space is probably big enough if the physical RAM is small

15:00 <ardb> arnd: the group relocations are not used when MODULE and CONFIG_ARM_MODULE_PLTS are #define'd

15:06 <arnd> ardb: I was looking at the asm/assembler.h version, thinking it might be used in the kernel to refer to a symbol from a module, but of course that wouldn't happen either

15:06 <ardb> arnd: no it's always the other way around

15:07 <ardb> but that does mean the SMP_ON_UP() patching of module code might be implicated here

15:07 <ardb> i'll have a look at the ftdi and slcan modules

15:09 <Xogium> did anyone ever see that sort of error I showed earlier with etnaviv ? Would it be safe to assume this is a kernel side issue, or could it be userspace triggering this ? Also, since when do gpu have a mmu ?

15:18 <arnd> ardb: is there anything in "ARM: implement THREAD_INFO_IN_TASK for uniprocessor systems" that stops the !CONFIG_IRQSTACKS config from working?

15:18 <arnd> I see it still builds either way, and the #ifdef checks are all still there, just the Kconfig option is not user-visible any more

15:18 <ardb> yeah those could be dropped i suppose

15:19 <ardb> disabling that should work as expected afaik

15:19 <arnd> I was thinking for him to try running without IRQSTACKS to rule that out as a source of problems

15:19 <arnd> ok, I've pushed the branch now, will ask him to retest without that

15:28 <Xogium> apparently I just hit this bug at random with this gpu

15:28 <Xogium> I dunno why or what's going on

15:52 <arnd> ardb: there is one suspicious bit about the backtrace that I can't stop thinking about: the omap3_noncore_dpll_program() function was interrupted by a hardirq (not sure which) that caused a softirq, both of which run on the irq stack. but as soon as the softirq enables interrupts, another hardirq (definitely timer) happens again, and this one causes yet another softirq to run

15:53 <arnd> so the irq stack at this point contains two hardirqs and two softirqs, which sounds like too much of a coincidence to be unrelated to the problem, but I don't see the connection to the SMP+v6 config

15:56 <arnd> oh, and the irq stack starts at 0xd000000-0xd0001ff8, which again looks like an awfully suspicious value, is that where you would expect it to be, or is that an indication that the irq stack pointer is incorrectly loaded from percpu data?

16:03 <ardb> i'm not seeing the second softirq

16:04 <ardb> the NMI backtrace is triggered by a hard IRQ taken while __do_softirq() is active

16:07 <ardb> and crash2.txt does not have the softirq at all

16:16 <arnd> ardb: I was thinking of the second softirq in hrtimer_interrupt() calling raise_softirq_irqoff() just before __hrtimer_run_queues(), but your are probably right that this does not actually run it but just asks for it being run at the next opportunity, not actually running it

16:19 <arnd> you are definitely correct that the chrash2.txt does not have the first softirq in its backtrace, it would only get there after returning from handle_arch_irq()/handle_irq_desc()

16:21 <ardb> yes so omap3_noncore_dpll_program() is the only thing these traces seem to have in common

16:22 <ardb> but i can see how reprogramming a PLL repeatedly on an otherwise stalled/idle system could take up a disproportional amount of time

16:57 <arnd> but 1.6 seconds?

16:58 <arnd> sorry, 2.6s

16:59 <ardb> all we know is that we never make it to an idle period, right?

17:00 <ardb> unless it is 'current' itself that is getting out of sync in some way? just clutching at straws here