IRC channel logs


back to list of 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>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>c1027e86: e8 f5 79 00 00 call c102f880 <cpu_number>
<damo22>c1027e8b: 3b 45 08 cmp 0x8(%ebp),%eax
<damo22>c1027e8e: 75 08 jne c1027e98 <machine_idle+0x18>
<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>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>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>i will take a look at doing this tomorrow