IRC channel logs


back to list of logs

<luckyluke>Thanks! it's up to 0xFF0000 then... Time to sleep for me
<AlmuHS>Hi. I continues searching the origin of the lock after startup the AP processor. I'm thinking that maybe the error could be in stack reserve. What do you think?
<AlmuHS>the stack is loaded here
<luckyluke>iteration in done starting from 0 in cpus_stack_alloc() and from 1 in start_other_cpus()
<luckyluke>AlmuHS: did you check exactly where execution stops in the AP processor?
<AlmuHS>because cpus_stack_alloc() reserve stack for all cpus (including bsp)
<AlmuHS>not more inside gdt_init()
<AlmuHS>debugging is vert lazy
<luckyluke>is it necessary to allocate the stack also for the bsp? it seems this code is only run for NCPU > 1, maybe it's already allocated for bsp
<luckyluke>but I think first you should find out where execution stops on AP and see whether a fault is triggered
<luckyluke>another trick I've seen is to add the ud2 instruction here and there, and see where it stops
<AlmuHS>what is ud2?
<luckyluke>it's an invalid instruction, so it will cause an exception whenever is reached. This should enter the debugger if it's enabled
<AlmuHS>it seems stack corruption
<AlmuHS>i've changed the stack reserve to a simple kalloc(), but the problems continues
<luckyluke>it seems the output is mixed from different cpu, I think there is no mutual exclusion when printing to the console
<luckyluke>did you try to put ud2 e.g. before printing "Configuring GDT and LDT"?
<luckyluke>inline asm should work
<luckyluke>e.g. asm volatile ("ud2");
<AlmuHS>i've fixed the stack, but the problem continues