Opened 5 years ago

Closed 5 years ago

#796 closed defect (fixed)

Lots of spurious interrupts on ppc32 after upgrade to QEMU 4.0.0

Reported by: Jakub Jermář Owned by:
Priority: major Milestone: 0.9.1
Component: helenos/kernel/ppc32 Version: mainline
Keywords: Cc:
Blocker for: Depends on:
See also:


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.

Change History (4)

comment:1 by Jakub Jermář, 5 years ago

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

comment:2 by Jakub Jermář, 5 years ago

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
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.

comment:3 by Jakub Jermář, 5 years ago

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.

comment:4 by Jiri Svoboda, 5 years ago

Milestone: 0.9.1
Resolution: fixed
Status: newclosed
Note: See TracTickets for help on using tickets.