On 8/5/24 05:51, Thomas Gleixner wrote:
On Mon, Aug 05 2024 at 10:56, Thomas Gleixner wrote:If this is really a race then the following must be true: 1) no delay CPU0 CPU1 request_irq(IRQF_ONESHOT) request_irq(IRQF_COND_ONESHOT) 2) delay CPU0 CPU1 request_irq(IRQF_COND_ONESHOT) request_irq(IRQF_ONESHOT) In this case the request on CPU 0 fails with -EBUSY ... ConfusedMore confusing: Adding a printk() in setup_irq() - using the config, rootfs and the run.sh script from: http://server.roeck-us.net/qemu/parisc64-6.1.5/ results in: [ 0.000000] genirq: 64 flags: 00215600 [ 0.000000] genirq: 65 flags: 00200400 [ 8.110946] genirq: 66 flags: 00200080 IRQF_ONESHOT is 0x2000 which is not set by any of the interrupt requests. IRQF_COND_ONESHOT has only an effect when 1) Interrupt is shared 2) First interrupt request has IRQF_ONESHOT set Neither #1 nor #2 are true, but maybe your current config enables some moar devices than the one on your website.
No, it is pretty much the same, except for a more recent C compiler, and it requires qemu v9.0. See http://server.roeck-us.net/qemu/parisc64-6.10.3/. Debugging shows pretty much the same for me, and any log message added to request_irq() makes the problem go away (or be different), and if the problem is seen it doesn't even get to the third interrupt request. I copied a more complete log to bad.log.gz in above page. Below is yet another "fix" of the problem, just as puzzling as the other "fix". Guenter --- diff --git a/arch/parisc/kernel/time.c b/arch/parisc/kernel/time.c index 9714fbd7c42d..9707914c1a62 100644 --- a/arch/parisc/kernel/time.c +++ b/arch/parisc/kernel/time.c @@ -75,6 +75,8 @@ irqreturn_t __irq_entry timer_interrupt(int irq, void *dev_id) /* Initialize next_tick to the old expected tick time. */ next_tick = cpuinfo->it_value; + pr_info_once("####### First timer interrupt\n"); + /* Calculate how many ticks have elapsed. */ now = mfctl(16); do {
