***Mete-- is now known as Mete-
<jbgg>the page fault was: Kernel page fault at address 0xc101ccba, eip = 0xc101cc4d <jbgg>0xc101cc4d is in thread_quantum_update (../kern/priority.c:195). <jbgg>195 thread_lock(thread); <jbgg>I studied the issue with debuggin variables: <jbgg>I eventually figure out that the page fault appears when elapsed_tick variable was different between the beginning of function thread_quantum_update and the page fault source line <jbgg>so I provide a possible solution disabling sched interrupt previously inside the function thread_quantum_update <jbgg>I have test it and page fault is not trigger it <jbgg>maybe it is not the best solution, the problem should be inside of the guards NCPUS > 1 of the function thread_quantum_update <AlmuHS>youpi: could you check the latest messages? <youpi>the error message says it's thread_lock(thread) that is faulty <youpi>it'd mean that the thread poniter is bogus <youpi>that's not supposed to happen <youpi>even if the change may avoid the problem, it possibly just hides the problem without actually fixing it <youpi>there is no reason why thread would be invalid <youpi>except if curren_thread() is bogus <youpi>which would be much more worrying than the clock interrupt problem <youpi>it'd mean the active_threads[] is not properly maintained <youpi>and that's what should be fixed <jbgg>I have check the assembly source code of the function and the thread argument is store in %ebx register all time <jbgg>so the problem is not active_threads, it is the context switching, isn't? <jbgg>furthermore, I have check the %ebx register at page fault, and doesn't point to any thread address