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:
no delay
CPU0 CPU1 request_irq(IRQF_ONESHOT) request_irq(IRQF_COND_ONESHOT)
delay
CPU0 CPU1 request_irq(IRQF_COND_ONESHOT) request_irq(IRQF_ONESHOT)
In this case the request on CPU 0 fails with -EBUSY ...
Confused
More 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 setNeither #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 {