spurious interrupts from a gpio interrupt line #5214
Assignees
Comments
|
I've just seen this issue - I can't find any GitHub notification for it, no idea what happened. Will investigate. |
|
Thanks. Let me know if some more information and/or test is needed.
…On 10/28/22 12:56 PM, Phil Elwell wrote:
I've just seen this issue - I can't find any GitHub notification for
it, no idea what happened. Will investigate.
—
Reply to this email directly, view it on GitHub
<#5214 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/A3V45ZN5TECYLR25AXZUPUTWFOWMFANCNFSM6AAAAAARQ6ROX4>.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
|
Hi, any updates on this issue? I am experiencing some similar issue after going from 32Bit to 64Bit |
|
I'm away from the office and my notes for a while, but from memory I did see the effect and couldn't see where it was coming from. |
|
Here are the results of a new test made using the latest available 64 bit system, namely the 2023-05-03-raspios-bullseye-arm64.img. The test has been repeated twice, using the irqflow and irqlevel modules described in https://github.com/marcarla/RPi_gpio_interrupt_check. In both tests a stream of interrupts with a 500 us cadence has been generated using a 1 kHz square wave. The irqflow module used edge-triggered interrupts, as in the previous tests and the results confirmed what had already been seen: with a probability of 1 ... 2%, interrupts are delivered to the Interrupt Service Routine (ISR) twice at a distance of 2 ... 7 us. The irqlevel module used level-triggered interrupts, switching between low and high level inside the ISR. The good news is that the irqlevel module works fine: more than 15 million events processed with no duplicated interrupt. The bad news is that irqlevel seems to fall short when two or more concurrent streams are to be handled by different gpios. But this is another problem, for another time. |
|
I can see what's going wrong - a concurrency problem, with multiple cores noticing and processing a pending interrupt. It will take a bit longer to understand how this occurs, and what is the correct way to avoid it, with the option of throwing in a spinlock to serialise access to the hardware interrupts available if there's nothing neater. |
pelwell
added a commit
to pelwell/linux
that referenced
this issue
Aug 31, 2023
The commit shown in Fixes: aims to improve interrupt throughput by getting the handlers invoked on different CPU cores. It does so (*) by using an irq_ack hook to change the interrupt routing. Unfortunately, the IRQ status bits must be cleared at source, which only happens once the interrupt handler has runs - there is no easy way for one core to claim one of the IRQs before sending the remainder to the next core on the list, so waking another core immediately results in a race and the chance of both cores handling the same IRQ. It is probably for this reason that the routing change is deferred to irq_ack, but that doesn't guarantee no clashes - after irq_ack is called, control returns to bcm2836_chained_handler_irq which proceeds to check for other pending IRQs at a time when the next core is probably doing the same thing. Since the whole point of the original commit is to distribute the IRQ handling, the problem can be solved (or at least made much harder to reproduce) by changing a "while" into an "if", so that each invocation only handles one IRQ. (*) I'm not convinced it's as effective as claimed since irq_ack is called _after_ the interrupt handler, but the author thought it made a difference. See: raspberrypi#5214 raspberrypi#1794 Fixes: fd4c978 ("ARM64: Round-Robin dispatch IRQs between CPUs.") Signed-off-by: Phil Elwell <[email protected]>
pelwell
added a commit
to pelwell/linux
that referenced
this issue
Aug 31, 2023
The commit shown in Fixes: aims to improve interrupt throughput by getting the handlers invoked on different CPU cores. It does so (*) by using an irq_ack hook to change the interrupt routing. Unfortunately, the IRQ status bits must be cleared at source, which only happens once the interrupt handler has run - there is no easy way for one core to claim one of the IRQs before sending the remainder to the next core on the list, so waking another core immediately results in a race with a chance of both cores handling the same IRQ. It is probably for this reason that the routing change is deferred to irq_ack, but that doesn't guarantee no clashes - after irq_ack is called, control returns to bcm2836_chained_handler_irq which proceeds to check for other pending IRQs at a time when the next core is probably doing the same thing. Since the whole point of the original commit is to distribute the IRQ handling, there is no reason to attempt to handle multiple IRQs in one interrupt callback, so the problem can be solved (or at least made much harder to reproduce) by changing a "while" into an "if", so that each invocation only handles one IRQ. (*) I'm not convinced it's as effective as claimed since irq_ack is called _after_ the interrupt handler, but the author thought it made a difference. See: raspberrypi#5214 raspberrypi#1794 Fixes: fd4c978 ("ARM64: Round-Robin dispatch IRQs between CPUs.") Signed-off-by: Phil Elwell <[email protected]>
|
I've traced the problem to a downstream patch adding round-robin dispatch of IRQs - see #1794. By looping for additional interrupts to handle within the same IRQ it almost guarantees that, in a close group of interrupts, some of them will be executed on multiple cores. See #5589 for a potential fix. If you wait about an hour until the auto-builds have completed you'll be able to install a trial kernel with |
pelwell
added a commit
to pelwell/linux
that referenced
this issue
Aug 31, 2023
The commit shown in Fixes: aims to improve interrupt throughput by getting the handlers invoked on different CPU cores. It does so (*) by using an irq_ack hook to change the interrupt routing. Unfortunately, the IRQ status bits must be cleared at source, which only happens once the interrupt handler has run - there is no easy way for one core to claim one of the IRQs before sending the remainder to the next core on the list, so waking another core immediately results in a race with a chance of both cores handling the same IRQ. It is probably for this reason that the routing change is deferred to irq_ack, but that doesn't guarantee no clashes - after irq_ack is called, control returns to bcm2836_chained_handler_irq which proceeds to check for other pending IRQs at a time when the next core is probably doing the same thing. Since the whole point of the original commit is to distribute the IRQ handling, there is no reason to attempt to handle multiple IRQs in one interrupt callback, so the problem can be solved (or at least made much harder to reproduce) by changing a "while" into an "if", so that each invocation only handles one IRQ. (*) I'm not convinced it's as effective as claimed since irq_ack is called _after_ the interrupt handler, but the author thought it made a difference. See: raspberrypi#5214 raspberrypi#1794 Fixes: fd4c978 ("ARM64: Round-Robin dispatch IRQs between CPUs.") Signed-off-by: Phil Elwell <[email protected]>
pelwell
added a commit
to pelwell/linux
that referenced
this issue
Aug 31, 2023
The commit shown in Fixes: aims to improve interrupt throughput by getting the handlers invoked on different CPU cores. It does so (*) by using an irq_ack hook to change the interrupt routing. Unfortunately, the IRQ status bits must be cleared at source, which only happens once the interrupt handler has run - there is no easy way for one core to claim one of the IRQs before sending the remainder to the next core on the list, so waking another core immediately results in a race with a chance of both cores handling the same IRQ. It is probably for this reason that the routing change is deferred to irq_ack, but that doesn't guarantee no clashes - after irq_ack is called, control returns to bcm2836_chained_handler_irq which proceeds to check for other pending IRQs at a time when the next core is probably doing the same thing. Since the whole point of the original commit is to distribute the IRQ handling, there is no reason to attempt to handle multiple IRQs in one interrupt callback, so the problem can be solved (or at least made much harder to reproduce) by changing a "while" into an "if", so that each invocation only handles one IRQ. (*) I'm not convinced it's as effective as claimed since irq_ack is called _after_ the interrupt handler, but the author thought it made a difference. See: raspberrypi#5214 raspberrypi#1794 Fixes: fd4c978 ("ARM64: Round-Robin dispatch IRQs between CPUs.") Signed-off-by: Phil Elwell <[email protected]>
|
Thanks for the proposed fix; I would like to test it; already made rpi-update (succesfully, I hope), but I need the linux-headers-6.1.47-v8 package to recompile the test module, and was not able to find it. Any help? |
|
I've bundled together the kernel headers (installed into ./usr/include) and pre-built versions of the irqtest and irqflow modules. I hope you get something usable from one or more of those. Download the tgz here: https://drive.google.com/file/d/1paayTNGw6303aa37lsm6GtnInpSzhPb0/view?usp=sharing |
pelwell
added a commit
that referenced
this issue
Sep 1, 2023
The commit shown in Fixes: aims to improve interrupt throughput by getting the handlers invoked on different CPU cores. It does so (*) by using an irq_ack hook to change the interrupt routing. Unfortunately, the IRQ status bits must be cleared at source, which only happens once the interrupt handler has run - there is no easy way for one core to claim one of the IRQs before sending the remainder to the next core on the list, so waking another core immediately results in a race with a chance of both cores handling the same IRQ. It is probably for this reason that the routing change is deferred to irq_ack, but that doesn't guarantee no clashes - after irq_ack is called, control returns to bcm2836_chained_handler_irq which proceeds to check for other pending IRQs at a time when the next core is probably doing the same thing. Since the whole point of the original commit is to distribute the IRQ handling, there is no reason to attempt to handle multiple IRQs in one interrupt callback, so the problem can be solved (or at least made much harder to reproduce) by changing a "while" into an "if", so that each invocation only handles one IRQ. (*) I'm not convinced it's as effective as claimed since irq_ack is called _after_ the interrupt handler, but the author thought it made a difference. See: #5214 #1794 Fixes: fd4c978 ("ARM64: Round-Robin dispatch IRQs between CPUs.") Signed-off-by: Phil Elwell <[email protected]>
pelwell
added a commit
that referenced
this issue
Sep 1, 2023
The commit shown in Fixes: aims to improve interrupt throughput by getting the handlers invoked on different CPU cores. It does so (*) by using an irq_ack hook to change the interrupt routing. Unfortunately, the IRQ status bits must be cleared at source, which only happens once the interrupt handler has run - there is no easy way for one core to claim one of the IRQs before sending the remainder to the next core on the list, so waking another core immediately results in a race with a chance of both cores handling the same IRQ. It is probably for this reason that the routing change is deferred to irq_ack, but that doesn't guarantee no clashes - after irq_ack is called, control returns to bcm2836_chained_handler_irq which proceeds to check for other pending IRQs at a time when the next core is probably doing the same thing. Since the whole point of the original commit is to distribute the IRQ handling, there is no reason to attempt to handle multiple IRQs in one interrupt callback, so the problem can be solved (or at least made much harder to reproduce) by changing a "while" into an "if", so that each invocation only handles one IRQ. (*) I'm not convinced it's as effective as claimed since irq_ack is called _after_ the interrupt handler, but the author thought it made a difference. See: #5214 #1794 Fixes: fd4c978 ("ARM64: Round-Robin dispatch IRQs between CPUs.") Signed-off-by: Phil Elwell <[email protected]>
pelwell
added a commit
that referenced
this issue
Sep 1, 2023
The commit shown in Fixes: aims to improve interrupt throughput by getting the handlers invoked on different CPU cores. It does so (*) by using an irq_ack hook to change the interrupt routing. Unfortunately, the IRQ status bits must be cleared at source, which only happens once the interrupt handler has run - there is no easy way for one core to claim one of the IRQs before sending the remainder to the next core on the list, so waking another core immediately results in a race with a chance of both cores handling the same IRQ. It is probably for this reason that the routing change is deferred to irq_ack, but that doesn't guarantee no clashes - after irq_ack is called, control returns to bcm2836_chained_handler_irq which proceeds to check for other pending IRQs at a time when the next core is probably doing the same thing. Since the whole point of the original commit is to distribute the IRQ handling, there is no reason to attempt to handle multiple IRQs in one interrupt callback, so the problem can be solved (or at least made much harder to reproduce) by changing a "while" into an "if", so that each invocation only handles one IRQ. (*) I'm not convinced it's as effective as claimed since irq_ack is called _after_ the interrupt handler, but the author thought it made a difference. See: #5214 #1794 Fixes: fd4c978 ("ARM64: Round-Robin dispatch IRQs between CPUs.") Signed-off-by: Phil Elwell <[email protected]>
|
Sorry, I could not have anything working. insmod of the modules fails with: insmod: ERROR: could not insert module irqflow.ko: Invalid module format with uname -a giving: Linux raspberrypi 6.1.47-v8+ #1 SMP PREEMPT Thu Aug 31 17:36:25 UTC 2023 aarch64 GNU/Linux The kernel headers appear to be only a subset of the full kernel headers tree, hence the module compilation fails. Am I missing something? |
|
The headers were created with |
popcornmix
pushed a commit
that referenced
this issue
Sep 5, 2023
The commit shown in Fixes: aims to improve interrupt throughput by getting the handlers invoked on different CPU cores. It does so (*) by using an irq_ack hook to change the interrupt routing. Unfortunately, the IRQ status bits must be cleared at source, which only happens once the interrupt handler has run - there is no easy way for one core to claim one of the IRQs before sending the remainder to the next core on the list, so waking another core immediately results in a race with a chance of both cores handling the same IRQ. It is probably for this reason that the routing change is deferred to irq_ack, but that doesn't guarantee no clashes - after irq_ack is called, control returns to bcm2836_chained_handler_irq which proceeds to check for other pending IRQs at a time when the next core is probably doing the same thing. Since the whole point of the original commit is to distribute the IRQ handling, there is no reason to attempt to handle multiple IRQs in one interrupt callback, so the problem can be solved (or at least made much harder to reproduce) by changing a "while" into an "if", so that each invocation only handles one IRQ. (*) I'm not convinced it's as effective as claimed since irq_ack is called _after_ the interrupt handler, but the author thought it made a difference. See: #5214 #1794 Fixes: fd4c978 ("ARM64: Round-Robin dispatch IRQs between CPUs.") Signed-off-by: Phil Elwell <[email protected]>
popcornmix
pushed a commit
that referenced
this issue
Sep 5, 2023
The commit shown in Fixes: aims to improve interrupt throughput by getting the handlers invoked on different CPU cores. It does so (*) by using an irq_ack hook to change the interrupt routing. Unfortunately, the IRQ status bits must be cleared at source, which only happens once the interrupt handler has run - there is no easy way for one core to claim one of the IRQs before sending the remainder to the next core on the list, so waking another core immediately results in a race with a chance of both cores handling the same IRQ. It is probably for this reason that the routing change is deferred to irq_ack, but that doesn't guarantee no clashes - after irq_ack is called, control returns to bcm2836_chained_handler_irq which proceeds to check for other pending IRQs at a time when the next core is probably doing the same thing. Since the whole point of the original commit is to distribute the IRQ handling, there is no reason to attempt to handle multiple IRQs in one interrupt callback, so the problem can be solved (or at least made much harder to reproduce) by changing a "while" into an "if", so that each invocation only handles one IRQ. (*) I'm not convinced it's as effective as claimed since irq_ack is called _after_ the interrupt handler, but the author thought it made a difference. See: #5214 #1794 Fixes: fd4c978 ("ARM64: Round-Robin dispatch IRQs between CPUs.") Signed-off-by: Phil Elwell <[email protected]>
popcornmix
pushed a commit
that referenced
this issue
Sep 8, 2023
The commit shown in Fixes: aims to improve interrupt throughput by getting the handlers invoked on different CPU cores. It does so (*) by using an irq_ack hook to change the interrupt routing. Unfortunately, the IRQ status bits must be cleared at source, which only happens once the interrupt handler has run - there is no easy way for one core to claim one of the IRQs before sending the remainder to the next core on the list, so waking another core immediately results in a race with a chance of both cores handling the same IRQ. It is probably for this reason that the routing change is deferred to irq_ack, but that doesn't guarantee no clashes - after irq_ack is called, control returns to bcm2836_chained_handler_irq which proceeds to check for other pending IRQs at a time when the next core is probably doing the same thing. Since the whole point of the original commit is to distribute the IRQ handling, there is no reason to attempt to handle multiple IRQs in one interrupt callback, so the problem can be solved (or at least made much harder to reproduce) by changing a "while" into an "if", so that each invocation only handles one IRQ. (*) I'm not convinced it's as effective as claimed since irq_ack is called _after_ the interrupt handler, but the author thought it made a difference. See: #5214 #1794 Fixes: fd4c978 ("ARM64: Round-Robin dispatch IRQs between CPUs.") Signed-off-by: Phil Elwell <[email protected]>
popcornmix
pushed a commit
that referenced
this issue
Sep 12, 2023
The commit shown in Fixes: aims to improve interrupt throughput by getting the handlers invoked on different CPU cores. It does so (*) by using an irq_ack hook to change the interrupt routing. Unfortunately, the IRQ status bits must be cleared at source, which only happens once the interrupt handler has run - there is no easy way for one core to claim one of the IRQs before sending the remainder to the next core on the list, so waking another core immediately results in a race with a chance of both cores handling the same IRQ. It is probably for this reason that the routing change is deferred to irq_ack, but that doesn't guarantee no clashes - after irq_ack is called, control returns to bcm2836_chained_handler_irq which proceeds to check for other pending IRQs at a time when the next core is probably doing the same thing. Since the whole point of the original commit is to distribute the IRQ handling, there is no reason to attempt to handle multiple IRQs in one interrupt callback, so the problem can be solved (or at least made much harder to reproduce) by changing a "while" into an "if", so that each invocation only handles one IRQ. (*) I'm not convinced it's as effective as claimed since irq_ack is called _after_ the interrupt handler, but the author thought it made a difference. See: #5214 #1794 Fixes: fd4c978 ("ARM64: Round-Robin dispatch IRQs between CPUs.") Signed-off-by: Phil Elwell <[email protected]>
popcornmix
pushed a commit
that referenced
this issue
Sep 13, 2023
The commit shown in Fixes: aims to improve interrupt throughput by getting the handlers invoked on different CPU cores. It does so (*) by using an irq_ack hook to change the interrupt routing. Unfortunately, the IRQ status bits must be cleared at source, which only happens once the interrupt handler has run - there is no easy way for one core to claim one of the IRQs before sending the remainder to the next core on the list, so waking another core immediately results in a race with a chance of both cores handling the same IRQ. It is probably for this reason that the routing change is deferred to irq_ack, but that doesn't guarantee no clashes - after irq_ack is called, control returns to bcm2836_chained_handler_irq which proceeds to check for other pending IRQs at a time when the next core is probably doing the same thing. Since the whole point of the original commit is to distribute the IRQ handling, there is no reason to attempt to handle multiple IRQs in one interrupt callback, so the problem can be solved (or at least made much harder to reproduce) by changing a "while" into an "if", so that each invocation only handles one IRQ. (*) I'm not convinced it's as effective as claimed since irq_ack is called _after_ the interrupt handler, but the author thought it made a difference. See: #5214 #1794 Fixes: fd4c978 ("ARM64: Round-Robin dispatch IRQs between CPUs.") Signed-off-by: Phil Elwell <[email protected]>
popcornmix
pushed a commit
that referenced
this issue
Sep 13, 2023
The commit shown in Fixes: aims to improve interrupt throughput by getting the handlers invoked on different CPU cores. It does so (*) by using an irq_ack hook to change the interrupt routing. Unfortunately, the IRQ status bits must be cleared at source, which only happens once the interrupt handler has run - there is no easy way for one core to claim one of the IRQs before sending the remainder to the next core on the list, so waking another core immediately results in a race with a chance of both cores handling the same IRQ. It is probably for this reason that the routing change is deferred to irq_ack, but that doesn't guarantee no clashes - after irq_ack is called, control returns to bcm2836_chained_handler_irq which proceeds to check for other pending IRQs at a time when the next core is probably doing the same thing. Since the whole point of the original commit is to distribute the IRQ handling, there is no reason to attempt to handle multiple IRQs in one interrupt callback, so the problem can be solved (or at least made much harder to reproduce) by changing a "while" into an "if", so that each invocation only handles one IRQ. (*) I'm not convinced it's as effective as claimed since irq_ack is called _after_ the interrupt handler, but the author thought it made a difference. See: #5214 #1794 Fixes: fd4c978 ("ARM64: Round-Robin dispatch IRQs between CPUs.") Signed-off-by: Phil Elwell <[email protected]>
popcornmix
pushed a commit
that referenced
this issue
Sep 19, 2023
IRQ-CPU mapping is round robined on ARM64 to increase concurrency and allow multiple interrupts to be serviced at a time. This reduces the need for FIQ. Signed-off-by: Michael Zoran <[email protected]> drivers: irqchip: irq-bcm2835: Concurrency fix The commit shown in Fixes: aims to improve interrupt throughput by getting the handlers invoked on different CPU cores. It does so (*) by using an irq_ack hook to change the interrupt routing. Unfortunately, the IRQ status bits must be cleared at source, which only happens once the interrupt handler has run - there is no easy way for one core to claim one of the IRQs before sending the remainder to the next core on the list, so waking another core immediately results in a race with a chance of both cores handling the same IRQ. It is probably for this reason that the routing change is deferred to irq_ack, but that doesn't guarantee no clashes - after irq_ack is called, control returns to bcm2836_chained_handler_irq which proceeds to check for other pending IRQs at a time when the next core is probably doing the same thing. Since the whole point of the original commit is to distribute the IRQ handling, there is no reason to attempt to handle multiple IRQs in one interrupt callback, so the problem can be solved (or at least made much harder to reproduce) by changing a "while" into an "if", so that each invocation only handles one IRQ. (*) I'm not convinced it's as effective as claimed since irq_ack is called _after_ the interrupt handler, but the author thought it made a difference. See: #5214 #1794 Fixes: fd4c978 ("ARM64: Round-Robin dispatch IRQs between CPUs.") Signed-off-by: Phil Elwell <[email protected]>
popcornmix
pushed a commit
that referenced
this issue
Sep 19, 2023
The commit shown in Fixes: aims to improve interrupt throughput by getting the handlers invoked on different CPU cores. It does so (*) by using an irq_ack hook to change the interrupt routing. Unfortunately, the IRQ status bits must be cleared at source, which only happens once the interrupt handler has run - there is no easy way for one core to claim one of the IRQs before sending the remainder to the next core on the list, so waking another core immediately results in a race with a chance of both cores handling the same IRQ. It is probably for this reason that the routing change is deferred to irq_ack, but that doesn't guarantee no clashes - after irq_ack is called, control returns to bcm2836_chained_handler_irq which proceeds to check for other pending IRQs at a time when the next core is probably doing the same thing. Since the whole point of the original commit is to distribute the IRQ handling, there is no reason to attempt to handle multiple IRQs in one interrupt callback, so the problem can be solved (or at least made much harder to reproduce) by changing a "while" into an "if", so that each invocation only handles one IRQ. (*) I'm not convinced it's as effective as claimed since irq_ack is called _after_ the interrupt handler, but the author thought it made a difference. See: #5214 #1794 Fixes: fd4c978 ("ARM64: Round-Robin dispatch IRQs between CPUs.") Signed-off-by: Phil Elwell <[email protected]>
popcornmix
pushed a commit
that referenced
this issue
Sep 25, 2023
IRQ-CPU mapping is round robined on ARM64 to increase concurrency and allow multiple interrupts to be serviced at a time. This reduces the need for FIQ. Signed-off-by: Michael Zoran <[email protected]> drivers: irqchip: irq-bcm2835: Concurrency fix The commit shown in Fixes: aims to improve interrupt throughput by getting the handlers invoked on different CPU cores. It does so (*) by using an irq_ack hook to change the interrupt routing. Unfortunately, the IRQ status bits must be cleared at source, which only happens once the interrupt handler has run - there is no easy way for one core to claim one of the IRQs before sending the remainder to the next core on the list, so waking another core immediately results in a race with a chance of both cores handling the same IRQ. It is probably for this reason that the routing change is deferred to irq_ack, but that doesn't guarantee no clashes - after irq_ack is called, control returns to bcm2836_chained_handler_irq which proceeds to check for other pending IRQs at a time when the next core is probably doing the same thing. Since the whole point of the original commit is to distribute the IRQ handling, there is no reason to attempt to handle multiple IRQs in one interrupt callback, so the problem can be solved (or at least made much harder to reproduce) by changing a "while" into an "if", so that each invocation only handles one IRQ. (*) I'm not convinced it's as effective as claimed since irq_ack is called _after_ the interrupt handler, but the author thought it made a difference. See: #5214 #1794 Fixes: fd4c978 ("ARM64: Round-Robin dispatch IRQs between CPUs.") Signed-off-by: Phil Elwell <[email protected]>
popcornmix
pushed a commit
that referenced
this issue
Sep 25, 2023
The commit shown in Fixes: aims to improve interrupt throughput by getting the handlers invoked on different CPU cores. It does so (*) by using an irq_ack hook to change the interrupt routing. Unfortunately, the IRQ status bits must be cleared at source, which only happens once the interrupt handler has run - there is no easy way for one core to claim one of the IRQs before sending the remainder to the next core on the list, so waking another core immediately results in a race with a chance of both cores handling the same IRQ. It is probably for this reason that the routing change is deferred to irq_ack, but that doesn't guarantee no clashes - after irq_ack is called, control returns to bcm2836_chained_handler_irq which proceeds to check for other pending IRQs at a time when the next core is probably doing the same thing. Since the whole point of the original commit is to distribute the IRQ handling, there is no reason to attempt to handle multiple IRQs in one interrupt callback, so the problem can be solved (or at least made much harder to reproduce) by changing a "while" into an "if", so that each invocation only handles one IRQ. (*) I'm not convinced it's as effective as claimed since irq_ack is called _after_ the interrupt handler, but the author thought it made a difference. See: #5214 #1794 Fixes: fd4c978 ("ARM64: Round-Robin dispatch IRQs between CPUs.") Signed-off-by: Phil Elwell <[email protected]>
popcornmix
pushed a commit
that referenced
this issue
Aug 27, 2024
IRQ-CPU mapping is round robined on ARM64 to increase concurrency and allow multiple interrupts to be serviced at a time. This reduces the need for FIQ. Signed-off-by: Michael Zoran <[email protected]> drivers: irqchip: irq-bcm2835: Concurrency fix The commit shown in Fixes: aims to improve interrupt throughput by getting the handlers invoked on different CPU cores. It does so (*) by using an irq_ack hook to change the interrupt routing. Unfortunately, the IRQ status bits must be cleared at source, which only happens once the interrupt handler has run - there is no easy way for one core to claim one of the IRQs before sending the remainder to the next core on the list, so waking another core immediately results in a race with a chance of both cores handling the same IRQ. It is probably for this reason that the routing change is deferred to irq_ack, but that doesn't guarantee no clashes - after irq_ack is called, control returns to bcm2836_chained_handler_irq which proceeds to check for other pending IRQs at a time when the next core is probably doing the same thing. Since the whole point of the original commit is to distribute the IRQ handling, there is no reason to attempt to handle multiple IRQs in one interrupt callback, so the problem can be solved (or at least made much harder to reproduce) by changing a "while" into an "if", so that each invocation only handles one IRQ. (*) I'm not convinced it's as effective as claimed since irq_ack is called _after_ the interrupt handler, but the author thought it made a difference. See: #5214 #1794 Fixes: fd4c978 ("ARM64: Round-Robin dispatch IRQs between CPUs.") Signed-off-by: Phil Elwell <[email protected]> irqchip: irq-bcm2836: Avoid prototype warning Declare bcm2836_arm_irqchip_spin_gpu_irq in irq-bcm2836.h to avoid a compiler warning about a missing prototype. Signed-off-by: Phil Elwell <[email protected]>
popcornmix
pushed a commit
that referenced
this issue
Aug 30, 2024
IRQ-CPU mapping is round robined on ARM64 to increase concurrency and allow multiple interrupts to be serviced at a time. This reduces the need for FIQ. Signed-off-by: Michael Zoran <[email protected]> drivers: irqchip: irq-bcm2835: Concurrency fix The commit shown in Fixes: aims to improve interrupt throughput by getting the handlers invoked on different CPU cores. It does so (*) by using an irq_ack hook to change the interrupt routing. Unfortunately, the IRQ status bits must be cleared at source, which only happens once the interrupt handler has run - there is no easy way for one core to claim one of the IRQs before sending the remainder to the next core on the list, so waking another core immediately results in a race with a chance of both cores handling the same IRQ. It is probably for this reason that the routing change is deferred to irq_ack, but that doesn't guarantee no clashes - after irq_ack is called, control returns to bcm2836_chained_handler_irq which proceeds to check for other pending IRQs at a time when the next core is probably doing the same thing. Since the whole point of the original commit is to distribute the IRQ handling, there is no reason to attempt to handle multiple IRQs in one interrupt callback, so the problem can be solved (or at least made much harder to reproduce) by changing a "while" into an "if", so that each invocation only handles one IRQ. (*) I'm not convinced it's as effective as claimed since irq_ack is called _after_ the interrupt handler, but the author thought it made a difference. See: #5214 #1794 Fixes: fd4c978 ("ARM64: Round-Robin dispatch IRQs between CPUs.") Signed-off-by: Phil Elwell <[email protected]> irqchip: irq-bcm2836: Avoid prototype warning Declare bcm2836_arm_irqchip_spin_gpu_irq in irq-bcm2836.h to avoid a compiler warning about a missing prototype. Signed-off-by: Phil Elwell <[email protected]>
popcornmix
pushed a commit
that referenced
this issue
Aug 30, 2024
IRQ-CPU mapping is round robined on ARM64 to increase concurrency and allow multiple interrupts to be serviced at a time. This reduces the need for FIQ. Signed-off-by: Michael Zoran <[email protected]> drivers: irqchip: irq-bcm2835: Concurrency fix The commit shown in Fixes: aims to improve interrupt throughput by getting the handlers invoked on different CPU cores. It does so (*) by using an irq_ack hook to change the interrupt routing. Unfortunately, the IRQ status bits must be cleared at source, which only happens once the interrupt handler has run - there is no easy way for one core to claim one of the IRQs before sending the remainder to the next core on the list, so waking another core immediately results in a race with a chance of both cores handling the same IRQ. It is probably for this reason that the routing change is deferred to irq_ack, but that doesn't guarantee no clashes - after irq_ack is called, control returns to bcm2836_chained_handler_irq which proceeds to check for other pending IRQs at a time when the next core is probably doing the same thing. Since the whole point of the original commit is to distribute the IRQ handling, there is no reason to attempt to handle multiple IRQs in one interrupt callback, so the problem can be solved (or at least made much harder to reproduce) by changing a "while" into an "if", so that each invocation only handles one IRQ. (*) I'm not convinced it's as effective as claimed since irq_ack is called _after_ the interrupt handler, but the author thought it made a difference. See: #5214 #1794 Fixes: fd4c978 ("ARM64: Round-Robin dispatch IRQs between CPUs.") Signed-off-by: Phil Elwell <[email protected]> irqchip: irq-bcm2836: Avoid prototype warning Declare bcm2836_arm_irqchip_spin_gpu_irq in irq-bcm2836.h to avoid a compiler warning about a missing prototype. Signed-off-by: Phil Elwell <[email protected]>
popcornmix
pushed a commit
that referenced
this issue
Sep 2, 2024
IRQ-CPU mapping is round robined on ARM64 to increase concurrency and allow multiple interrupts to be serviced at a time. This reduces the need for FIQ. Signed-off-by: Michael Zoran <[email protected]> drivers: irqchip: irq-bcm2835: Concurrency fix The commit shown in Fixes: aims to improve interrupt throughput by getting the handlers invoked on different CPU cores. It does so (*) by using an irq_ack hook to change the interrupt routing. Unfortunately, the IRQ status bits must be cleared at source, which only happens once the interrupt handler has run - there is no easy way for one core to claim one of the IRQs before sending the remainder to the next core on the list, so waking another core immediately results in a race with a chance of both cores handling the same IRQ. It is probably for this reason that the routing change is deferred to irq_ack, but that doesn't guarantee no clashes - after irq_ack is called, control returns to bcm2836_chained_handler_irq which proceeds to check for other pending IRQs at a time when the next core is probably doing the same thing. Since the whole point of the original commit is to distribute the IRQ handling, there is no reason to attempt to handle multiple IRQs in one interrupt callback, so the problem can be solved (or at least made much harder to reproduce) by changing a "while" into an "if", so that each invocation only handles one IRQ. (*) I'm not convinced it's as effective as claimed since irq_ack is called _after_ the interrupt handler, but the author thought it made a difference. See: #5214 #1794 Fixes: fd4c978 ("ARM64: Round-Robin dispatch IRQs between CPUs.") Signed-off-by: Phil Elwell <[email protected]> irqchip: irq-bcm2836: Avoid prototype warning Declare bcm2836_arm_irqchip_spin_gpu_irq in irq-bcm2836.h to avoid a compiler warning about a missing prototype. Signed-off-by: Phil Elwell <[email protected]>
popcornmix
pushed a commit
that referenced
this issue
Sep 6, 2024
IRQ-CPU mapping is round robined on ARM64 to increase concurrency and allow multiple interrupts to be serviced at a time. This reduces the need for FIQ. Signed-off-by: Michael Zoran <[email protected]> drivers: irqchip: irq-bcm2835: Concurrency fix The commit shown in Fixes: aims to improve interrupt throughput by getting the handlers invoked on different CPU cores. It does so (*) by using an irq_ack hook to change the interrupt routing. Unfortunately, the IRQ status bits must be cleared at source, which only happens once the interrupt handler has run - there is no easy way for one core to claim one of the IRQs before sending the remainder to the next core on the list, so waking another core immediately results in a race with a chance of both cores handling the same IRQ. It is probably for this reason that the routing change is deferred to irq_ack, but that doesn't guarantee no clashes - after irq_ack is called, control returns to bcm2836_chained_handler_irq which proceeds to check for other pending IRQs at a time when the next core is probably doing the same thing. Since the whole point of the original commit is to distribute the IRQ handling, there is no reason to attempt to handle multiple IRQs in one interrupt callback, so the problem can be solved (or at least made much harder to reproduce) by changing a "while" into an "if", so that each invocation only handles one IRQ. (*) I'm not convinced it's as effective as claimed since irq_ack is called _after_ the interrupt handler, but the author thought it made a difference. See: #5214 #1794 Fixes: fd4c978 ("ARM64: Round-Robin dispatch IRQs between CPUs.") Signed-off-by: Phil Elwell <[email protected]> irqchip: irq-bcm2836: Avoid prototype warning Declare bcm2836_arm_irqchip_spin_gpu_irq in irq-bcm2836.h to avoid a compiler warning about a missing prototype. Signed-off-by: Phil Elwell <[email protected]>
popcornmix
pushed a commit
that referenced
this issue
Sep 10, 2024
IRQ-CPU mapping is round robined on ARM64 to increase concurrency and allow multiple interrupts to be serviced at a time. This reduces the need for FIQ. Signed-off-by: Michael Zoran <[email protected]> drivers: irqchip: irq-bcm2835: Concurrency fix The commit shown in Fixes: aims to improve interrupt throughput by getting the handlers invoked on different CPU cores. It does so (*) by using an irq_ack hook to change the interrupt routing. Unfortunately, the IRQ status bits must be cleared at source, which only happens once the interrupt handler has run - there is no easy way for one core to claim one of the IRQs before sending the remainder to the next core on the list, so waking another core immediately results in a race with a chance of both cores handling the same IRQ. It is probably for this reason that the routing change is deferred to irq_ack, but that doesn't guarantee no clashes - after irq_ack is called, control returns to bcm2836_chained_handler_irq which proceeds to check for other pending IRQs at a time when the next core is probably doing the same thing. Since the whole point of the original commit is to distribute the IRQ handling, there is no reason to attempt to handle multiple IRQs in one interrupt callback, so the problem can be solved (or at least made much harder to reproduce) by changing a "while" into an "if", so that each invocation only handles one IRQ. (*) I'm not convinced it's as effective as claimed since irq_ack is called _after_ the interrupt handler, but the author thought it made a difference. See: #5214 #1794 Fixes: fd4c978 ("ARM64: Round-Robin dispatch IRQs between CPUs.") Signed-off-by: Phil Elwell <[email protected]> irqchip: irq-bcm2836: Avoid prototype warning Declare bcm2836_arm_irqchip_spin_gpu_irq in irq-bcm2836.h to avoid a compiler warning about a missing prototype. Signed-off-by: Phil Elwell <[email protected]>
popcornmix
pushed a commit
that referenced
this issue
Sep 10, 2024
IRQ-CPU mapping is round robined on ARM64 to increase concurrency and allow multiple interrupts to be serviced at a time. This reduces the need for FIQ. Signed-off-by: Michael Zoran <[email protected]> drivers: irqchip: irq-bcm2835: Concurrency fix The commit shown in Fixes: aims to improve interrupt throughput by getting the handlers invoked on different CPU cores. It does so (*) by using an irq_ack hook to change the interrupt routing. Unfortunately, the IRQ status bits must be cleared at source, which only happens once the interrupt handler has run - there is no easy way for one core to claim one of the IRQs before sending the remainder to the next core on the list, so waking another core immediately results in a race with a chance of both cores handling the same IRQ. It is probably for this reason that the routing change is deferred to irq_ack, but that doesn't guarantee no clashes - after irq_ack is called, control returns to bcm2836_chained_handler_irq which proceeds to check for other pending IRQs at a time when the next core is probably doing the same thing. Since the whole point of the original commit is to distribute the IRQ handling, there is no reason to attempt to handle multiple IRQs in one interrupt callback, so the problem can be solved (or at least made much harder to reproduce) by changing a "while" into an "if", so that each invocation only handles one IRQ. (*) I'm not convinced it's as effective as claimed since irq_ack is called _after_ the interrupt handler, but the author thought it made a difference. See: #5214 #1794 Fixes: fd4c978 ("ARM64: Round-Robin dispatch IRQs between CPUs.") Signed-off-by: Phil Elwell <[email protected]> irqchip: irq-bcm2836: Avoid prototype warning Declare bcm2836_arm_irqchip_spin_gpu_irq in irq-bcm2836.h to avoid a compiler warning about a missing prototype. Signed-off-by: Phil Elwell <[email protected]>
popcornmix
pushed a commit
that referenced
this issue
Sep 12, 2024
IRQ-CPU mapping is round robined on ARM64 to increase concurrency and allow multiple interrupts to be serviced at a time. This reduces the need for FIQ. Signed-off-by: Michael Zoran <[email protected]> drivers: irqchip: irq-bcm2835: Concurrency fix The commit shown in Fixes: aims to improve interrupt throughput by getting the handlers invoked on different CPU cores. It does so (*) by using an irq_ack hook to change the interrupt routing. Unfortunately, the IRQ status bits must be cleared at source, which only happens once the interrupt handler has run - there is no easy way for one core to claim one of the IRQs before sending the remainder to the next core on the list, so waking another core immediately results in a race with a chance of both cores handling the same IRQ. It is probably for this reason that the routing change is deferred to irq_ack, but that doesn't guarantee no clashes - after irq_ack is called, control returns to bcm2836_chained_handler_irq which proceeds to check for other pending IRQs at a time when the next core is probably doing the same thing. Since the whole point of the original commit is to distribute the IRQ handling, there is no reason to attempt to handle multiple IRQs in one interrupt callback, so the problem can be solved (or at least made much harder to reproduce) by changing a "while" into an "if", so that each invocation only handles one IRQ. (*) I'm not convinced it's as effective as claimed since irq_ack is called _after_ the interrupt handler, but the author thought it made a difference. See: #5214 #1794 Fixes: fd4c978 ("ARM64: Round-Robin dispatch IRQs between CPUs.") Signed-off-by: Phil Elwell <[email protected]> irqchip: irq-bcm2836: Avoid prototype warning Declare bcm2836_arm_irqchip_spin_gpu_irq in irq-bcm2836.h to avoid a compiler warning about a missing prototype. Signed-off-by: Phil Elwell <[email protected]>
popcornmix
pushed a commit
that referenced
this issue
Sep 16, 2024
IRQ-CPU mapping is round robined on ARM64 to increase concurrency and allow multiple interrupts to be serviced at a time. This reduces the need for FIQ. Signed-off-by: Michael Zoran <[email protected]> drivers: irqchip: irq-bcm2835: Concurrency fix The commit shown in Fixes: aims to improve interrupt throughput by getting the handlers invoked on different CPU cores. It does so (*) by using an irq_ack hook to change the interrupt routing. Unfortunately, the IRQ status bits must be cleared at source, which only happens once the interrupt handler has run - there is no easy way for one core to claim one of the IRQs before sending the remainder to the next core on the list, so waking another core immediately results in a race with a chance of both cores handling the same IRQ. It is probably for this reason that the routing change is deferred to irq_ack, but that doesn't guarantee no clashes - after irq_ack is called, control returns to bcm2836_chained_handler_irq which proceeds to check for other pending IRQs at a time when the next core is probably doing the same thing. Since the whole point of the original commit is to distribute the IRQ handling, there is no reason to attempt to handle multiple IRQs in one interrupt callback, so the problem can be solved (or at least made much harder to reproduce) by changing a "while" into an "if", so that each invocation only handles one IRQ. (*) I'm not convinced it's as effective as claimed since irq_ack is called _after_ the interrupt handler, but the author thought it made a difference. See: #5214 #1794 Fixes: fd4c978 ("ARM64: Round-Robin dispatch IRQs between CPUs.") Signed-off-by: Phil Elwell <[email protected]> irqchip: irq-bcm2836: Avoid prototype warning Declare bcm2836_arm_irqchip_spin_gpu_irq in irq-bcm2836.h to avoid a compiler warning about a missing prototype. Signed-off-by: Phil Elwell <[email protected]>
popcornmix
pushed a commit
that referenced
this issue
Oct 2, 2024
IRQ-CPU mapping is round robined on ARM64 to increase concurrency and allow multiple interrupts to be serviced at a time. This reduces the need for FIQ. Signed-off-by: Michael Zoran <[email protected]> drivers: irqchip: irq-bcm2835: Concurrency fix The commit shown in Fixes: aims to improve interrupt throughput by getting the handlers invoked on different CPU cores. It does so (*) by using an irq_ack hook to change the interrupt routing. Unfortunately, the IRQ status bits must be cleared at source, which only happens once the interrupt handler has run - there is no easy way for one core to claim one of the IRQs before sending the remainder to the next core on the list, so waking another core immediately results in a race with a chance of both cores handling the same IRQ. It is probably for this reason that the routing change is deferred to irq_ack, but that doesn't guarantee no clashes - after irq_ack is called, control returns to bcm2836_chained_handler_irq which proceeds to check for other pending IRQs at a time when the next core is probably doing the same thing. Since the whole point of the original commit is to distribute the IRQ handling, there is no reason to attempt to handle multiple IRQs in one interrupt callback, so the problem can be solved (or at least made much harder to reproduce) by changing a "while" into an "if", so that each invocation only handles one IRQ. (*) I'm not convinced it's as effective as claimed since irq_ack is called _after_ the interrupt handler, but the author thought it made a difference. See: #5214 #1794 Fixes: fd4c978 ("ARM64: Round-Robin dispatch IRQs between CPUs.") Signed-off-by: Phil Elwell <[email protected]> irqchip: irq-bcm2836: Avoid prototype warning Declare bcm2836_arm_irqchip_spin_gpu_irq in irq-bcm2836.h to avoid a compiler warning about a missing prototype. Signed-off-by: Phil Elwell <[email protected]>
popcornmix
pushed a commit
that referenced
this issue
Oct 2, 2024
IRQ-CPU mapping is round robined on ARM64 to increase concurrency and allow multiple interrupts to be serviced at a time. This reduces the need for FIQ. Signed-off-by: Michael Zoran <[email protected]> drivers: irqchip: irq-bcm2835: Concurrency fix The commit shown in Fixes: aims to improve interrupt throughput by getting the handlers invoked on different CPU cores. It does so (*) by using an irq_ack hook to change the interrupt routing. Unfortunately, the IRQ status bits must be cleared at source, which only happens once the interrupt handler has run - there is no easy way for one core to claim one of the IRQs before sending the remainder to the next core on the list, so waking another core immediately results in a race with a chance of both cores handling the same IRQ. It is probably for this reason that the routing change is deferred to irq_ack, but that doesn't guarantee no clashes - after irq_ack is called, control returns to bcm2836_chained_handler_irq which proceeds to check for other pending IRQs at a time when the next core is probably doing the same thing. Since the whole point of the original commit is to distribute the IRQ handling, there is no reason to attempt to handle multiple IRQs in one interrupt callback, so the problem can be solved (or at least made much harder to reproduce) by changing a "while" into an "if", so that each invocation only handles one IRQ. (*) I'm not convinced it's as effective as claimed since irq_ack is called _after_ the interrupt handler, but the author thought it made a difference. See: #5214 #1794 Fixes: fd4c978 ("ARM64: Round-Robin dispatch IRQs between CPUs.") Signed-off-by: Phil Elwell <[email protected]> irqchip: irq-bcm2836: Avoid prototype warning Declare bcm2836_arm_irqchip_spin_gpu_irq in irq-bcm2836.h to avoid a compiler warning about a missing prototype. Signed-off-by: Phil Elwell <[email protected]>
popcornmix
pushed a commit
that referenced
this issue
Oct 7, 2024
IRQ-CPU mapping is round robined on ARM64 to increase concurrency and allow multiple interrupts to be serviced at a time. This reduces the need for FIQ. Signed-off-by: Michael Zoran <[email protected]> drivers: irqchip: irq-bcm2835: Concurrency fix The commit shown in Fixes: aims to improve interrupt throughput by getting the handlers invoked on different CPU cores. It does so (*) by using an irq_ack hook to change the interrupt routing. Unfortunately, the IRQ status bits must be cleared at source, which only happens once the interrupt handler has run - there is no easy way for one core to claim one of the IRQs before sending the remainder to the next core on the list, so waking another core immediately results in a race with a chance of both cores handling the same IRQ. It is probably for this reason that the routing change is deferred to irq_ack, but that doesn't guarantee no clashes - after irq_ack is called, control returns to bcm2836_chained_handler_irq which proceeds to check for other pending IRQs at a time when the next core is probably doing the same thing. Since the whole point of the original commit is to distribute the IRQ handling, there is no reason to attempt to handle multiple IRQs in one interrupt callback, so the problem can be solved (or at least made much harder to reproduce) by changing a "while" into an "if", so that each invocation only handles one IRQ. (*) I'm not convinced it's as effective as claimed since irq_ack is called _after_ the interrupt handler, but the author thought it made a difference. See: #5214 #1794 Fixes: fd4c978 ("ARM64: Round-Robin dispatch IRQs between CPUs.") Signed-off-by: Phil Elwell <[email protected]> irqchip: irq-bcm2836: Avoid prototype warning Declare bcm2836_arm_irqchip_spin_gpu_irq in irq-bcm2836.h to avoid a compiler warning about a missing prototype. Signed-off-by: Phil Elwell <[email protected]>
popcornmix
pushed a commit
that referenced
this issue
Oct 10, 2024
IRQ-CPU mapping is round robined on ARM64 to increase concurrency and allow multiple interrupts to be serviced at a time. This reduces the need for FIQ. Signed-off-by: Michael Zoran <[email protected]> drivers: irqchip: irq-bcm2835: Concurrency fix The commit shown in Fixes: aims to improve interrupt throughput by getting the handlers invoked on different CPU cores. It does so (*) by using an irq_ack hook to change the interrupt routing. Unfortunately, the IRQ status bits must be cleared at source, which only happens once the interrupt handler has run - there is no easy way for one core to claim one of the IRQs before sending the remainder to the next core on the list, so waking another core immediately results in a race with a chance of both cores handling the same IRQ. It is probably for this reason that the routing change is deferred to irq_ack, but that doesn't guarantee no clashes - after irq_ack is called, control returns to bcm2836_chained_handler_irq which proceeds to check for other pending IRQs at a time when the next core is probably doing the same thing. Since the whole point of the original commit is to distribute the IRQ handling, there is no reason to attempt to handle multiple IRQs in one interrupt callback, so the problem can be solved (or at least made much harder to reproduce) by changing a "while" into an "if", so that each invocation only handles one IRQ. (*) I'm not convinced it's as effective as claimed since irq_ack is called _after_ the interrupt handler, but the author thought it made a difference. See: #5214 #1794 Fixes: fd4c978 ("ARM64: Round-Robin dispatch IRQs between CPUs.") Signed-off-by: Phil Elwell <[email protected]> irqchip: irq-bcm2836: Avoid prototype warning Declare bcm2836_arm_irqchip_spin_gpu_irq in irq-bcm2836.h to avoid a compiler warning about a missing prototype. Signed-off-by: Phil Elwell <[email protected]>
popcornmix
pushed a commit
that referenced
this issue
Oct 10, 2024
IRQ-CPU mapping is round robined on ARM64 to increase concurrency and allow multiple interrupts to be serviced at a time. This reduces the need for FIQ. Signed-off-by: Michael Zoran <[email protected]> drivers: irqchip: irq-bcm2835: Concurrency fix The commit shown in Fixes: aims to improve interrupt throughput by getting the handlers invoked on different CPU cores. It does so (*) by using an irq_ack hook to change the interrupt routing. Unfortunately, the IRQ status bits must be cleared at source, which only happens once the interrupt handler has run - there is no easy way for one core to claim one of the IRQs before sending the remainder to the next core on the list, so waking another core immediately results in a race with a chance of both cores handling the same IRQ. It is probably for this reason that the routing change is deferred to irq_ack, but that doesn't guarantee no clashes - after irq_ack is called, control returns to bcm2836_chained_handler_irq which proceeds to check for other pending IRQs at a time when the next core is probably doing the same thing. Since the whole point of the original commit is to distribute the IRQ handling, there is no reason to attempt to handle multiple IRQs in one interrupt callback, so the problem can be solved (or at least made much harder to reproduce) by changing a "while" into an "if", so that each invocation only handles one IRQ. (*) I'm not convinced it's as effective as claimed since irq_ack is called _after_ the interrupt handler, but the author thought it made a difference. See: #5214 #1794 Fixes: fd4c978 ("ARM64: Round-Robin dispatch IRQs between CPUs.") Signed-off-by: Phil Elwell <[email protected]> irqchip: irq-bcm2836: Avoid prototype warning Declare bcm2836_arm_irqchip_spin_gpu_irq in irq-bcm2836.h to avoid a compiler warning about a missing prototype. Signed-off-by: Phil Elwell <[email protected]>
popcornmix
pushed a commit
that referenced
this issue
Oct 14, 2024
IRQ-CPU mapping is round robined on ARM64 to increase concurrency and allow multiple interrupts to be serviced at a time. This reduces the need for FIQ. Signed-off-by: Michael Zoran <[email protected]> drivers: irqchip: irq-bcm2835: Concurrency fix The commit shown in Fixes: aims to improve interrupt throughput by getting the handlers invoked on different CPU cores. It does so (*) by using an irq_ack hook to change the interrupt routing. Unfortunately, the IRQ status bits must be cleared at source, which only happens once the interrupt handler has run - there is no easy way for one core to claim one of the IRQs before sending the remainder to the next core on the list, so waking another core immediately results in a race with a chance of both cores handling the same IRQ. It is probably for this reason that the routing change is deferred to irq_ack, but that doesn't guarantee no clashes - after irq_ack is called, control returns to bcm2836_chained_handler_irq which proceeds to check for other pending IRQs at a time when the next core is probably doing the same thing. Since the whole point of the original commit is to distribute the IRQ handling, there is no reason to attempt to handle multiple IRQs in one interrupt callback, so the problem can be solved (or at least made much harder to reproduce) by changing a "while" into an "if", so that each invocation only handles one IRQ. (*) I'm not convinced it's as effective as claimed since irq_ack is called _after_ the interrupt handler, but the author thought it made a difference. See: #5214 #1794 Fixes: fd4c978 ("ARM64: Round-Robin dispatch IRQs between CPUs.") Signed-off-by: Phil Elwell <[email protected]> irqchip: irq-bcm2836: Avoid prototype warning Declare bcm2836_arm_irqchip_spin_gpu_irq in irq-bcm2836.h to avoid a compiler warning about a missing prototype. Signed-off-by: Phil Elwell <[email protected]>
popcornmix
pushed a commit
that referenced
this issue
Oct 14, 2024
IRQ-CPU mapping is round robined on ARM64 to increase concurrency and allow multiple interrupts to be serviced at a time. This reduces the need for FIQ. Signed-off-by: Michael Zoran <[email protected]> drivers: irqchip: irq-bcm2835: Concurrency fix The commit shown in Fixes: aims to improve interrupt throughput by getting the handlers invoked on different CPU cores. It does so (*) by using an irq_ack hook to change the interrupt routing. Unfortunately, the IRQ status bits must be cleared at source, which only happens once the interrupt handler has run - there is no easy way for one core to claim one of the IRQs before sending the remainder to the next core on the list, so waking another core immediately results in a race with a chance of both cores handling the same IRQ. It is probably for this reason that the routing change is deferred to irq_ack, but that doesn't guarantee no clashes - after irq_ack is called, control returns to bcm2836_chained_handler_irq which proceeds to check for other pending IRQs at a time when the next core is probably doing the same thing. Since the whole point of the original commit is to distribute the IRQ handling, there is no reason to attempt to handle multiple IRQs in one interrupt callback, so the problem can be solved (or at least made much harder to reproduce) by changing a "while" into an "if", so that each invocation only handles one IRQ. (*) I'm not convinced it's as effective as claimed since irq_ack is called _after_ the interrupt handler, but the author thought it made a difference. See: #5214 #1794 Fixes: fd4c978 ("ARM64: Round-Robin dispatch IRQs between CPUs.") Signed-off-by: Phil Elwell <[email protected]> irqchip: irq-bcm2836: Avoid prototype warning Declare bcm2836_arm_irqchip_spin_gpu_irq in irq-bcm2836.h to avoid a compiler warning about a missing prototype. Signed-off-by: Phil Elwell <[email protected]>
popcornmix
pushed a commit
that referenced
this issue
Oct 17, 2024
IRQ-CPU mapping is round robined on ARM64 to increase concurrency and allow multiple interrupts to be serviced at a time. This reduces the need for FIQ. Signed-off-by: Michael Zoran <[email protected]> drivers: irqchip: irq-bcm2835: Concurrency fix The commit shown in Fixes: aims to improve interrupt throughput by getting the handlers invoked on different CPU cores. It does so (*) by using an irq_ack hook to change the interrupt routing. Unfortunately, the IRQ status bits must be cleared at source, which only happens once the interrupt handler has run - there is no easy way for one core to claim one of the IRQs before sending the remainder to the next core on the list, so waking another core immediately results in a race with a chance of both cores handling the same IRQ. It is probably for this reason that the routing change is deferred to irq_ack, but that doesn't guarantee no clashes - after irq_ack is called, control returns to bcm2836_chained_handler_irq which proceeds to check for other pending IRQs at a time when the next core is probably doing the same thing. Since the whole point of the original commit is to distribute the IRQ handling, there is no reason to attempt to handle multiple IRQs in one interrupt callback, so the problem can be solved (or at least made much harder to reproduce) by changing a "while" into an "if", so that each invocation only handles one IRQ. (*) I'm not convinced it's as effective as claimed since irq_ack is called _after_ the interrupt handler, but the author thought it made a difference. See: #5214 #1794 Fixes: fd4c978 ("ARM64: Round-Robin dispatch IRQs between CPUs.") Signed-off-by: Phil Elwell <[email protected]> irqchip: irq-bcm2836: Avoid prototype warning Declare bcm2836_arm_irqchip_spin_gpu_irq in irq-bcm2836.h to avoid a compiler warning about a missing prototype. Signed-off-by: Phil Elwell <[email protected]>
popcornmix
pushed a commit
that referenced
this issue
Oct 21, 2024
IRQ-CPU mapping is round robined on ARM64 to increase concurrency and allow multiple interrupts to be serviced at a time. This reduces the need for FIQ. Signed-off-by: Michael Zoran <[email protected]> drivers: irqchip: irq-bcm2835: Concurrency fix The commit shown in Fixes: aims to improve interrupt throughput by getting the handlers invoked on different CPU cores. It does so (*) by using an irq_ack hook to change the interrupt routing. Unfortunately, the IRQ status bits must be cleared at source, which only happens once the interrupt handler has run - there is no easy way for one core to claim one of the IRQs before sending the remainder to the next core on the list, so waking another core immediately results in a race with a chance of both cores handling the same IRQ. It is probably for this reason that the routing change is deferred to irq_ack, but that doesn't guarantee no clashes - after irq_ack is called, control returns to bcm2836_chained_handler_irq which proceeds to check for other pending IRQs at a time when the next core is probably doing the same thing. Since the whole point of the original commit is to distribute the IRQ handling, there is no reason to attempt to handle multiple IRQs in one interrupt callback, so the problem can be solved (or at least made much harder to reproduce) by changing a "while" into an "if", so that each invocation only handles one IRQ. (*) I'm not convinced it's as effective as claimed since irq_ack is called _after_ the interrupt handler, but the author thought it made a difference. See: #5214 #1794 Fixes: fd4c978 ("ARM64: Round-Robin dispatch IRQs between CPUs.") Signed-off-by: Phil Elwell <[email protected]> irqchip: irq-bcm2836: Avoid prototype warning Declare bcm2836_arm_irqchip_spin_gpu_irq in irq-bcm2836.h to avoid a compiler warning about a missing prototype. Signed-off-by: Phil Elwell <[email protected]>
popcornmix
pushed a commit
that referenced
this issue
Oct 23, 2024
IRQ-CPU mapping is round robined on ARM64 to increase concurrency and allow multiple interrupts to be serviced at a time. This reduces the need for FIQ. Signed-off-by: Michael Zoran <[email protected]> drivers: irqchip: irq-bcm2835: Concurrency fix The commit shown in Fixes: aims to improve interrupt throughput by getting the handlers invoked on different CPU cores. It does so (*) by using an irq_ack hook to change the interrupt routing. Unfortunately, the IRQ status bits must be cleared at source, which only happens once the interrupt handler has run - there is no easy way for one core to claim one of the IRQs before sending the remainder to the next core on the list, so waking another core immediately results in a race with a chance of both cores handling the same IRQ. It is probably for this reason that the routing change is deferred to irq_ack, but that doesn't guarantee no clashes - after irq_ack is called, control returns to bcm2836_chained_handler_irq which proceeds to check for other pending IRQs at a time when the next core is probably doing the same thing. Since the whole point of the original commit is to distribute the IRQ handling, there is no reason to attempt to handle multiple IRQs in one interrupt callback, so the problem can be solved (or at least made much harder to reproduce) by changing a "while" into an "if", so that each invocation only handles one IRQ. (*) I'm not convinced it's as effective as claimed since irq_ack is called _after_ the interrupt handler, but the author thought it made a difference. See: #5214 #1794 Fixes: fd4c978 ("ARM64: Round-Robin dispatch IRQs between CPUs.") Signed-off-by: Phil Elwell <[email protected]> irqchip: irq-bcm2836: Avoid prototype warning Declare bcm2836_arm_irqchip_spin_gpu_irq in irq-bcm2836.h to avoid a compiler warning about a missing prototype. Signed-off-by: Phil Elwell <[email protected]>
popcornmix
pushed a commit
that referenced
this issue
Oct 28, 2024
IRQ-CPU mapping is round robined on ARM64 to increase concurrency and allow multiple interrupts to be serviced at a time. This reduces the need for FIQ. Signed-off-by: Michael Zoran <[email protected]> drivers: irqchip: irq-bcm2835: Concurrency fix The commit shown in Fixes: aims to improve interrupt throughput by getting the handlers invoked on different CPU cores. It does so (*) by using an irq_ack hook to change the interrupt routing. Unfortunately, the IRQ status bits must be cleared at source, which only happens once the interrupt handler has run - there is no easy way for one core to claim one of the IRQs before sending the remainder to the next core on the list, so waking another core immediately results in a race with a chance of both cores handling the same IRQ. It is probably for this reason that the routing change is deferred to irq_ack, but that doesn't guarantee no clashes - after irq_ack is called, control returns to bcm2836_chained_handler_irq which proceeds to check for other pending IRQs at a time when the next core is probably doing the same thing. Since the whole point of the original commit is to distribute the IRQ handling, there is no reason to attempt to handle multiple IRQs in one interrupt callback, so the problem can be solved (or at least made much harder to reproduce) by changing a "while" into an "if", so that each invocation only handles one IRQ. (*) I'm not convinced it's as effective as claimed since irq_ack is called _after_ the interrupt handler, but the author thought it made a difference. See: #5214 #1794 Fixes: fd4c978 ("ARM64: Round-Robin dispatch IRQs between CPUs.") Signed-off-by: Phil Elwell <[email protected]> irqchip: irq-bcm2836: Avoid prototype warning Declare bcm2836_arm_irqchip_spin_gpu_irq in irq-bcm2836.h to avoid a compiler warning about a missing prototype. Signed-off-by: Phil Elwell <[email protected]>
popcornmix
pushed a commit
that referenced
this issue
Nov 1, 2024
IRQ-CPU mapping is round robined on ARM64 to increase concurrency and allow multiple interrupts to be serviced at a time. This reduces the need for FIQ. Signed-off-by: Michael Zoran <[email protected]> drivers: irqchip: irq-bcm2835: Concurrency fix The commit shown in Fixes: aims to improve interrupt throughput by getting the handlers invoked on different CPU cores. It does so (*) by using an irq_ack hook to change the interrupt routing. Unfortunately, the IRQ status bits must be cleared at source, which only happens once the interrupt handler has run - there is no easy way for one core to claim one of the IRQs before sending the remainder to the next core on the list, so waking another core immediately results in a race with a chance of both cores handling the same IRQ. It is probably for this reason that the routing change is deferred to irq_ack, but that doesn't guarantee no clashes - after irq_ack is called, control returns to bcm2836_chained_handler_irq which proceeds to check for other pending IRQs at a time when the next core is probably doing the same thing. Since the whole point of the original commit is to distribute the IRQ handling, there is no reason to attempt to handle multiple IRQs in one interrupt callback, so the problem can be solved (or at least made much harder to reproduce) by changing a "while" into an "if", so that each invocation only handles one IRQ. (*) I'm not convinced it's as effective as claimed since irq_ack is called _after_ the interrupt handler, but the author thought it made a difference. See: #5214 #1794 Fixes: fd4c978 ("ARM64: Round-Robin dispatch IRQs between CPUs.") Signed-off-by: Phil Elwell <[email protected]> irqchip: irq-bcm2836: Avoid prototype warning Declare bcm2836_arm_irqchip_spin_gpu_irq in irq-bcm2836.h to avoid a compiler warning about a missing prototype. Signed-off-by: Phil Elwell <[email protected]>
popcornmix
pushed a commit
that referenced
this issue
Nov 5, 2024
IRQ-CPU mapping is round robined on ARM64 to increase concurrency and allow multiple interrupts to be serviced at a time. This reduces the need for FIQ. Signed-off-by: Michael Zoran <[email protected]> drivers: irqchip: irq-bcm2835: Concurrency fix The commit shown in Fixes: aims to improve interrupt throughput by getting the handlers invoked on different CPU cores. It does so (*) by using an irq_ack hook to change the interrupt routing. Unfortunately, the IRQ status bits must be cleared at source, which only happens once the interrupt handler has run - there is no easy way for one core to claim one of the IRQs before sending the remainder to the next core on the list, so waking another core immediately results in a race with a chance of both cores handling the same IRQ. It is probably for this reason that the routing change is deferred to irq_ack, but that doesn't guarantee no clashes - after irq_ack is called, control returns to bcm2836_chained_handler_irq which proceeds to check for other pending IRQs at a time when the next core is probably doing the same thing. Since the whole point of the original commit is to distribute the IRQ handling, there is no reason to attempt to handle multiple IRQs in one interrupt callback, so the problem can be solved (or at least made much harder to reproduce) by changing a "while" into an "if", so that each invocation only handles one IRQ. (*) I'm not convinced it's as effective as claimed since irq_ack is called _after_ the interrupt handler, but the author thought it made a difference. See: #5214 #1794 Fixes: fd4c978 ("ARM64: Round-Robin dispatch IRQs between CPUs.") Signed-off-by: Phil Elwell <[email protected]> irqchip: irq-bcm2836: Avoid prototype warning Declare bcm2836_arm_irqchip_spin_gpu_irq in irq-bcm2836.h to avoid a compiler warning about a missing prototype. Signed-off-by: Phil Elwell <[email protected]>
popcornmix
pushed a commit
that referenced
this issue
Nov 6, 2024
IRQ-CPU mapping is round robined on ARM64 to increase concurrency and allow multiple interrupts to be serviced at a time. This reduces the need for FIQ. Signed-off-by: Michael Zoran <[email protected]> drivers: irqchip: irq-bcm2835: Concurrency fix The commit shown in Fixes: aims to improve interrupt throughput by getting the handlers invoked on different CPU cores. It does so (*) by using an irq_ack hook to change the interrupt routing. Unfortunately, the IRQ status bits must be cleared at source, which only happens once the interrupt handler has run - there is no easy way for one core to claim one of the IRQs before sending the remainder to the next core on the list, so waking another core immediately results in a race with a chance of both cores handling the same IRQ. It is probably for this reason that the routing change is deferred to irq_ack, but that doesn't guarantee no clashes - after irq_ack is called, control returns to bcm2836_chained_handler_irq which proceeds to check for other pending IRQs at a time when the next core is probably doing the same thing. Since the whole point of the original commit is to distribute the IRQ handling, there is no reason to attempt to handle multiple IRQs in one interrupt callback, so the problem can be solved (or at least made much harder to reproduce) by changing a "while" into an "if", so that each invocation only handles one IRQ. (*) I'm not convinced it's as effective as claimed since irq_ack is called _after_ the interrupt handler, but the author thought it made a difference. See: #5214 #1794 Fixes: fd4c978 ("ARM64: Round-Robin dispatch IRQs between CPUs.") Signed-off-by: Phil Elwell <[email protected]> irqchip: irq-bcm2836: Avoid prototype warning Declare bcm2836_arm_irqchip_spin_gpu_irq in irq-bcm2836.h to avoid a compiler warning about a missing prototype. Signed-off-by: Phil Elwell <[email protected]>
popcornmix
pushed a commit
that referenced
this issue
Nov 8, 2024
IRQ-CPU mapping is round robined on ARM64 to increase concurrency and allow multiple interrupts to be serviced at a time. This reduces the need for FIQ. Signed-off-by: Michael Zoran <[email protected]> drivers: irqchip: irq-bcm2835: Concurrency fix The commit shown in Fixes: aims to improve interrupt throughput by getting the handlers invoked on different CPU cores. It does so (*) by using an irq_ack hook to change the interrupt routing. Unfortunately, the IRQ status bits must be cleared at source, which only happens once the interrupt handler has run - there is no easy way for one core to claim one of the IRQs before sending the remainder to the next core on the list, so waking another core immediately results in a race with a chance of both cores handling the same IRQ. It is probably for this reason that the routing change is deferred to irq_ack, but that doesn't guarantee no clashes - after irq_ack is called, control returns to bcm2836_chained_handler_irq which proceeds to check for other pending IRQs at a time when the next core is probably doing the same thing. Since the whole point of the original commit is to distribute the IRQ handling, there is no reason to attempt to handle multiple IRQs in one interrupt callback, so the problem can be solved (or at least made much harder to reproduce) by changing a "while" into an "if", so that each invocation only handles one IRQ. (*) I'm not convinced it's as effective as claimed since irq_ack is called _after_ the interrupt handler, but the author thought it made a difference. See: #5214 #1794 Fixes: fd4c978 ("ARM64: Round-Robin dispatch IRQs between CPUs.") Signed-off-by: Phil Elwell <[email protected]> irqchip: irq-bcm2836: Avoid prototype warning Declare bcm2836_arm_irqchip_spin_gpu_irq in irq-bcm2836.h to avoid a compiler warning about a missing prototype. Signed-off-by: Phil Elwell <[email protected]>
popcornmix
pushed a commit
that referenced
this issue
Nov 11, 2024
IRQ-CPU mapping is round robined on ARM64 to increase concurrency and allow multiple interrupts to be serviced at a time. This reduces the need for FIQ. Signed-off-by: Michael Zoran <[email protected]> drivers: irqchip: irq-bcm2835: Concurrency fix The commit shown in Fixes: aims to improve interrupt throughput by getting the handlers invoked on different CPU cores. It does so (*) by using an irq_ack hook to change the interrupt routing. Unfortunately, the IRQ status bits must be cleared at source, which only happens once the interrupt handler has run - there is no easy way for one core to claim one of the IRQs before sending the remainder to the next core on the list, so waking another core immediately results in a race with a chance of both cores handling the same IRQ. It is probably for this reason that the routing change is deferred to irq_ack, but that doesn't guarantee no clashes - after irq_ack is called, control returns to bcm2836_chained_handler_irq which proceeds to check for other pending IRQs at a time when the next core is probably doing the same thing. Since the whole point of the original commit is to distribute the IRQ handling, there is no reason to attempt to handle multiple IRQs in one interrupt callback, so the problem can be solved (or at least made much harder to reproduce) by changing a "while" into an "if", so that each invocation only handles one IRQ. (*) I'm not convinced it's as effective as claimed since irq_ack is called _after_ the interrupt handler, but the author thought it made a difference. See: #5214 #1794 Fixes: fd4c978 ("ARM64: Round-Robin dispatch IRQs between CPUs.") Signed-off-by: Phil Elwell <[email protected]> irqchip: irq-bcm2836: Avoid prototype warning Declare bcm2836_arm_irqchip_spin_gpu_irq in irq-bcm2836.h to avoid a compiler warning about a missing prototype. Signed-off-by: Phil Elwell <[email protected]>
popcornmix
pushed a commit
that referenced
this issue
Nov 18, 2024
IRQ-CPU mapping is round robined on ARM64 to increase concurrency and allow multiple interrupts to be serviced at a time. This reduces the need for FIQ. Signed-off-by: Michael Zoran <[email protected]> drivers: irqchip: irq-bcm2835: Concurrency fix The commit shown in Fixes: aims to improve interrupt throughput by getting the handlers invoked on different CPU cores. It does so (*) by using an irq_ack hook to change the interrupt routing. Unfortunately, the IRQ status bits must be cleared at source, which only happens once the interrupt handler has run - there is no easy way for one core to claim one of the IRQs before sending the remainder to the next core on the list, so waking another core immediately results in a race with a chance of both cores handling the same IRQ. It is probably for this reason that the routing change is deferred to irq_ack, but that doesn't guarantee no clashes - after irq_ack is called, control returns to bcm2836_chained_handler_irq which proceeds to check for other pending IRQs at a time when the next core is probably doing the same thing. Since the whole point of the original commit is to distribute the IRQ handling, there is no reason to attempt to handle multiple IRQs in one interrupt callback, so the problem can be solved (or at least made much harder to reproduce) by changing a "while" into an "if", so that each invocation only handles one IRQ. (*) I'm not convinced it's as effective as claimed since irq_ack is called _after_ the interrupt handler, but the author thought it made a difference. See: #5214 #1794 Fixes: fd4c978 ("ARM64: Round-Robin dispatch IRQs between CPUs.") Signed-off-by: Phil Elwell <[email protected]> irqchip: irq-bcm2836: Avoid prototype warning Declare bcm2836_arm_irqchip_spin_gpu_irq in irq-bcm2836.h to avoid a compiler warning about a missing prototype. Signed-off-by: Phil Elwell <[email protected]>
popcornmix
pushed a commit
that referenced
this issue
Nov 18, 2024
IRQ-CPU mapping is round robined on ARM64 to increase concurrency and allow multiple interrupts to be serviced at a time. This reduces the need for FIQ. Signed-off-by: Michael Zoran <[email protected]> drivers: irqchip: irq-bcm2835: Concurrency fix The commit shown in Fixes: aims to improve interrupt throughput by getting the handlers invoked on different CPU cores. It does so (*) by using an irq_ack hook to change the interrupt routing. Unfortunately, the IRQ status bits must be cleared at source, which only happens once the interrupt handler has run - there is no easy way for one core to claim one of the IRQs before sending the remainder to the next core on the list, so waking another core immediately results in a race with a chance of both cores handling the same IRQ. It is probably for this reason that the routing change is deferred to irq_ack, but that doesn't guarantee no clashes - after irq_ack is called, control returns to bcm2836_chained_handler_irq which proceeds to check for other pending IRQs at a time when the next core is probably doing the same thing. Since the whole point of the original commit is to distribute the IRQ handling, there is no reason to attempt to handle multiple IRQs in one interrupt callback, so the problem can be solved (or at least made much harder to reproduce) by changing a "while" into an "if", so that each invocation only handles one IRQ. (*) I'm not convinced it's as effective as claimed since irq_ack is called _after_ the interrupt handler, but the author thought it made a difference. See: #5214 #1794 Fixes: fd4c978 ("ARM64: Round-Robin dispatch IRQs between CPUs.") Signed-off-by: Phil Elwell <[email protected]> irqchip: irq-bcm2836: Avoid prototype warning Declare bcm2836_arm_irqchip_spin_gpu_irq in irq-bcm2836.h to avoid a compiler warning about a missing prototype. Signed-off-by: Phil Elwell <[email protected]>
popcornmix
pushed a commit
that referenced
this issue
Nov 18, 2024
IRQ-CPU mapping is round robined on ARM64 to increase concurrency and allow multiple interrupts to be serviced at a time. This reduces the need for FIQ. Signed-off-by: Michael Zoran <[email protected]> drivers: irqchip: irq-bcm2835: Concurrency fix The commit shown in Fixes: aims to improve interrupt throughput by getting the handlers invoked on different CPU cores. It does so (*) by using an irq_ack hook to change the interrupt routing. Unfortunately, the IRQ status bits must be cleared at source, which only happens once the interrupt handler has run - there is no easy way for one core to claim one of the IRQs before sending the remainder to the next core on the list, so waking another core immediately results in a race with a chance of both cores handling the same IRQ. It is probably for this reason that the routing change is deferred to irq_ack, but that doesn't guarantee no clashes - after irq_ack is called, control returns to bcm2836_chained_handler_irq which proceeds to check for other pending IRQs at a time when the next core is probably doing the same thing. Since the whole point of the original commit is to distribute the IRQ handling, there is no reason to attempt to handle multiple IRQs in one interrupt callback, so the problem can be solved (or at least made much harder to reproduce) by changing a "while" into an "if", so that each invocation only handles one IRQ. (*) I'm not convinced it's as effective as claimed since irq_ack is called _after_ the interrupt handler, but the author thought it made a difference. See: #5214 #1794 Fixes: fd4c978 ("ARM64: Round-Robin dispatch IRQs between CPUs.") Signed-off-by: Phil Elwell <[email protected]> irqchip: irq-bcm2836: Avoid prototype warning Declare bcm2836_arm_irqchip_spin_gpu_irq in irq-bcm2836.h to avoid a compiler warning about a missing prototype. Signed-off-by: Phil Elwell <[email protected]>
popcornmix
pushed a commit
that referenced
this issue
Nov 25, 2024
IRQ-CPU mapping is round robined on ARM64 to increase concurrency and allow multiple interrupts to be serviced at a time. This reduces the need for FIQ. Signed-off-by: Michael Zoran <[email protected]> drivers: irqchip: irq-bcm2835: Concurrency fix The commit shown in Fixes: aims to improve interrupt throughput by getting the handlers invoked on different CPU cores. It does so (*) by using an irq_ack hook to change the interrupt routing. Unfortunately, the IRQ status bits must be cleared at source, which only happens once the interrupt handler has run - there is no easy way for one core to claim one of the IRQs before sending the remainder to the next core on the list, so waking another core immediately results in a race with a chance of both cores handling the same IRQ. It is probably for this reason that the routing change is deferred to irq_ack, but that doesn't guarantee no clashes - after irq_ack is called, control returns to bcm2836_chained_handler_irq which proceeds to check for other pending IRQs at a time when the next core is probably doing the same thing. Since the whole point of the original commit is to distribute the IRQ handling, there is no reason to attempt to handle multiple IRQs in one interrupt callback, so the problem can be solved (or at least made much harder to reproduce) by changing a "while" into an "if", so that each invocation only handles one IRQ. (*) I'm not convinced it's as effective as claimed since irq_ack is called _after_ the interrupt handler, but the author thought it made a difference. See: #5214 #1794 Fixes: fd4c978 ("ARM64: Round-Robin dispatch IRQs between CPUs.") Signed-off-by: Phil Elwell <[email protected]> irqchip: irq-bcm2836: Avoid prototype warning Declare bcm2836_arm_irqchip_spin_gpu_irq in irq-bcm2836.h to avoid a compiler warning about a missing prototype. Signed-off-by: Phil Elwell <[email protected]>
popcornmix
pushed a commit
that referenced
this issue
Nov 25, 2024
IRQ-CPU mapping is round robined on ARM64 to increase concurrency and allow multiple interrupts to be serviced at a time. This reduces the need for FIQ. Signed-off-by: Michael Zoran <[email protected]> drivers: irqchip: irq-bcm2835: Concurrency fix The commit shown in Fixes: aims to improve interrupt throughput by getting the handlers invoked on different CPU cores. It does so (*) by using an irq_ack hook to change the interrupt routing. Unfortunately, the IRQ status bits must be cleared at source, which only happens once the interrupt handler has run - there is no easy way for one core to claim one of the IRQs before sending the remainder to the next core on the list, so waking another core immediately results in a race with a chance of both cores handling the same IRQ. It is probably for this reason that the routing change is deferred to irq_ack, but that doesn't guarantee no clashes - after irq_ack is called, control returns to bcm2836_chained_handler_irq which proceeds to check for other pending IRQs at a time when the next core is probably doing the same thing. Since the whole point of the original commit is to distribute the IRQ handling, there is no reason to attempt to handle multiple IRQs in one interrupt callback, so the problem can be solved (or at least made much harder to reproduce) by changing a "while" into an "if", so that each invocation only handles one IRQ. (*) I'm not convinced it's as effective as claimed since irq_ack is called _after_ the interrupt handler, but the author thought it made a difference. See: #5214 #1794 Fixes: fd4c978 ("ARM64: Round-Robin dispatch IRQs between CPUs.") Signed-off-by: Phil Elwell <[email protected]> irqchip: irq-bcm2836: Avoid prototype warning Declare bcm2836_arm_irqchip_spin_gpu_irq in irq-bcm2836.h to avoid a compiler warning about a missing prototype. Signed-off-by: Phil Elwell <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
At random, interrupts from a gpio line are received by the interrupt handler twice. The problem is present only with a 64 bit system, while 32 bit systems are clean
Steps to reproduce the behaviour
I send a square wave with frequency 1 kHz and duty cycle 50% to a gpio line (gpio4), programmed to generate interrupts both at the rising and falling edge. Interrupts should occur with cadence 500 us with alternating 0/1 values. A small module handles the interrupts flow and checks its coherency.
Sometimes (about once in a thousand events) a few usec after an interrupt has been handled (typically 4 ... 10), the service routine is entered again.
To reproduce the problem, these is the module source code:
irqtest.c.txt
and the Makefile (remove the .txt from names):
Makefile.txt
This same test, run on the same machine with a 32 bit system, goes clean through millions of events.
Device (s)
Raspberry Pi 3 Mod. B
System
pi@raspberrypi:~/irqtest $ raspinfo
System Information
Raspberry Pi 3 Model B Rev 1.2
PRETTY_NAME="Debian GNU/Linux 11 (bullseye)"
NAME="Debian GNU/Linux"
VERSION_ID="11"
VERSION="11 (bullseye)"
Raspberry Pi reference 2022-09-22
Generated using pi-gen, https://github.com/RPi-Distro/pi-gen, 005a8c73b05a2cab394073150208bf4f069e861a, stage4
Linux raspberrypi 5.15.61-v8+ #1579 SMP PREEMPT Fri Aug 26 11:16:44 BST 2022 aarch64 GNU/Linux
Revision : a02082
Serial : 00000000fd306629
Model : Raspberry Pi 3 Model B Rev 1.2
Throttled flag : throttled=0x0
Camera : supported=0 detected=0, libcamera interfaces=0
Videocore information
Aug 26 2022 14:04:36
Copyright (c) 2012 Broadcom
version 102f1e848393c2112206fadffaaf86db04e98326 (clean) (release) (start)
alloc failures: 0
compactions: 0
legacy block fails: 0
Filesystem information
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/root 14978128 3586248 10726152 26% /
devtmpfs 332740 0 332740 0% /dev
tmpfs 465732 0 465732 0% /dev/shm
tmpfs 186296 1156 185140 1% /run
tmpfs 5120 4 5116 1% /run/lock
/dev/mmcblk0p1 261108 31222 229886 12% /boot
tmpfs 93144 20 93124 1% /run/user/1000
Filename Type Size Used Priority
/var/swap file 102396 768 -2
Package version information
raspberrypi-ui-mods:
Installed: 1.20220923
raspberrypi-sys-mods:
Installed: 20220915
openbox:
Installed: 3.6.1-9+rpt1+deb11u1
lxpanel:
Installed: 0.10.1-2+rpt19
pcmanfm:
Installed: 1.3.2-1+rpt9
rpd-plym-splash:
Installed: 0.32
Networking Information
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet x.x.x.x netmask x.x.x.x broadcast x.x.x.x
inet6 y::y.y.y.y prefixlen 64 scopeid 0x20
ether m.m.m.m txqueuelen 1000 (Ethernet)
RX packets 25916 bytes 3817750 (3.6 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 31346 bytes 22138677 (21.1 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet x.x.x.x netmask x.x.x.x
inet6 ::1 prefixlen 128 scopeid 0x10
loop txqueuelen 1000 (Local Loopback)
RX packets 32452 bytes 22896453 (21.8 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 32452 bytes 22896453 (21.8 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
wlan0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
ether m.m.m.m txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
USB Information
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc_otg/1p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/5p, 480M
|__ Port 1: Dev 3, If 0, Class=Vendor Specific Class, Driver=smsc95xx, 480M
|__ Port 2: Dev 4, If 1, Class=Human Interface Device, Driver=usbhid, 12M
|__ Port 2: Dev 4, If 0, Class=Human Interface Device, Driver=usbhid, 12M
|__ Port 3: Dev 5, If 0, Class=Mass Storage, Driver=usb-storage, 480M
|__ Port 5: Dev 6, If 0, Class=Human Interface Device, Driver=usbhid, 12M
config.txt
aphy_params_current=819
arm_64bit=1
arm_freq=1200
arm_freq_min=600
audio_pwm_mode=514
camera_auto_detect=1
config_hdmi_boost=5
core_freq=400
desired_osc_freq=0x387520
disable_commandline_tags=2
disable_l2cache=1
disable_overscan=1
display_auto_detect=1
display_hdmi_rotate=-1
display_lcd_rotate=-1
dphy_params_current=547
dvfs=3
enable_tvout=1
force_eeprom_read=1
force_pwm_open=1
framebuffer_ignore_alpha=1
framebuffer_swap=1
gpu_freq=300
init_uart_clock=0x2dc6c00
lcd_framerate=60
mask_gpu_interrupt0=3072
mask_gpu_interrupt1=26370
max_framebuffers=2
over_voltage_avs=0x13d62
pause_burst_frames=1
program_serial_random=1
sdram_freq=450
total_mem=1024
hdmi_force_cec_address:0=65535
hdmi_force_cec_address:1=65535
hdmi_pixel_freq_limit:0=0x9a7ec80
device_tree=-
overlay_prefix=overlays/
hdmi_cvt:0=
hdmi_cvt:1=
hdmi_edid_filename:0=
hdmi_edid_filename:1=
hdmi_timings:0=
hdmi_timings:1=
cmdline.txt
coherent_pool=1M 8250.nr_uarts=0 snd_bcm2835.enable_compat_alsa=0 snd_bcm2835.enable_hdmi=1 video=HDMI-A-1:720x576M@50 vc_mem.mem_base=0x3ec00000 vc_mem.mem_size=0x40000000 console=ttyS0,115200 console=tty1 root=PARTUUID=d823e4c0-02 rootfstype=ext4 fsck.repair=yes rootwait quiet splash plymouth.ignore-serial-consoles
raspi-gpio settings
BANK0 (GPIO 0 to 27):
GPIO 0: level=1 fsel=0 func=INPUT
GPIO 1: level=1 fsel=0 func=INPUT
GPIO 2: level=1 fsel=0 func=INPUT
GPIO 3: level=1 fsel=0 func=INPUT
GPIO 4: level=1 fsel=0 func=INPUT
GPIO 5: level=1 fsel=0 func=INPUT
GPIO 6: level=1 fsel=0 func=INPUT
GPIO 7: level=1 fsel=0 func=INPUT
GPIO 8: level=1 fsel=0 func=INPUT
GPIO 9: level=0 fsel=0 func=INPUT
GPIO 10: level=0 fsel=0 func=INPUT
GPIO 11: level=0 fsel=0 func=INPUT
GPIO 12: level=0 fsel=0 func=INPUT
GPIO 13: level=0 fsel=0 func=INPUT
GPIO 14: level=0 fsel=0 func=INPUT
GPIO 15: level=1 fsel=0 func=INPUT
GPIO 16: level=0 fsel=0 func=INPUT
GPIO 17: level=0 fsel=0 func=INPUT
GPIO 18: level=0 fsel=0 func=INPUT
GPIO 19: level=0 fsel=0 func=INPUT
GPIO 20: level=0 fsel=0 func=INPUT
GPIO 21: level=0 fsel=0 func=INPUT
GPIO 22: level=0 fsel=0 func=INPUT
GPIO 23: level=0 fsel=0 func=INPUT
GPIO 24: level=0 fsel=0 func=INPUT
GPIO 25: level=0 fsel=0 func=INPUT
GPIO 26: level=0 fsel=0 func=INPUT
GPIO 27: level=0 fsel=0 func=INPUT
BANK1 (GPIO 28 to 45):
GPIO 28: level=0 fsel=0 func=INPUT
GPIO 29: level=1 fsel=0 func=INPUT
GPIO 30: level=0 fsel=0 func=INPUT
GPIO 31: level=0 fsel=0 func=INPUT
GPIO 32: level=1 fsel=7 alt=3 func=TXD0
GPIO 33: level=1 fsel=7 alt=3 func=RXD0
GPIO 34: level=1 fsel=7 alt=3 func=SD1_CLK
GPIO 35: level=1 fsel=7 alt=3 func=SD1_CMD
GPIO 36: level=1 fsel=7 alt=3 func=SD1_DAT0
GPIO 37: level=1 fsel=7 alt=3 func=SD1_DAT1
GPIO 38: level=1 fsel=7 alt=3 func=SD1_DAT2
GPIO 39: level=1 fsel=7 alt=3 func=SD1_DAT3
GPIO 40: level=1 fsel=4 alt=0 func=PWM0
GPIO 41: level=0 fsel=4 alt=0 func=PWM1
GPIO 42: level=0 fsel=4 alt=0 func=GPCLK1
GPIO 43: level=1 fsel=4 alt=0 func=GPCLK2
GPIO 44: level=1 fsel=0 func=INPUT
GPIO 45: level=1 fsel=0 func=INPUT
BANK2 (GPIO 46 to 53):
GPIO 46: level=1 fsel=0 func=INPUT
GPIO 47: level=1 fsel=1 func=OUTPUT
GPIO 48: level=0 fsel=4 alt=0 func=SD0_CLK
GPIO 49: level=1 fsel=4 alt=0 func=SD0_CMD
GPIO 50: level=1 fsel=4 alt=0 func=SD0_DAT0
GPIO 51: level=1 fsel=4 alt=0 func=SD0_DAT1
GPIO 52: level=1 fsel=4 alt=0 func=SD0_DAT2
GPIO 53: level=1 fsel=4 alt=0 func=SD0_DAT3
vcdbg log messages
sudo: vcdbg: command not found
dmesg log
[ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034]
[ 0.000000] Linux version 5.15.61-v8+ (dom@buildbot) (aarch64-linux-gnu-gcc-8 (Ubuntu/Linaro 8.4.0-3ubuntu1) 8.4.0, GNU ld (GNU Binutils for Ubuntu) 2.34) #1579 SMP PREEMPT Fri Aug 26 11:16:44 BST 2022
[ 0.000000] random: crng init done
[ 0.000000] Machine model: Raspberry Pi 3 Model B Rev 1.2
[ 0.000000] efi: UEFI not found.
[ 0.000000] Reserved memory: created CMA memory pool at 0x000000001ec00000, size 256 MiB
[ 0.000000] OF: reserved mem: initialized node linux,cma, compatible id shared-dma-pool
[ 0.000000] Zone ranges:
[ 0.000000] DMA [mem 0x0000000000000000-0x000000003b3fffff]
[ 0.000000] DMA32 empty
[ 0.000000] Normal empty
[ 0.000000] Movable zone start for each node
[ 0.000000] Early memory node ranges
[ 0.000000] node 0: [mem 0x0000000000000000-0x000000003b3fffff]
[ 0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x000000003b3fffff]
[ 0.000000] On node 0, zone DMA: 19456 pages in unavailable ranges
[ 0.000000] percpu: Embedded 28 pages/cpu s77272 r8192 d29224 u114688
[ 0.000000] pcpu-alloc: s77272 r8192 d29224 u114688 alloc=28*4096
[ 0.000000] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3
[ 0.000000] Detected VIPT I-cache on CPU0
[ 0.000000] CPU features: kernel page table isolation forced ON by KASLR
[ 0.000000] CPU features: detected: Kernel page table isolation (KPTI)
[ 0.000000] CPU features: detected: ARM erratum 843419
[ 0.000000] CPU features: detected: ARM erratum 845719
[ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 238896
[ 0.000000] Kernel command line: coherent_pool=1M 8250.nr_uarts=0 snd_bcm2835.enable_compat_alsa=0 snd_bcm2835.enable_hdmi=1 video=HDMI-A-1:720x576M@50 vc_mem.mem_base=0x3ec00000 vc_mem.mem_size=0x40000000 console=ttyS0,115200 console=tty1 root=PARTUUID=d823e4c0-02 rootfstype=ext4 fsck.repair=yes rootwait quiet splash plymouth.ignore-serial-consoles
[ 0.000000] Unknown kernel command line parameters "splash", will be passed to user space.
[ 0.000000] Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes, linear)
[ 0.000000] Inode-cache hash table entries: 65536 (order: 7, 524288 bytes, linear)
[ 0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off
[ 0.000000] Memory: 665480K/970752K available (11520K kernel code, 1956K rwdata, 4140K rodata, 3840K init, 974K bss, 43128K reserved, 262144K cma-reserved)
[ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
[ 0.000000] ftrace: allocating 38040 entries in 149 pages
[ 0.000000] ftrace: allocated 149 pages with 4 groups
[ 0.000000] trace event string verifier disabled
[ 0.000000] rcu: Preemptible hierarchical RCU implementation.
[ 0.000000] rcu: RCU event tracing is enabled.
[ 0.000000] rcu: RCU restricting CPUs from NR_CPUS=256 to nr_cpu_ids=4.
[ 0.000000] Trampoline variant of Tasks RCU enabled.
[ 0.000000] Rude variant of Tasks RCU enabled.
[ 0.000000] Tracing variant of Tasks RCU enabled.
[ 0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 25 jiffies.
[ 0.000000] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=4
[ 0.000000] NR_IRQS: 64, nr_irqs: 64, preallocated irqs: 0
[ 0.000000] Root IRQ handler: bcm2836_arm_irqchip_handle_irq
[ 0.000000] arch_timer: cp15 timer(s) running at 19.20MHz (phys).
[ 0.000000] clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x46d987e47, max_idle_ns: 440795202767 ns
[ 0.000001] sched_clock: 56 bits at 19MHz, resolution 52ns, wraps every 4398046511078ns
[ 0.000360] Console: colour dummy device 80x25
[ 0.000434] printk: console [tty1] enabled
[ 0.000503] Calibrating delay loop (skipped), value calculated using timer frequency.. 38.40 BogoMIPS (lpj=76800)
[ 0.000539] pid_max: default: 32768 minimum: 301
[ 0.000728] LSM: Security Framework initializing
[ 0.000991] Mount-cache hash table entries: 2048 (order: 2, 16384 bytes, linear)
[ 0.001035] Mountpoint-cache hash table entries: 2048 (order: 2, 16384 bytes, linear)
[ 0.002736] cgroup: Disabling memory control group subsystem
[ 0.006599] rcu: Hierarchical SRCU implementation.
[ 0.008096] EFI services will not be available.
[ 0.008904] smp: Bringing up secondary CPUs ...
[ 0.010421] Detected VIPT I-cache on CPU1
[ 0.010515] CPU1: Booted secondary processor 0x0000000001 [0x410fd034]
[ 0.012332] Detected VIPT I-cache on CPU2
[ 0.012396] CPU2: Booted secondary processor 0x0000000002 [0x410fd034]
[ 0.014047] Detected VIPT I-cache on CPU3
[ 0.014102] CPU3: Booted secondary processor 0x0000000003 [0x410fd034]
[ 0.014316] smp: Brought up 1 node, 4 CPUs
[ 0.014345] SMP: Total of 4 processors activated.
[ 0.014362] CPU features: detected: 32-bit EL0 Support
[ 0.014376] CPU features: detected: 32-bit EL1 Support
[ 0.014393] CPU features: detected: CRC32 instructions
[ 0.055389] CPU: All CPU(s) started at EL2
[ 0.055503] alternatives: patching kernel code
[ 0.057505] devtmpfs: initialized
[ 0.080007] Enabled cp15_barrier support
[ 0.080059] Enabled setend support
[ 0.080087] KASLR enabled
[ 0.080394] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns
[ 0.080437] futex hash table entries: 1024 (order: 4, 65536 bytes, linear)
[ 0.092287] pinctrl core: initialized pinctrl subsystem
[ 0.093566] DMI not present or invalid.
[ 0.094525] NET: Registered PF_NETLINK/PF_ROUTE protocol family
[ 0.105890] DMA: preallocated 1024 KiB GFP_KERNEL pool for atomic allocations
[ 0.106394] DMA: preallocated 1024 KiB GFP_KERNEL|GFP_DMA pool for atomic allocations
[ 0.107839] DMA: preallocated 1024 KiB GFP_KERNEL|GFP_DMA32 pool for atomic allocations
[ 0.108005] audit: initializing netlink subsys (disabled)
[ 0.108443] audit: type=2000 audit(0.104:1): state=initialized audit_enabled=0 res=1
[ 0.109400] thermal_sys: Registered thermal governor 'step_wise'
[ 0.109705] cpuidle: using governor menu
[ 0.110313] hw-breakpoint: found 6 breakpoint and 4 watchpoint registers.
[ 0.110602] ASID allocator initialised with 32768 entries
[ 0.110844] Serial: AMBA PL011 UART driver
[ 0.125196] bcm2835-mbox 3f00b880.mailbox: mailbox enabled
[ 0.152798] raspberrypi-firmware soc:firmware: Attached to firmware from 2022-08-26T14:04:36, variant start
[ 0.156823] raspberrypi-firmware soc:firmware: Firmware hash is 102f1e848393c2112206fadffaaf86db04e98326
[ 0.217222] bcm2835-dma 3f007000.dma: DMA legacy API manager, dmachans=0x1
[ 0.222796] vgaarb: loaded
[ 0.223450] SCSI subsystem initialized
[ 0.223773] usbcore: registered new interface driver usbfs
[ 0.223870] usbcore: registered new interface driver hub
[ 0.223968] usbcore: registered new device driver usb
[ 0.224500] usb_phy_generic phy: supply vcc not found, using dummy regulator
[ 0.224808] usb_phy_generic phy: dummy supplies not allowed for exclusive requests
[ 0.225365] pps_core: LinuxPPS API ver. 1 registered
[ 0.225383] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti [email protected]
[ 0.225419] PTP clock support registered
[ 0.227757] clocksource: Switched to clocksource arch_sys_counter
[ 0.356501] VFS: Disk quotas dquot_6.6.0
[ 0.356648] VFS: Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
[ 0.356905] FS-Cache: Loaded
[ 0.357221] CacheFiles: Loaded
[ 0.358578] simple-framebuffer 3ea65000.framebuffer: framebuffer at 0x3ea65000, 0x195000 bytes
[ 0.358606] simple-framebuffer 3ea65000.framebuffer: format=a8r8g8b8, mode=720x576x32, linelength=2880
[ 0.359207] Console: switching to colour frame buffer device 90x36
[ 0.366185] simple-framebuffer 3ea65000.framebuffer: fb0: simplefb registered!
[ 0.381709] NET: Registered PF_INET protocol family
[ 0.382038] IP idents hash table entries: 16384 (order: 5, 131072 bytes, linear)
[ 0.383669] tcp_listen_portaddr_hash hash table entries: 512 (order: 1, 8192 bytes, linear)
[ 0.383760] Table-perturb hash table entries: 65536 (order: 6, 262144 bytes, linear)
[ 0.383796] TCP established hash table entries: 8192 (order: 4, 65536 bytes, linear)
[ 0.383925] TCP bind hash table entries: 8192 (order: 5, 131072 bytes, linear)
[ 0.384131] TCP: Hash tables configured (established 8192 bind 8192)
[ 0.384411] UDP hash table entries: 512 (order: 2, 16384 bytes, linear)
[ 0.384476] UDP-Lite hash table entries: 512 (order: 2, 16384 bytes, linear)
[ 0.384829] NET: Registered PF_UNIX/PF_LOCAL protocol family
[ 0.386218] RPC: Registered named UNIX socket transport module.
[ 0.386240] RPC: Registered udp transport module.
[ 0.386255] RPC: Registered tcp transport module.
[ 0.386270] RPC: Registered tcp NFSv4.1 backchannel transport module.
[ 0.386297] PCI: CLS 0 bytes, default 64
[ 0.389351] hw perfevents: enabled with armv8_cortex_a53 PMU driver, 7 counters available
[ 0.389697] kvm [1]: IPA Size Limit: 40 bits
[ 0.391413] kvm [1]: Hyp mode initialized successfully
[ 1.737580] Initialise system trusted keyrings
[ 1.738114] workingset: timestamp_bits=46 max_order=18 bucket_order=0
[ 1.748991] zbud: loaded
[ 1.751906] FS-Cache: Netfs 'nfs' registered for caching
[ 1.752887] NFS: Registering the id_resolver key type
[ 1.752940] Key type id_resolver registered
[ 1.752957] Key type id_legacy registered
[ 1.753113] nfs4filelayout_init: NFSv4 File Layout Driver Registering...
[ 1.753133] nfs4flexfilelayout_init: NFSv4 Flexfile Layout Driver Registering...
[ 1.754869] Key type asymmetric registered
[ 1.754890] Asymmetric key parser 'x509' registered
[ 1.755006] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 247)
[ 1.755405] io scheduler mq-deadline registered
[ 1.755426] io scheduler kyber registered
[ 1.773422] bcm2835-rng 3f104000.rng: hwrng registered
[ 1.774398] vc-mem: phys_addr:0x00000000 mem_base=0x3ec00000 mem_size:0x40000000(1024 MiB)
[ 1.776483] gpiomem-bcm2835 3f200000.gpiomem: Initialised: Registers at 0x3f200000
[ 1.795889] brd: module loaded
[ 1.810962] loop: module loaded
[ 1.812063] Loading iSCSI transport class v2.0-870.
[ 1.819016] usbcore: registered new interface driver r8152
[ 1.819135] usbcore: registered new interface driver lan78xx
[ 1.819221] usbcore: registered new interface driver smsc95xx
[ 1.819949] dwc_otg: version 3.00a 10-AUG-2012 (platform bus)
[ 2.548553] Core Release: 2.80a
[ 2.548593] Setting default values for core params
[ 2.548629] Finished setting default values for core params
[ 2.749089] Using Buffer DMA mode
[ 2.749105] Periodic Transfer Interrupt Enhancement - disabled
[ 2.749121] Multiprocessor Interrupt Enhancement - disabled
[ 2.749136] OTG VER PARAM: 0, OTG VER FLAG: 0
[ 2.749159] Dedicated Tx FIFOs mode
[ 2.753826] WARN::dwc_otg_hcd_init:1074: FIQ DMA bounce buffers: virt = ffffffc008469000 dma = 0x00000000df000000 len=9024
[ 2.753872] FIQ FSM acceleration enabled for :
Non-periodic Split Transactions
Periodic Split Transactions
High-Speed Isochronous Endpoints
Interrupt/Control Split Transaction hack enabled
[ 2.753894] dwc_otg: Microframe scheduler enabled
[ 2.753971] WARN::hcd_init_fiq:497: MPHI regs_base at ffffffc00806d000
[ 2.754067] dwc_otg 3f980000.usb: DWC OTG Controller
[ 2.754112] dwc_otg 3f980000.usb: new USB bus registered, assigned bus number 1
[ 2.754176] dwc_otg 3f980000.usb: irq 74, io mem 0x00000000
[ 2.754238] Init: Port Power? op_state=1
[ 2.754253] Init: Power Port (0)
[ 2.754801] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 5.15
[ 2.754829] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 2.754851] usb usb1: Product: DWC OTG Controller
[ 2.754871] usb usb1: Manufacturer: Linux 5.15.61-v8+ dwc_otg_hcd
[ 2.754890] usb usb1: SerialNumber: 3f980000.usb
[ 2.755971] hub 1-0:1.0: USB hub found
[ 2.756066] hub 1-0:1.0: 1 port detected
[ 2.757348] dwc_otg: FIQ enabled
[ 2.757366] dwc_otg: NAK holdoff enabled
[ 2.757381] dwc_otg: FIQ split-transaction FSM enabled
[ 2.757403] Module dwc_common_port init
[ 2.758172] usbcore: registered new interface driver uas
[ 2.758298] usbcore: registered new interface driver usb-storage
[ 2.758645] mousedev: PS/2 mouse device common for all mice
[ 2.764731] sdhci: Secure Digital Host Controller Interface driver
[ 2.764757] sdhci: Copyright(c) Pierre Ossman
[ 2.765555] sdhci-pltfm: SDHCI platform and OF driver helper
[ 2.769720] ledtrig-cpu: registered to indicate activity on CPUs
[ 2.770515] hid: raw HID events driver (C) Jiri Kosina
[ 2.770734] usbcore: registered new interface driver usbhid
[ 2.770753] usbhid: USB HID core driver
[ 2.771222] ashmem: initialized
[ 2.779546] NET: Registered PF_PACKET protocol family
[ 2.779823] Key type dns_resolver registered
[ 2.781767] registered taskstats version 1
[ 2.781814] Loading compiled-in X.509 certificates
[ 2.782902] Key type ._fscrypt registered
[ 2.782923] Key type .fscrypt registered
[ 2.782938] Key type fscrypt-provisioning registered
[ 2.802779] uart-pl011 3f201000.serial: cts_event_workaround enabled
[ 2.802996] 3f201000.serial: ttyAMA0 at MMIO 0x3f201000 (irq = 99, base_baud = 0) is a PL011 rev2
[ 2.808938] bcm2835-wdt bcm2835-wdt: Broadcom BCM2835 watchdog timer
[ 2.809642] bcm2835-power bcm2835-power: Broadcom BCM2835 power domains driver
[ 2.812440] mmc-bcm2835 3f300000.mmcnr: mmc_debug:0 mmc_debug2:0
[ 2.812467] mmc-bcm2835 3f300000.mmcnr: DMA channel allocated
[ 2.839527] sdhost: log_buf @ 000000004db341b1 (c2d1d000)
[ 2.867987] Indeed it is in host mode hprt0 = 00021501
[ 2.910143] mmc0: sdhost-bcm2835 loaded - DMA enabled (>1)
[ 2.915119] of_cfs_init
[ 2.915303] of_cfs_init: OK
[ 2.917831] Waiting for root device PARTUUID=d823e4c0-02...
[ 2.981164] mmc0: host does not support reading read-only switch, assuming write-enable
[ 2.985520] mmc0: new high speed SDHC card at address aaaa
[ 2.987588] mmcblk0: mmc0:aaaa SC16G 14.8 GiB
[ 2.997956] mmc1: new high speed SDIO card at address 0001
[ 3.001343] mmcblk0: p1 p2
[ 3.002161] mmcblk0: mmc0:aaaa SC16G 14.8 GiB
[ 3.029353] EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode. Opts: (null). Quota mode: none.
[ 3.029493] VFS: Mounted root (ext4 filesystem) readonly on device 179:2.
[ 3.030702] devtmpfs: mounted
[ 3.041658] Freeing unused kernel memory: 3840K
[ 3.041861] Run /sbin/init as init process
[ 3.041880] with arguments:
[ 3.041893] /sbin/init
[ 3.041906] splash
[ 3.041920] with environment:
[ 3.041932] HOME=/
[ 3.041945] TERM=linux
[ 3.059818] usb 1-1: new high-speed USB device number 2 using dwc_otg
[ 3.060098] Indeed it is in host mode hprt0 = 00001101
[ 3.268435] usb 1-1: New USB device found, idVendor=0424, idProduct=9514, bcdDevice= 2.00
[ 3.268498] usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[ 3.269710] hub 1-1:1.0: USB hub found
[ 3.269912] hub 1-1:1.0: 5 ports detected
[ 3.559820] usb 1-1.1: new high-speed USB device number 3 using dwc_otg
[ 3.657471] systemd[1]: System time before build time, advancing clock.
[ 3.660461] usb 1-1.1: New USB device found, idVendor=0424, idProduct=ec00, bcdDevice= 2.00
[ 3.660498] usb 1-1.1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[ 3.663692] smsc95xx v2.0.0
[ 3.813011] SMSC LAN8700 usb-001:003:01: attached PHY driver (mii_bus:phy_addr=usb-001:003:01, irq=POLL)
[ 3.814225] smsc95xx 1-1.1:1.0 eth0: register 'smsc95xx' at usb-3f980000.usb-1.1, smsc95xx USB 2.0 Ethernet, m.m.m.m
[ 3.891840] usb 1-1.2: new full-speed USB device number 4 using dwc_otg
[ 3.967242] NET: Registered PF_INET6 protocol family
[ 3.969906] Segment Routing with IPv6
[ 3.969973] In-situ OAM (IOAM) with IPv6
[ 4.005018] usb 1-1.2: New USB device found, idVendor=046d, idProduct=c534, bcdDevice=29.00
[ 4.005063] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 4.005086] usb 1-1.2: Product: USB Receiver
[ 4.005105] usb 1-1.2: Manufacturer: Logitech
[ 4.012262] input: Logitech USB Receiver as /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.2/1-1.2:1.0/0003:046D:C534.0001/input/input0
[ 4.065753] systemd[1]: systemd 247.3-7+deb11u1 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +ZSTD +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN +PCRE2 default-hierarchy=unified)
[ 4.067271] systemd[1]: Detected architecture arm64.
[ 4.073156] hid-generic 0003:046D:C534.0001: input,hidraw0: USB HID v1.11 Keyboard [Logitech USB Receiver] on usb-3f980000.usb-1.2/input0
[ 4.075447] systemd[1]: Set hostname to .
[ 4.084662] input: Logitech USB Receiver Mouse as /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.2/1-1.2:1.1/0003:046D:C534.0002/input/input1
[ 4.085529] input: Logitech USB Receiver Consumer Control as /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.2/1-1.2:1.1/0003:046D:C534.0002/input/input2
[ 4.144511] input: Logitech USB Receiver System Control as /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.2/1-1.2:1.1/0003:046D:C534.0002/input/input3
[ 4.145599] hid-generic 0003:046D:C534.0002: input,hiddev96,hidraw1: USB HID v1.11 Mouse [Logitech USB Receiver] on usb-3f980000.usb-1.2/input1
[ 4.223884] usb 1-1.3: new high-speed USB device number 5 using dwc_otg
[ 4.335995] usb 1-1.3: New USB device found, idVendor=05e3, idProduct=0723, bcdDevice=94.54
[ 4.336041] usb 1-1.3: New USB device strings: Mfr=3, Product=4, SerialNumber=0
[ 4.336065] usb 1-1.3: Product: USB Storage
[ 4.336084] usb 1-1.3: Manufacturer: Generic
[ 4.337808] usb-storage 1-1.3:1.0: USB Mass Storage device detected
[ 4.338883] scsi host0: usb-storage 1-1.3:1.0
[ 4.563855] usb 1-1.5: new full-speed USB device number 6 using dwc_otg
[ 4.674522] usb 1-1.5: New USB device found, idVendor=1a86, idProduct=e5e3, bcdDevice= 0.00
[ 4.674567] usb 1-1.5: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 4.674590] usb 1-1.5: Product: USB2IIC_CTP_CONTROL
[ 4.674610] usb 1-1.5: Manufacturer: wch.cn
[ 4.712231] input: wch.cn USB2IIC_CTP_CONTROL as /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.5/1-1.5:1.0/0003:1A86:E5E3.0003/input/input6
[ 4.713037] hid-generic 0003:1A86:E5E3.0003: input,hidraw2: USB HID v1.00 Device [wch.cn USB2IIC_CTP_CONTROL] on usb-3f980000.usb-1.5/input0
[ 5.064625] systemd[1]: /lib/systemd/system/plymouth-start.service:16: Unit configured to use KillMode=none. This is unsafe, as it disables systemd's process lifecycle management for the service. Please update your service to use a safer KillMode=, such as 'mixed' or 'control-group'. Support for KillMode=none is deprecated and will eventually be removed.
[ 5.308224] systemd[1]: Queued start job for default target Graphical Interface.
[ 5.317343] systemd[1]: Created slice system-getty.slice.
[ 5.319608] systemd[1]: Created slice system-modprobe.slice.
[ 5.321336] systemd[1]: Created slice system-systemd\x2dfsck.slice.
[ 5.322588] systemd[1]: Created slice User and Session Slice.
[ 5.323331] systemd[1]: Started Forward Password Requests to Wall Directory Watch.
[ 5.325115] systemd[1]: Set up automount Arbitrary Executable File Formats File System Automount Point.
[ 5.325901] systemd[1]: Reached target Slices.
[ 5.326092] systemd[1]: Reached target Swap.
[ 5.333360] systemd[1]: Listening on Syslog Socket.
[ 5.334611] systemd[1]: Listening on fsck to fsckd communication Socket.
[ 5.335190] systemd[1]: Listening on initctl Compatibility Named Pipe.
[ 5.337315] systemd[1]: Listening on Journal Audit Socket.
[ 5.338519] systemd[1]: Listening on Journal Socket (/dev/log).
[ 5.340006] systemd[1]: Listening on Journal Socket.
[ 5.345498] scsi 0:0:0:0: Direct-Access Generic STORAGE DEVICE 9454 PQ: 0 ANSI: 0
[ 5.347100] sd 0:0:0:0: [sda] Media removed, stopped polling
[ 5.347436] systemd[1]: Listening on udev Control Socket.
[ 5.349013] systemd[1]: Listening on udev Kernel Socket.
[ 5.350743] sd 0:0:0:0: [sda] Attached SCSI removable disk
[ 5.350865] systemd[1]: Condition check resulted in Huge Pages File System being skipped.
[ 5.357209] systemd[1]: Mounting POSIX Message Queue File System...
[ 5.364145] systemd[1]: Mounting RPC Pipe File System...
[ 5.372914] systemd[1]: Mounting Kernel Debug File System...
[ 5.380865] systemd[1]: Mounting Kernel Trace File System...
[ 5.381550] systemd[1]: Condition check resulted in Kernel Module supporting RPCSEC_GSS being skipped.
[ 5.394286] systemd[1]: Starting Restore / save the current clock...
[ 5.402147] systemd[1]: Starting Set the console keyboard layout...
[ 5.410488] systemd[1]: Starting Create list of static device nodes for the current kernel...
[ 5.418863] systemd[1]: Starting Load Kernel Module configfs...
[ 5.427359] systemd[1]: Starting Load Kernel Module drm...
[ 5.436668] systemd[1]: Starting Load Kernel Module fuse...
[ 5.456444] systemd[1]: Condition check resulted in Set Up Additional Binary Formats being skipped.
[ 5.470082] systemd[1]: Starting File System Check on Root Device...
[ 5.487291] systemd[1]: Starting Journal Service...
[ 5.526755] systemd[1]: Starting Load Kernel Modules...
[ 5.543131] systemd[1]: Starting Coldplug All udev Devices...
[ 5.578487] systemd[1]: Mounted POSIX Message Queue File System.
[ 5.584943] systemd[1]: Mounted RPC Pipe File System.
[ 5.586509] systemd[1]: Mounted Kernel Debug File System.
[ 5.588057] systemd[1]: Mounted Kernel Trace File System.
[ 5.591563] systemd[1]: Finished Restore / save the current clock.
[ 5.595691] systemd[1]: Finished Create list of static device nodes for the current kernel.
[ 5.610464] fuse: init (API version 7.34)
[ 5.613957] systemd[1]: [email protected]: Succeeded.
[ 5.617529] systemd[1]: Finished Load Kernel Module configfs.
[ 5.629814] systemd[1]: Mounting Kernel Configuration File System...
[ 5.639717] systemd[1]: Started File System Check Daemon to report status.
[ 5.645660] systemd[1]: [email protected]: Succeeded.
[ 5.648235] systemd[1]: Finished Load Kernel Module fuse.
[ 5.654207] i2c_dev: i2c /dev entries driver
[ 5.708459] systemd[1]: Mounting FUSE Control File System...
[ 5.737844] systemd[1]: Finished Load Kernel Modules.
[ 5.742313] systemd[1]: [email protected]: Succeeded.
[ 5.744696] systemd[1]: Finished Load Kernel Module drm.
[ 5.746637] systemd[1]: Mounted Kernel Configuration File System.
[ 5.748010] systemd[1]: Mounted FUSE Control File System.
[ 5.755604] systemd[1]: Starting Apply Kernel Variables...
[ 5.855240] systemd[1]: Finished File System Check on Root Device.
[ 5.863886] systemd[1]: Starting Remount Root and Kernel File Systems...
[ 5.867546] systemd[1]: Finished Apply Kernel Variables.
[ 6.051608] systemd[1]: Started Journal Service.
[ 6.137158] EXT4-fs (mmcblk0p2): re-mounted. Opts: (null). Quota mode: none.
[ 6.268201] systemd-journald[138]: Received client request to flush runtime journal.
[ 6.274685] systemd-journald[138]: File /var/log/journal/b9729f7115d045c0bcb30117269d548b/system.journal corrupted or uncleanly shut down, renaming and replacing.
[ 7.369795] sd 0:0:0:0: Attached scsi generic sg0 type 0
[ 7.948473] mc: Linux media interface: v0.10
[ 7.968939] vc_sm_cma: module is from the staging directory, the quality is unknown, you have been warned.
[ 7.991917] bcm2835_vc_sm_cma_probe: Videocore shared memory driver
[ 7.991978] [vc_sm_connected_init]: start
[ 8.010712] [vc_sm_connected_init]: installed successfully
[ 8.098968] videodev: Linux video capture interface: v2.00
[ 8.185579] bcm2835_mmal_vchiq: module is from the staging directory, the quality is unknown, you have been warned.
[ 8.187966] bcm2835_mmal_vchiq: module is from the staging directory, the quality is unknown, you have been warned.
[ 8.207253] bcm2835_isp: module is from the staging directory, the quality is unknown, you have been warned.
[ 8.235632] bcm2835-isp bcm2835-isp: Device node output[0] registered as /dev/video13
[ 8.237213] bcm2835-isp bcm2835-isp: Device node capture[0] registered as /dev/video14
[ 8.237938] bcm2835-isp bcm2835-isp: Device node capture[1] registered as /dev/video15
[ 8.238491] bcm2835-isp bcm2835-isp: Device node stats[2] registered as /dev/video16
[ 8.238543] bcm2835-isp bcm2835-isp: Register output node 0 with media controller
[ 8.238580] bcm2835-isp bcm2835-isp: Register capture node 1 with media controller
[ 8.238608] bcm2835-isp bcm2835-isp: Register capture node 2 with media controller
[ 8.238635] bcm2835-isp bcm2835-isp: Register capture node 3 with media controller
[ 8.240186] bcm2835_v4l2: module is from the staging directory, the quality is unknown, you have been warned.
[ 8.251285] bcm2835-isp bcm2835-isp: Device node output[0] registered as /dev/video20
[ 8.252525] bcm2835-isp bcm2835-isp: Device node capture[0] registered as /dev/video21
[ 8.253459] bcm2835-isp bcm2835-isp: Device node capture[1] registered as /dev/video22
[ 8.253994] bcm2835-isp bcm2835-isp: Device node stats[2] registered as /dev/video23
[ 8.254043] bcm2835-isp bcm2835-isp: Register output node 0 with media controller
[ 8.254076] bcm2835-isp bcm2835-isp: Register capture node 1 with media controller
[ 8.254104] bcm2835-isp bcm2835-isp: Register capture node 2 with media controller
[ 8.254131] bcm2835-isp bcm2835-isp: Register capture node 3 with media controller
[ 8.254475] bcm2835-isp bcm2835-isp: Loaded V4L2 bcm2835-isp
[ 8.309091] snd_bcm2835: module is from the staging directory, the quality is unknown, you have been warned.
[ 8.364490] bcm2835_codec: module is from the staging directory, the quality is unknown, you have been warned.
[ 8.392057] bcm2835_audio bcm2835_audio: card created with 8 channels
[ 8.424533] bcm2835-codec bcm2835-codec: Device registered as /dev/video10
[ 8.424630] bcm2835-codec bcm2835-codec: Loaded V4L2 decode
[ 8.432806] bcm2835-codec bcm2835-codec: Device registered as /dev/video11
[ 8.432900] bcm2835-codec bcm2835-codec: Loaded V4L2 encode
[ 8.440890] bcm2835-codec bcm2835-codec: Device registered as /dev/video12
[ 8.440970] bcm2835-codec bcm2835-codec: Loaded V4L2 isp
[ 8.453112] bcm2835-codec bcm2835-codec: Device registered as /dev/video18
[ 8.453209] bcm2835-codec bcm2835-codec: Loaded V4L2 image_fx
[ 8.459361] bcm2835-codec bcm2835-codec: Device registered as /dev/video31
[ 8.459443] bcm2835-codec bcm2835-codec: Loaded V4L2 encode_image
[ 8.921799] cfg80211: Loading compiled-in X.509 certificates for regulatory database
[ 9.027254] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
[ 9.049539] cfg80211: loaded regulatory.db is malformed or signature is missing/invalid
[ 9.184522] logitech-djreceiver 0003:046D:C534.0001: hidraw0: USB HID v1.11 Keyboard [Logitech USB Receiver] on usb-3f980000.usb-1.2/input0
[ 9.461473] brcmfmac: F1 signature read @0x18000000=0x1541a9a6
[ 9.483585] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43430-sdio for chip BCM43430/1
[ 9.485827] input: wch.cn USB2IIC_CTP_CONTROL as /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.5/1-1.5:1.0/0003:1A86:E5E3.0003/input/input7
[ 9.487554] hid-multitouch 0003:1A86:E5E3.0003: input,hidraw1: USB HID v1.00 Device [wch.cn USB2IIC_CTP_CONTROL] on usb-3f980000.usb-1.5/input0
[ 9.492683] logitech-djreceiver 0003:046D:C534.0002: hiddev96,hidraw2: USB HID v1.11 Mouse [Logitech USB Receiver] on usb-3f980000.usb-1.2/input1
[ 9.493133] usbcore: registered new interface driver brcmfmac
[ 9.499249] brcmfmac mmc1:0001:1: Direct firmware load for brcm/brcmfmac43430-sdio.raspberrypi,3-model-b.bin failed with error -2
[ 9.558924] logitech-djreceiver 0003:046D:C534.0002: device of type eQUAD nano Lite (0x0a) connected on slot 1
[ 9.565600] input: Logitech Wireless Keyboard PID:4023 Keyboard as /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.2/1-1.2:1.1/0003:046D:C534.0002/0003:046D:4023.0004/input/input8
[ 9.575917] logitech-djreceiver 0003:046D:C534.0002: device of type eQUAD nano Lite (0x0a) connected on slot 2
[ 9.587607] hid-generic 0003:046D:4023.0004: input,hidraw3: USB HID v1.11 Keyboard [Logitech Wireless Keyboard PID:4023] on usb-3f980000.usb-1.2/input1:1
[ 9.603225] input: Logitech Wireless Mouse PID:4022 Mouse as /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.2/1-1.2:1.1/0003:046D:C534.0002/0003:046D:4022.0005/input/input13
[ 9.675147] hid-generic 0003:046D:4022.0005: input,hidraw4: USB HID v1.11 Mouse [Logitech Wireless Mouse PID:4022] on usb-3f980000.usb-1.2/input1:2
[ 9.776259] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43430-sdio for chip BCM43430/1
[ 9.776534] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43430-sdio for chip BCM43430/1
[ 9.800149] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM43430/1 wl0: Jul 19 2021 03:24:18 version 7.45.98 (TOB) (56df937 CY) FWID 01-8e14b897
[ 10.070195] checking generic (3ea65000 195000) vs hw (0 ffffffffffffffff)
[ 10.070242] fb0: switching to vc4 from simple
[ 10.092247] Console: switching to colour dummy device 80x25
[ 10.114727] vc4-drm soc:gpu: bound 3f400000.hvs (ops vc4_hvs_ops [vc4])
[ 10.124642] Registered IR keymap rc-cec
[ 10.171423] rc rc0: vc4 as /devices/platform/soc/3f902000.hdmi/rc/rc0
[ 10.175660] input: vc4 as /devices/platform/soc/3f902000.hdmi/rc/rc0/input17
[ 11.195094] uart-pl011 3f201000.serial: no DMA platform data
[ 11.215586] 8021q: 802.1Q VLAN Support v1.8
[ 11.604659] Adding 102396k swap on /var/swap. Priority:-2 extents:1 across:102396k SSFS
[ 11.853328] smsc95xx 1-1.1:1.0 eth0: hardware isn't capable of remote wakeup
[ 12.010297] smsc95xx 1-1.1:1.0 eth0: Link is Down
[ 13.347018] vc4-drm soc:gpu: bound 3f400000.hvs (ops vc4_hvs_ops [vc4])
[ 13.354748] Registered IR keymap rc-cec
[ 13.366470] rc rc0: vc4 as /devices/platform/soc/3f902000.hdmi/rc/rc0
[ 13.389900] input: vc4 as /devices/platform/soc/3f902000.hdmi/rc/rc0/input18
[ 13.430728] vc4-drm soc:gpu: bound 3f902000.hdmi (ops vc4_hdmi_ops [vc4])
[ 13.431188] vc4-drm soc:gpu: bound 3f004000.txp (ops vc4_txp_ops [vc4])
[ 13.431521] vc4-drm soc:gpu: bound 3f206000.pixelvalve (ops vc4_crtc_ops [vc4])
[ 13.433636] vc4-drm soc:gpu: bound 3f207000.pixelvalve (ops vc4_crtc_ops [vc4])
[ 13.433993] vc4-drm soc:gpu: bound 3f807000.pixelvalve (ops vc4_crtc_ops [vc4])
[ 13.434236] vc4-drm soc:gpu: bound 3fc00000.v3d (ops vc4_v3d_ops [vc4])
[ 13.466790] [drm] Initialized vc4 0.0.0 20140616 for soc:gpu on minor 0
[ 13.522771] Console: switching to colour frame buffer device 90x36
[ 13.522834] vc4-drm soc:gpu: [drm] fb0: vc4drmfb frame buffer device
[ 13.553263] brcmfmac: brcmf_cfg80211_set_power_mgmt: power save enabled
[ 13.756471] input: Logitech Wireless Keyboard PID:4023 as /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.2/1-1.2:1.1/0003:046D:C534.0002/0003:046D:4023.0004/input/input19
[ 13.760377] logitech-hidpp-device 0003:046D:4023.0004: input,hidraw3: USB HID v1.11 Keyboard [Logitech Wireless Keyboard PID:4023] on usb-3f980000.usb-1.2/input1:1
[ 13.871140] input: Logitech Wireless Mouse PID:4022 as /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.2/1-1.2:1.1/0003:046D:C534.0002/0003:046D:4022.0005/input/input20
[ 13.872726] logitech-hidpp-device 0003:046D:4022.0005: input,hidraw4: USB HID v1.11 Mouse [Logitech Wireless Mouse PID:4022] on usb-3f980000.usb-1.2/input1:2
[ 15.360868] smsc95xx 1-1.1:1.0 eth0: Link is Up - 100Mbps/Full - flow control off
[ 15.360936] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[ 16.143132] Bluetooth: Core ver 2.22
[ 16.143272] NET: Registered PF_BLUETOOTH protocol family
[ 16.143281] Bluetooth: HCI device and connection manager initialized
[ 16.143309] Bluetooth: HCI socket layer initialized
[ 16.143324] Bluetooth: L2CAP socket layer initialized
[ 16.143356] Bluetooth: SCO socket layer initialized
[ 16.159462] Bluetooth: HCI UART driver ver 2.3
[ 16.159493] Bluetooth: HCI UART protocol H4 registered
[ 16.159596] Bluetooth: HCI UART protocol Three-wire (H5) registered
[ 16.160008] Bluetooth: HCI UART protocol Broadcom registered
[ 16.584366] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[ 16.584396] Bluetooth: BNEP filters: protocol multicast
[ 16.584424] Bluetooth: BNEP socket layer initialized
[ 16.614870] NET: Registered PF_ALG protocol family
[ 19.890063] Bluetooth: RFCOMM TTY layer initialized
[ 19.890115] Bluetooth: RFCOMM socket layer initialized
[ 19.890156] Bluetooth: RFCOMM ver 1.11
[ 32.632794] logitech-hidpp-device 0003:046D:4022.0005: HID++ 2.0 device connected.
[ 33.759868] cam-dummy-reg: disabling
[ 51.229800] logitech-hidpp-device 0003:046D:4023.0004: HID++ 2.0 device connected.
[ 267.818216] Invalid architecture in ELF header: 40
[ 314.298827] irqtest: loading out-of-tree module taints kernel.
[ 314.299891] irqtest:mod_init - major is 235
[ 314.299920] irqtest:mod_init - registered device: 246415360 000000004616acf1 0000000070ed5ce6
[ 314.300275] irqtest:mod_init - created device 0 00000000580cd165
[ 314.300290] irqtest:mod_init - installed by "insmod" (pid 1833) at 000000000333ad62
[ 337.072045] irqtest:open - open device 235:0
[ 337.072491] irqtest:open - Registered IRQ 184 for pin 4.
[ 337.072617] irqtest:read - Starting operation.
[ 337.072637] irqtest:irq_service - 4:184 - bad interrupt 1/0 after 337065325 us counts: 1:0
[ 337.102662] irqtest:irq_service - 4:184 - bad interrupt 1/1 after 8 us counts: 2:61
[ 342.020124] irqtest:irq_service - 4:184 - bad interrupt 0/0 after 4 us counts: 3:9897
[ 342.278626] irqtest:irq_service - 4:184 - bad interrupt 1/1 after 5 us counts: 4:10415
[ 343.044627] irqtest:irq_service - 4:184 - bad interrupt 1/1 after 7 us counts: 5:11948
[ 344.068625] irqtest:irq_service - 4:184 - bad interrupt 1/1 after 7 us counts: 6:13997
[ 344.085627] irqtest:irq_service - 4:184 - bad interrupt 1/1 after 7 us counts: 7:14032
[ 346.895120] irqtest:irq_service - 4:184 - bad interrupt 0/0 after 6 us counts: 8:19652
[ 346.955618] irqtest:irq_service - 4:184 - bad interrupt 1/1 after 6 us counts: 9:19774
[ 347.370125] irqtest:irq_service - 4:184 - bad interrupt 0/0 after 8 us counts: 10:20604
[ 347.917621] irqtest:irq_service - 4:184 - bad interrupt 1/1 after 7 us counts: 11:21700
[ 347.918625] irqtest:irq_service - 4:184 - bad interrupt 1/1 after 8 us counts: 12:21703
[ 347.937621] irqtest:irq_service - 4:184 - bad interrupt 1/1 after 10 us counts: 13:21742
[ 348.952614] irqtest:irq_service - 4:184 - bad interrupt 1/1 after 7 us counts: 14:23773
[ 348.969618] irqtest:irq_service - 4:184 - bad interrupt 1/1 after 9 us counts: 15:23808
[ 348.976616] irqtest:irq_service - 4:184 - bad interrupt 1/1 after 8 us counts: 16:23823
[ 348.977615] irqtest:irq_service - 4:184 - bad interrupt 1/1 after 6 us counts: 17:23826
[ 349.422615] irqtest:irq_service - 4:184 - bad interrupt 1/1 after 8 us counts: 18:24717
[ 349.463621] irqtest:irq_service - 4:184 - bad interrupt 1/1 after 9 us counts: 19:24800
[ 349.502615] irqtest:irq_service - 4:184 - bad interrupt 1/1 after 7 us counts: 20:24879
[ 349.504614] irqtest:irq_service - 4:184 - bad interrupt 1/1 after 8 us counts: 21:24884
[ 354.533604] irqtest:irq_service - 4:184 - bad interrupt 1/1 after 8 us counts: 22:34943
[ 354.536605] irqtest:irq_service - 4:184 - bad interrupt 1/1 after 7 us counts: 23:34950
[ 354.538601] irqtest:irq_service - 4:184 - bad interrupt 1/1 after 6 us counts: 24:34955
[ 354.540601] irqtest:irq_service - 4:184 - bad interrupt 1/1 after 5 us counts: 25:34960
[ 354.542599] irqtest:irq_service - 4:184 - bad interrupt 1/1 after 5 us counts: 26:34965
[ 354.544601] irqtest:irq_service - 4:184 - bad interrupt 1/1 after 7 us counts: 27:34970
[ 354.548601] irqtest:irq_service - 4:184 - bad interrupt 1/1 after 7 us counts: 28:34979
[ 354.552603] irqtest:irq_service - 4:184 - bad interrupt 1/1 after 7 us counts: 29:34988
[ 354.557606] irqtest:irq_service - 4:184 - bad interrupt 1/1 after 7 us counts: 30:34999
[ 354.559604] irqtest:irq_service - 4:184 - bad interrupt 1/1 after 6 us counts: 31:35004
[ 354.568606] irqtest:irq_service - 4:184 - bad interrupt 1/1 after 8 us counts: 32:35023
[ 354.569600] irqtest:irq_service - 4:184 - bad interrupt 1/1 after 4 us counts: 33:35026
[ 354.570597] irqtest:irq_service - 4:184 - bad interrupt 1/1 after 4 us counts: 34:35029
[ 354.575601] irqtest:irq_service - 4:184 - bad interrupt 1/1 after 7 us counts: 35:35040
[ 354.576595] irqtest:irq_service - 4:184 - bad interrupt 1/1 after 3 us counts: 36:35043
[ 354.577605] irqtest:irq_service - 4:184 - bad interrupt 1/1 after 5 us counts: 37:35046
[ 354.578600] irqtest:irq_service - 4:184 - bad interrupt 1/1 after 3 us counts: 38:35049
[ 354.579603] irqtest:irq_service - 4:184 - bad interrupt 1/1 after 4 us counts: 39:35052
[ 354.583617] irqtest:irq_service - 4:184 - bad interrupt 1/1 after 7 us counts: 40:35061
[ 354.585604] irqtest:irq_service - 4:184 - bad interrupt 1/1 after 6 us counts: 41:35066
[ 354.590602] irqtest:irq_service - 4:184 - bad interrupt 1/1 after 7 us counts: 42:35077
[ 354.594602] irqtest:irq_service - 4:184 - bad interrupt 1/1 after 7 us counts: 43:35086
[ 354.596602] irqtest:irq_service - 4:184 - bad interrupt 1/1 after 6 us counts: 44:35091
[ 354.598598] irqtest:irq_service - 4:184 - bad interrupt 1/1 after 6 us counts: 45:35096
[ 354.606605] irqtest:irq_service - 4:184 - bad interrupt 1/1 after 7 us counts: 46:35113
[ 354.609609] irqtest:irq_service - 4:184 - bad interrupt 1/1 after 8 us counts: 47:35120
[ 354.615606] irqtest:irq_service - 4:184 - bad interrupt 1/1 after 8 us counts: 48:35133
[ 354.617598] irqtest:irq_service - 4:184 - bad interrupt 1/1 after 3 us counts: 49:35138
[ 354.619600] irqtest:irq_service - 4:184 - bad interrupt 1/1 after 4 us counts: 50:35143
[ 354.623605] irqtest:irq_service - 4:184 - bad interrupt 1/1 after 7 us counts: 51:35152
[ 354.626604] irqtest:irq_service - 4:184 - bad interrupt 1/1 after 6 us counts: 52:35159
[ 354.632605] irqtest:irq_service - 4:184 - bad interrupt 1/1 after 7 us counts: 53:35172
[ 354.968102] irqtest:read - Stop. Bad events: 53 / 35844
[ 354.968523] irqtest:release - close request for pin 4
pi@raspberrypi:~/irqtest $
Logs
No response
Additional context
No response
The text was updated successfully, but these errors were encountered: