IRC channel logs


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
<AlmuHS>i'm repeating the experiment
<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>the bt shows always the same
<AlmuHS>(gdb) bt
<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>that's expected
<youpi>they are different runqs
<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>this is interesting
<AlmuHS>$23 = (struct queue_entry *) 0xc1217a60 <default_pset>
<AlmuHS>(gdb) p processor_ptr[0]
<AlmuHS>$24 = (struct queue_entry *) 0xc121ffe0 <processor_array>
<AlmuHS>(gdb) p
<AlmuHS>$25 = (struct queue_entry *) 0xc1217a60 <default_pset>
<AlmuHS>sorry, better now
<AlmuHS>(gdb) p
<AlmuHS>$23 = (struct queue_entry *) 0xc1217a60 <default_pset>
<AlmuHS>(gdb) p processor_ptr[0]
<AlmuHS>$24 = (struct queue_entry *) 0xc121ffe0 <processor_array>
<AlmuHS>(gdb) p
<AlmuHS>$25 = (struct queue_entry *) 0xc1217a60 <default_pset>
<AlmuHS>oops, nothing. a mistake
<AlmuHS>sometimes, shows the same thread than processor_ptr[0]
<damo22>im hitting intnull(2) followed by a page fault
<damo22>is that NMI interrupt?
<AlmuHS>I think all are sleeping now :/
<damo22>not me
<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
<damo22>but only on qemu
<AlmuHS>have you test in in real PC?
<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>ioapic pin 2 is on 0x34
<AlmuHS>read docs about PCI interrupts
<AlmuHS>i can't say you anymore
<damo22>actually no
<damo22>the NMI is not even in the IDT table
<damo22>its skipped
<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>then it crashes
<damo22>0=timer, 1=keyboard spurious ACK 2= ???
<damo22>its reaching vectors 48, 49, 50
<damo22>so not the PIC
<damo22>kernel invalid opcode trap
<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