IRC channel logs


back to list of logs

***Mete-- is now known as Mete-
<jbgg>recently, AlmuHS branch ( gives a page fault, so she asked for debuggin it
<jbgg>the page fault was: Kernel page fault at address 0xc101ccba, eip = 0xc101cc4d
<jbgg>then debuggin:
<jbgg>(gdb) l *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>possible solution is in this commit:
<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>AlmuHS: which message ?
<AlmuHS>the jbgg messages
<AlmuHS>it's related with my smp work
<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