IRC channel logs


back to list of logs

<Pellescours>damo22: I just tested your feat-smp branch with 2 cpus, and it boots
<Pellescours>with smp 2 it makes boot really quicker than smp 1, really
<Pellescours>but htop is showing only 1 cpu, I don???t know what need to be patch to show all running cpus
<youpi> /proc information
<youpi>though glibc's sysconf(_SC_NPROCESSORS_CONF) should be working fine
<Pellescours> cat /proc/hostinfo says me only 1 cpu is running but I see a speed difference
<youpi>I hadn't realized we had a hostinfo
<youpi>so if hostinfo shows 1, sysconf will report that as well
<youpi>you can track down how that's returned by mach starting from the __host_info RPC
<Pellescours>max_cpu is set statically by NCPUS and avail_cpu is incremented by cpu_up() call
<Pellescours>this is strange that max_cpu reports 1???in my case because I configured it to 4 in my gnumach build command line
<damo22>that is strange, i never saw it completely working
<damo22>Pellescours: what configure options did you use
<youpi>Pellescours: maybe check that you actually configured smp 2 and gave 2 cpus
<Pellescours> ../configure --disable-linux-groups --enable-ncpus=4 --enable-kdb
<damo22>my rebased branch is called feat-smp-upstreaming
<Pellescours>youpi: I configured it with NCPUS=4 and gave it 4 cpus, I checked in build/config.h value is 4
<damo22>i think its broken
<Pellescours>damo22: nevermind, I was booting on the wrong kernel???
<Pellescours>I was booting on the kernel with hack to have DMA working with piixide
<damo22>yeah its tricky sometimes to make sure youre running what you just compiled
<damo22>but feat-smp is obsolete, since its been rebased and some of it upstreamed
<damo22>unless you see it works better than the new one
<Pellescours>ok so I should try feat-smp-upstreaming then
<damo22>try both, but i know the new one is broken
<Pellescours>with feat-smp, it hang after sending shootdown for AP
<damo22>yeah thats what i saw too
<damo22>i get a page fault on feat-smp-upstreaming with -smp 2
<damo22>sorry gtg to work
<Pellescours>I added a print before the slave_main and it appears, and with the print the trap seems to be located at another place. It???s happens during the memset of the pmap_zero_page. I can also see first boot logs of bootsrap modules
<Pellescours>without the added print, the panic seems to happen before, at kmem_cache_alloc during mach_device_init
<Pellescours>I think it???s a problem of concurrency, a concurent access that should be prevented with a lock and that is not
<Pellescours>Ah, trying with smp 1, make the VM hang during start of rump
<Pellescours>I enabled apic to test, and with 1 cpu it didn???t hang, I think it???s due to the removal of "Program counter 0 of 8253 to interrupt hz times per second"
<Pellescours>in 322ea6cbbb1eb2ef2eca46e1eddd6af26471c71f
<Pellescours>no that???s not that, because I don???t enable linux code
<Pellescours>If I compile your branch with NCPUS=1 it boots correctly (but an "#include <i386/gdt.h>" is missing in i386/i386at/int_init.c)
<youpi>damo22: I found a bug in the int commit
<youpi>now fixed
<m4t3>What's the progress of hardware support for the Hurd?
<Pellescours>support some ethernet cards with netdde, support sata and ide with rumpdisk