IRC channel logs
2019-11-04.log
back to list of logs
<youpi>AlmuHS: but then it's odd that none of them appear in the runq <youpi>one can be actually running, but the other one has to be somehwere <youpi>backtrace on cpu1 shows the idle stack, doesn'tit? <youpi>you could check the pset queue <youpi>print not only the pset q or only the processor queue, we need to see both at the same time, to be sure to be looking at a coherent state <AlmuHS>there are a loop around thread_block function <AlmuHS>cpu 0 always return to this, and It seems never out of this <AlmuHS>after this line, the kernel don't return to debugger <AlmuHS>893 while (!thread_invoke(thread, continuation, new_thread)); <AlmuHS>#0 0xc102f7ba in thread_invoke (new_thread=<optimized out>, continuation=<optimized out>, old_thread=<optimized out>) at ../kern/sched_prim.c:668 <AlmuHS>#1 thread_invoke (old_thread=0xf5e1aa88, continuation=0xc1007120 <thread_exception_return>, new_thread=0xf5c00000) at ../kern/sched_prim.c:627 <AlmuHS>#2 0xc103003c in thread_block (continuation=0xc1007120 <thread_exception_return>) at ../kern/sched_prim.c:893 <AlmuHS>#3 0xc1023e81 in ast_taken () at ../kern/ast.c:111 <AlmuHS>#4 0xc1009553 in i386_astintr () at ../i386/i386/trap.c:582 <AlmuHS>#5 0xc10070c5 in _return_from_trap () at ../i386/i386/locore.S:513 ***Server sets mode: +nt
<AlmuHS>default_pset and processor_ptr[0] shows diferents values in their runq <youpi>default_pset is for all processors <youpi>processor_ptr[0] is for cpu0 only <youpi>settingbound_processor made gnumach use processor_ptr[0].runq instead of default_pset.runq, precisely <AlmuHS>$23 = (struct queue_entry *) 0xc1217a60 <default_pset> <AlmuHS>(gdb) p processor_ptr[0].runq.runq.next <AlmuHS>$24 = (struct queue_entry *) 0xc121ffe0 <processor_array> <AlmuHS>(gdb) p default_pset.runq.runq.next <AlmuHS>$25 = (struct queue_entry *) 0xc1217a60 <default_pset> <AlmuHS>(gdb) p default_pset.runq.runq.next.next <AlmuHS>$23 = (struct queue_entry *) 0xc1217a60 <default_pset> <AlmuHS>(gdb) p processor_ptr[0].runq.runq.next <AlmuHS>$24 = (struct queue_entry *) 0xc121ffe0 <processor_array> <AlmuHS>(gdb) p default_pset.runq.runq.next <AlmuHS>$25 = (struct queue_entry *) 0xc1217a60 <default_pset> <AlmuHS>sometimes, default_pset.runq.runq.next.next shows the same thread than processor_ptr[0].runq.runq.next <damo22>im hitting intnull(2) followed by a page fault <AlmuHS>most devs are in european timezone, I think <damo22>i configured the ioapic and then i get an interrupt on pin 2 then it page faults <AlmuHS>but qemu ussually are more permisive than the real pC <damo22>im confused because the intnull says 2 so that means it got to the ioapic pin 2 <damo22>but the nmi interrupt is on vector 2 <damo22>the NMI is not even in the IDT table <AlmuHS>NMI is not maskable, maybe It's related <AlmuHS>I need to go sleep. You can ask here in a few hours, after rest of devs wake up <damo22>my ioapic code works, i checked with qemu info <damo22>but something is causing a page fault at boot <damo22>i set up the lapic timer correctly and calibrated it with PIT <damo22>there are 3 interrupts on the ioapic pending, 0, 1, 2 <damo22>0=timer, 1=keyboard spurious ACK 2= ??? <damo22>the interrupt code is a tangled spaghetti <damo22>i cant figure out where i went wrong <damo22>ive pushed my latest code, it looks correct but hangs on real hw and faults on qemu