Lots of spurious interrupts on ppc32 after upgrade to QEMU 4.0.0

[Jakub Jermář]

After upgrading to QEMU 4.0.0, HelenOS is stormed by many spurious interrupt messages during boot:

cpu0: spurious interrupt (inum=10) 

The system nevertheless boots eventually, but exhibits jerkiness.

[Jakub Jermář]

Seems to be caused by QEMU commit ​d6c666ad81f6f771ff40bb9c72dde327e6c87846. Not clear if this is a QEMU regression or something that HelenOS needs to adapt to.

[Jakub Jermář]

Using the following QEMU tracing options:

-trace 'mos6522_*' -trace 'cuda_*' -trace '*irq*' -d int

we get this trace around the time when the first message appears (i.e. shortly after the uspace cuda driver kicks in):

2176925@1557054210.879586:mos6522_write reg=0xa val=0x1
2176925@1557054210.879617:mos6522_read reg=0x0 val=0x8
2176925@1557054210.879664:mos6522_write reg=0x0 val=0x18
2176925@1557054210.879672:cuda_data_send send: 0x01
2176925@1557054210.879677:cuda_delay_set_sr_int 
2176918@1557054210.879704:mos6522_set_sr_int set sr_int
2176925@1557054210.879740:mos6522_write reg=0xd val=0x4
2176925@1557054210.879751:heathrow_set_irq set_irq: num=0x12 level=0
Raise exception at 018014b8 => 00000004 (00)       <=== VECTOR_EXTERNAL while in uspace
Raise exception at 8000e168 => 00000002 (00)       <=== VECTOR_DATA_STORAGE while in cuda_claim
Raise exception at 8002ac18 => 00000002 (00)       <=== VECTOR_DATA_STORAGE while in memcpy    
Raise exception at 8002ac18 => 00000002 (00)       <=== ...
Raise exception at 8002ac18 => 00000002 (00)
Raise exception at 8002ac18 => 00000002 (00)
...

The last line then repeats until a key is pressed.

What is strange about this is that there is only one external interrupt reported by QEMU, but according to the kernel, the external interrupts keep coming in.

[Jakub Jermář]

Starting from commit ​1fbe639b466afe078eca607954ab69d4ffba7e36 the kernel breaks out of the IRQ-processing loop in exception_external() when the IRQ is not claimed by anyone, resulting in a much saner behaviour - each spurious IRQ is logged just once.

The behaviour has changed now: there is no longer a flood of the spurious IRQ messages, but only one or a few later on when the UI has fully booted. The input is still jerky and lossy, probably because of these 'lost' interrupts. If I comment out CMD_PREDICATE from the cuda driver's IRQ pseudocode, these problems go away and the input is not jerky or lossy at all. But I guess it only points at some problem with the IRQ handling logic in the driver.

[Jiri Svoboda]

Fixed in changeset ​3fb14b058575b4d56650893d29ab2f3d5b7ed67a.