IRC channel logs

<damo22>youpi1: when i enable the lapic timer on the AP, i get a stack overflow while interrupting on int stack

<damo22>LAPIC timer configured on cpu1

<damo22>Kernel Invalid opcode trap, eip 0xc103169c

<damo22>kernel: Invalid opcode (6), code=0

<damo22>Stopped at all_intrs+0xc0: ud2

<damo22>all_intrs(c117fb65,1,35ec1000,0,0)+0xc0

<damo22>cpu_setup(c1154648,0,0,c102ffef,0)+0x13f

<damo22>cpu_ap_main(0,0,0,0,0)+0x20

<damo22>switch_to_shutdown_context()

<damo22>if the timer interrupt occurs on AP, how does AP service it?

<damo22>if the timer interrupts repeatedly before the AP can send the EOI would that cause a stack overflow?

<damo22>on the int stack?

<youpi1>htat's the converse

<youpi1>stack overflow happens because the handler didn't manage to exit its stack before another interrupt happens

<youpi1>not sending EOI *avoids* that

<youpi1>but it shouldn't be a problem

<youpi1>provided that you have interrupts disabled between EOI and actually returning from the interrupt

<youpi1>in that case, getting another interrupt will just get back to the same stack position

<youpi1>because the interrupt will just trigger right after the iret instruction which atomically pops from the stack, and enables interrupts

<damo22>im getting stack overflow in int_from_intstack

<damo22>on AP

<youpi1>is it really a stack overflow?

<youpi1>or just that the stack_overflowed test doesn't know about AP stacks

<damo22>i thought i fixed that, but i dont know how to check exactly

<youpi1>always make sure that what you think happens is actually what happens

<youpi1>you can check the value of $rsp

<youpi1>against what it's suppsoed to be

<damo22>can kdb set a reg?

<damo22>or get the value?

<youpi1>obviuosluy

<youpi1>it'd be useless otherwise

<youpi1>show registers

<youpi1> info registers

<youpi1>something like that

<youpi1>see the gnumach manuel

<damo22>ok

<youpi1>the whole kdb is documented there

<damo22>#define ON_INT_STACK(P) (((P) & ~(NCPUS*INTSTACK_SIZE-1)) == int_stack_base[0])

<damo22>does that look like the right logic?

<damo22>i made the intstacks conti=guous

<damo22>so int_stack_base[i] = (vm_offset_t) &solid_intstack[i * INTSTACK_SIZE];

<damo22>i dont want to make the int stack check dependent on cpu_number

<damo22>so i can check if the value falls in the range of all the intstacks

<damo22>or maybe that wont work because it might overflow into the next stack

<damo22>and still pass the test

<youpi>damo22: that depends how exactly the int stacks are allocated

<gnu_srs1>Hi, I've now found out why a reboot hangs after: start ext2fs: Hurd server bootstrap: ext2fs[device:hd0s1] exec startup proc auth and before executing runsystem.

<gnu_srs1>settrans -c /proc /hurd/procfs --compatible does cause the hang: starting procfs as an active translator is OK. (but does not survive a reboot).

<gnu_srs1>Any ideas why??

<youpi>possibly somehow some of these translators try to open /proc/something, and conversely procfs tries to open these translators, and thus that gets interlocked

<youpi>you can probably install the static versions of the translators, to get from the kernel kdb the backtrace of these attempts

<youpi>to know where we'd have to break the loop

IRC channel logs

2023-01-24.log