Unexpected pfrc (159712).

[Jakub Jermář]

During mainline testing before the upcoming 0.4.3 release, I hit the following panic on msim:

.. Sub-phase 2 (Alloc/Dealloc)
RARRAAARRRAAAARRARAARRRRRAARRRAAAARRARARRAAAARRRRAAARAAAARARRAARARRAARRRAAAAAAAA
RAAARARRRRRRARRRARRAAAAAAAAAARRRRRRRAAAARAAAARARAAAAARARRRAAARAARAAARARAARAAAAAR
RRRRAARRRRRARAARRARARAARAAARARRARARRRRAR
..  finished.
.. Sub-phase 3 (Deallocation)
RRRRRRRRRRRRRRARRRRRRRRRARRRRRRRRRRRRARRRRRRRRRRRRRRRRRRRRARRRRRRRRRRRRARRRRRRRR
RRRRRRRRRRRRRRRRRRRRRRRRRRRRARRRRRRRRRRRRARRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRARRR
RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRARRRRRF(R)
..  finished.
Phase finished.
Entering phase 2 (128 KB memory blocks)
.. Sub-phase 1 (Allocation)
ARAAAAAAAAAARAAAARAARAAAAAAARAAAAARRARRARAARRAAAAARARRAAAAAAARRAAAARAARRAAARAAAA
AAAAAAAARRAARRARAARRARAAAARAAARRARAAAAAAARARRAARRRAAAAA
######> Kernel panic on cpu0 due to the following reason: <######
Unexpected pfrc (159712).

0x8127fed0: generic/src/debug/stacktrace.o:stack_trace()+0x00000018
0x8127fef8: generic/src/debug/panic.o:panic_common()+0x00000104
0x8127ff30: arch/mips32/src/mm/tlb.o:tlb_refill()+0x000001dc
0x8127ff68: arch/mips32/src/start.o:tlb_refill_handler()+0x000000d8
cpu0: halted

[Jakub Jermář]

The issue is reproducible on msim 1.3.8 and mainline revision 885. To reproduce, boot HelenOS in msim using the config file from contrib and do:

# tester *

[Jakub Jermář]

Initializing the pfrc variable to some known value reveals that the variable remains uninitialized by the call to find_mapping_and_check(). After initializing it to 1234, I got:

Thread 7 waiting for 1 frames, 1 available.
Thread 36 woken up.
Thread 36 waiting for 1 frames, 1 available.
Thread 7 woken up.
Thread 7 waiting for 1 frames, 1 available.
Thread 36 woken up.
EntryHi.asid=6, AS->asid=30

######> Kernel panic on cpu0 due to the following reason: <######
Unexpected pfrc (1234).

0x816ebed0: generic/src/debug/stacktrace.o:stack_trace()+0x00000018
0x816ebef8: generic/src/debug/panic.o:panic_common()+0x00000104
0x816ebf30: arch/mips32/src/mm/tlb.o:tlb_refill()+0x000001e4
0x816ebf68: arch/mips32/src/start.o:tlb_refill_handler()+0x000000d8
cpu0: halted

Note the extra debugging information on the kconsole before the panic.

[Jiri Svoboda]

By looking at the code what happens is that the following if statement in find_mapping_and_check() is executed:

        /*
         * Handler cannot succeed if the ASIDs don't match.
         */
        if (hi.asid != AS->asid) {
                printf("EntryHi.asid=%d, AS->asid=%d\n", hi.asid, AS->asid);
                return NULL;
        }

Note that while we return NULL, we do not set *pfrc which the caller does no expect.

• Why don't the ASIDs match?
• What should be done when the ASIDs don't match?

[Jakub Jermář]

Replying to svoboda:

Note that while we return NULL, we do not set *pfrc which the caller does no expect.

• Why don't the ASIDs match?
• What should be done when the ASIDs don't match?

The ASIDs should match except for a little window in as_switch(). If they don't match, it is an error.

For the sake of debugging this, we should modify to code to print the information about the interrupted context, especially PC and registers and also the address which caused the TLB miss.

[Jakub Jermář]

istate→epc seems to be a userland address.

[Martin Decky]

I am unable to reproduce the issue with the current mainline (mainline,1582). Therefore I am closing this ticket. Feel free to reopen if this issue reappears.