IRC channel logs


back to list of logs

<damo22>Pellescours: ping
<damo22>youpi: should this line be PROCESSOR_IDLE ?
<damo22>like when the processor is initially set to be used, it should enter as idle right?
<damo22>otherwise it cant be dispatched to a thread because the scheduler thinks its already running?
<Pellescours>damo22: pong :D
<damo22>we're getting closer
<damo22>i wrote an IPI for synchronising the TLBs on other processors
<damo22>but it doesnt seem to be received and trigger any interrupt
<Pellescours>I ran your commit and last message was «Sending IPI(%u) to call TLB shootdown... done»
<damo22>yeah this is all about the coherency of the cache when multiple cpus are running on the same process
<Pellescours>should we configure the lapic TLV for interruptions?
<damo22>basically there is support for this in gnumach but we need to implement an interrupt vector
<damo22>so we send an IPI to a particular cpu and it runs the pmap_update_interrupt function
<Pellescours>I’m not ruse it actualy *runs* the pmap_update_interrupt, I didn’t saw log of the function running
<damo22>something is not quite right even though ive implemented the interrupt vector its not triggering the int
<damo22>yea its not running it
<damo22>need to figure out why
<damo22>i added the vector to the IDT gate
<damo22>on all cpus
<damo22>maybe its not passing the right vector?
<damo22>irq number
<damo22>since they are not 1:1 sequential
<Pellescours>but irq are identified by there number, so why would the vector being wrong?
<damo22>there are two levels of indirection, the offset in the irq table, and then the irq number
<damo22>the way it loads it is weird
<damo22>with INTERRUPT() macro
<Pellescours>I have printf of 2 cpus overwiting each other "Processmodule 0: ..."
<damo22>that is expected
<damo22>i want the bsp to run a thread before the ap
<Pellescours>I though printf was "thead-safe" with multiprocessor
<damo22>how can it be?
<Pellescours>I don’t kno
<damo22>i mean, it outputs one char at a time
<damo22>i think
<damo22>so they can interleave
<Pellescours>there is no lock between the 2 processor to have it being sequencial (I don’t know if it’s even possible)
<damo22>the printing to the console isnt so important
<damo22>its for debug
<Pellescours>I see that in all_intr it use the macro CPU_NUMBER, which always set the register to 0
<Pellescours>The INTERRUPT macro, calls the function all_intr, and in all_intr, there is a call to CPU_NUMBER (which is not really implemented)
<Pellescours>I don’t know if the cpu_number is used in the handling of an interruption but if yes, that can be a cause
<damo22>we need to implement CPU_NUMBER()
<damo22>i did implement it in cpuboot.S
<damo22>but it uses 3 registers
<damo22>cpu_number() is also already implemented
<damo22>how do you do a multiline macro that preserves newlines?
<damo22>ie, to write CPU_NUMBER(reg) i need to expand that to a number of asm commands
<Pellescours>with \ ?
<damo22>no that chops the newlines
<damo22>and puts everything on one line
<damo22>#define CPU_NUMBER(reg) \
<damo22> MACRO_BEGIN
<damo22> pushl %eax
<damo22> call EXT(cpu_number)
<damo22> movl %eax, reg
<damo22> popl %eax
<damo22> MACRO_END
<damo22>that might work
<Pellescours>need to add ;\ at the end of each line
<Pellescours>like it is done in other asm macro (sample in locore.S)
<damo22>start acpi: acpi pci rumpdisk Kernel Page fault trap, eip 0xc10321f9
<damo22>kernel: Page fault (14), code=0
<damo22>Stopped at thread_select.part.0.constprop.0+0xc9: cmpl $0x1,0x58(%eax)
<damo22>db{0}> show all tasks
<damo22> 0 f483fea0 gnumach [10]
<damo22> 1 f483fdd0 acpi [3]
<damo22> 2 f483fd00 pci-arbiter [3]
<damo22> 3 f483fc30 rumpdisk [1]
<damo22> 4 f483fb60 ext2fs [1]
<damo22> 5 f483fa90 exec [1]
<Pellescours>this is better right?
<Pellescours>in pcb.c there is a warning "SMP support missing (avoid races with io_perm_modify).", I don’t know if that’s a requirement
<damo22>cant we just update all cpu's ktss?
<damo22>detects the curr_ktss(cpu_number())
<Pellescours>just to see, I tried to boot with 3 cpu and this makes kvm crash
<damo22>i will push what ive got
<damo22>it gets to the page fault with -smp 2
<damo22>ah no the ktss needs to be updated per thread where its in the same process as the caller
<damo22>we could send IPI and make it call a function
<damo22>but i havent got that working yet
<Pellescours>Another same warning is in io_perm.c
<damo22>youpi: is it a bad idea to use init_alloc_align to allocate cpu stacks per cpu?
<damo22>ie should we just hardcode them to a region in asm?
<damo22>s/cpu stacks/interrupt stacks
<youpi>since it'll be used forever, that's not a problem to use init_alloc_align to allocate them
<youpi>there is no need to hardcode in asm
<damo22>i was just wondering because the thread stacks need to be at a higher address than the cpu/int stacks
<damo22>as there is a barrier address
<damo22>im coding them into asm
<youpi>a barrier address ?
<damo22> /*
<damo22> * Set up the barrier address. All thread stacks MUST
<damo22> * be above this address.
<damo22> */
<damo22>eg cpu_stack_high = (vm_offset_t) (_ap_cpustack + ncpus * KERNEL_STACK_SIZE);
<damo22>ok im getting a bit further
<damo22>start acpi: acpi pci rumpdisk Kernel Page fault trap, eip 0xc1032189
<damo22>kernel: Page fault (14), code=0
<damo22>Stopped at thread_select.part.0.constprop.0+0xc9: cmpl $0x1,0x58(%eax)
<damo22>>>>>> user space <<<<<
<damo22>booted with -smp 6 to the same fault
<damo22>perhaps i need to enable interrupts on the APs before they go into idle mode
<damo22>what happens with PIC interrupts? do they only interrupt the BSP?
<damo22>i havent enabled the IDT gates for pic interrupts on the APs
<damo22>could be the ktss thing
<youpi>int_stack_high doesn't seem to be used actually ?
<civodul>anyone knows of ways to get debugging output from early on that would be more convenient than ?