IRC channel logs

<flavioc>damo22: I have been running cross-hurd with gnumach compiled wiht -O0 (the default if you don't set CFLAGS). it does seem like that the SMP implementation is broken with -O0. my latest patch will make -O2 the default again

<flavioc>luckyluke: I have setup a daily CI job in cross-hurd to compile the whole system. it would be cool to make it run the kernel or whole system with more tests but I don't know how to run those under docker

<damo22>flavioc: yes, i dont know what is wrong yet, but it seems to work ok with -O2

<damo22>at least -smp 1 boots

<damo22>-smp 2 hangs at the point it needs a thread or something

<luckyluke>flavioc: cool! Maybe for my tests installing qemu would be enough, although maybe a bit slow without kvm

<damo22>flavioc: did you try feat-smp-develop of my repo?

<damo22>youpi1: with -smp 2 the processors are both at the same instruction in HLT state waiting for threads

<damo22>Stopped at machine_idle+0x11: leave

<damo22>machine_idle(0,1,f58fbfc8,c100bac6,c100bc25)+0x11

<damo22>idle_thread_continue(c100af10,f5904d20,0,c102f9a1,f5904690)+0x59

<damo22>thread_continue(f5904690,f5903de0,c100af10,f58fbfe4,0)+0x2e

<damo22>Thread_continue()

<damo22>with interrupts enabled

<damo22>c1027e80 <machine_idle>:

<damo22>c1027e80: 55 push %ebp

<damo22>c1027e81: 89 e5 mov %esp,%ebp

<damo22>c1027e83: 83 ec 08 sub $0x8,%esp

<damo22>c1027e8b: 3b 45 08 cmp 0x8(%ebp),%eax

<damo22>c1027e90: f4 hlt

<damo22>c1027e91: c9 leave <----- sitting here

<damo22>cpu_up() seems to set a processor state to PROCESSOR_RUNNING but it should be PROCESSOR_IDLE, and then picked to run a thread... but the code makes an assumption that one of the cpus is already running

<damo22>s/one of the/the

<damo22>-smp 2 INIT: version 3.04 booting

<damo22>!!!!

<damo22>youpi1: i have a slow-booting -smp 2 working with two processors, top only shows cpu0 though

<damo22>with APIC

<damo22>and LAPIC timer

<youpi1>flavioc: the normal process for gcc patches is to just ping :/

<youpi1>damo22, flavioc: it's odd that we need -O2 for damo22's case to work

<youpi1>damo22: I don't think they need separate kernel_pmap for now. Possibly if we want per-cpu data later (and still, we could use e.g. fs/gs for that)

<damo22>yes it only works with one AP because i didnt know how to serialise the accesses to the pmap per cpu

<youpi1>damo22: booting additional cpus sequentially doesn't seem too bad to me

<youpi1>damo22: we need APs to be interrupted periodically, otherwise userland could hang a CPU by just running while(1){}

<damo22>maybe that is what is currently happening because the cpu load is 100%

<damo22>with -smp 2

<youpi1>gnu_srs: yes, restarted them this morning

<youpi1>top most probably provides bogus data, until we get to check what show up in /proc for top to grok

<damo22>i have 5 more commits that make smp2 work, on top of what i have sent to mailing list

<damo22>"feat-smp2-works"

<damo22>something is strange with the lapic timer calibration, i had to fudge it with a factor of 10 to make the timer interrupts less frequent, otherwise i get a strange failure trying to boot proc from startup

<damo22>i think it boots too quick otherwise

<damo22>youpi1: which interrupt should be triggering on the APs? the timer is isolated to cpu0's lapic

<damo22>therefore cpu0 is the only one that receives timer interrupts

<damo22>do i need to implement all lapic timers?

<youpi1>it doesn't matter which interrupt exactly, it just needs to be an interrupt

<youpi1>so userland gets to get interrupted from times to times for the scheduler to preempt it

<damo22>ok

<damo22>i will take a look at doing this tomorrow

IRC channel logs

2023-01-23.log