IRC channel logs

<damo22>Pellescours: ping

<damo22>youpi: should this line be PROCESSOR_IDLE ? http://git.zammit.org/gnumach-sv.git/commit/?h=feat-smp&id=0e81b9d09e42371c86d8945ae28b2443392e436c

<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

<Pellescours>ok

<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>yes

<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

<damo22>??

<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)

<damo22>ok

<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>ahh

<damo22>thx

<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>...

<damo22>db{0}> show all tasks

<damo22> ID TASK NAME [THREADS]

<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?

<damo22>yeah

<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>update_ktss_iopb()

<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

<Pellescours>yup

<damo22>done

<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>(non-overlapping)

<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>thread_select.part.0.constprop.0(0,0,7,0,0)+0xc9

<damo22>thread_block(c1061a50,f484c000,f4845ee0,c1061641)+0x4f

<damo22>ipc_mqueue_receive(f52fff10,0,2000,0,0)+0x186

<damo22>mach_msg_receive(bfffdd50,802,2000,14,0,0,d,f4845fb4)+0x159

<damo22>mach_msg_trap(bfffdd50,802,0,2000,14)+0x385

<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

<damo22>#warning

<youpi>int_stack_high doesn't seem to be used actually ?

<civodul>hey!

<civodul>anyone knows of ways to get debugging output from ld.so early on that would be more convenient than https://lists.gnu.org/archive/html/bug-hurd/2011-11/msg00038.html ?

IRC channel logs

2022-10-08.log