The alternative theory here is that this is always breaking at sbi_send_cpumask_ipi, which is being patched at:
ffffffe0000091e2: fffff097 auipc ra,0xfffff ffffffe0000091e6: dfe080e7 jalr -514(ra) # ffffffe000007fe0 <ftrace_stub> I even found ffffffe0000091e2 as one of the addresses being patched (look at __start_mcount_loc). And it happens that the patching code will end up calling flush_icache_range (which is really flush_icache_all). That, in turn, will end up doing some form of IPI. So, possibly there is a race involved here, where the IPI code is being executed after it is patched, but before icache is flushed. It's hard to think that this segment lies inside a cache boundary, but there is certainly something else necessary for the sync here. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1934548 Title: RISC-V: Illegal instruction To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-riscv/+bug/1934548/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
