IRC channel logs


back to list of 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>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>it'd be useless otherwise
<youpi1>show registers
<youpi1> info registers
<youpi1>something like that
<youpi1>see the gnumach manuel
<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