IRC channel logs

2023-03-10.log

back to list of logs

<almuhs>damo22: my Qemu VM, using 2 CPUs, freeze with gnumach --enable-ncpus=8
<almuhs> https://pasteboard.co/kOJTSW4OjxHz.png
<almuhs>even with a simple CPU
<almuhs>*single
<damo22>almuhs: are you using kvm acceleration?
<damo22>i cant imagine how slow it would be without that
<damo22>which commit are you on?
<damo22>also --disable-linux-groups
<damo22>and --enable-apic
<youpi>we should make linux-groups forcibly disabled if ncpus > 1
<almuhs>damo22: yes
<almuhs>damo22: upstream's latest
<almuhs>i'm checking configure options, because gnumach makes CPUs enumeration even with --enable-ncpus=1
<almuhs>../configure --host=i686-gnu CC='gcc -m32' LD='ld -melf_i386' --enable-apic --enable-kdb --disable-ide
<damo22>--disable-linux-groups
<almuhs>ok
<almuhs>ok, now seems boot with APIC and no SMP
<almuhs>but seems freeze after INIT
<damo22>-smp ?
<almuhs> https://pasteboard.co/PARkarW8SxQA.png
<damo22>yes i think Pellescours had problems with IDE mode
<damo22>it boots with AHCI
<almuhs>i have --disable-ide
<damo22>but you have to coerce qemu to attach a sata disk
<damo22>to the ahci controller
<almuhs>yes, i have a SATA emulation
<almuhs>this is my qemu script https://github.com/AlmuHS/gnumach_dev_scripts/blob/main/qemu-hurd.sh
<damo22>qemu-system-i386 ... -M q35,accel=kvm
<almuhs>what is q32?
<almuhs>q35?
<damo22>it is a different qemu machine
<damo22>emulates a more modern chipset
<almuhs>i will add this
<damo22>your cd drive is IDE
<almuhs>no
<damo22>yes, it is attached to IDE controller in qmeu
<almuhs>oh, then I upload an old script
<damo22>no your screenshot of qemu booting shows cd0 -> piixide
<almuhs>yes
<damo22>that is why there are lost interrupts, you cant use piixide driver for now
<almuhs>i'm checking that the SATA CD drive is in other version of the script
<almuhs>now I've just fixed it, and i go to check again
<almuhs>fixed
<almuhs>thanks damo22 to advice me
<damo22>so -smp 1 will boot, but -smp 2 will be very very slow
<almuhs>i go to recompile with --enable-cpus > 1
<damo22>that is our next job, to figure out why and fix this
<almuhs>also, i noticed that, in real hardware, system reboots after send first IPI
<damo22>lets fix qemu first
<damo22>s/qemu/gnumach booting in qemu
<almuhs>seems freeze after "startup" server
<almuhs>or so slow
<damo22>yes very slow
<almuhs>now in INIT
<damo22>how many cpus
<almuhs>2
<damo22>yes i said, 2 is unusable
<almuhs>to check the easy case
<almuhs>simple case
<almuhs>oh, a crash
<damo22>1 is okay, but anything > 1 is too slow to run
<almuhs> https://pasteboard.co/bcgio6NcFjGj.png
<damo22>i havent seen that before
<almuhs>i will try again
<almuhs>my interest is finish the boot and execute over tty some commands, to check if the APs are in use
<almuhs>but I never got tty in SMP mode
<almuhs>now seems freeze after auth
<damo22>i know, almuhs, i still havent been able to boot with smp > 1
<damo22>we need to fix it
<almuhs>yes
<almuhs>(waiting to INIT)
<almuhs> https://pasteboard.co/w6FMzg9LPXPZ.png
<almuhs>maybe there are a very bad scheduling algorithm for SMP
<almuhs>has you checked sched_init.c ?
<almuhs>boots continues in same step than the screenshot
<almuhs>after disable cd0 in /etc/fstab, now the boots are getting check harddisk
<almuhs>damo22: https://pasteboard.co/YhnUNoh2AsPS.png
<almuhs>i can disable DHCP to get a simpler boot
<almuhs>oops, now i have lost my network configuration, and the VM has not internet access
<almuhs>ok, fixed but not ping. It's a qemu problem
<almuhs>i'm reading during the boot "using makefile-style concurrent boot". is it possible to use a pure sequential boot, with a single cpu?
<damo22>youpi1: could the #warnings regarding SMP be causing slowness?
<damo22>we do need to fix those races
<DiffieHellman>Taking a certainly reliable™ guess, maybe the #warnings aren't directly causing it, but fixing them will allow the reason causing slowness issue to be fixed?
<DiffieHellman>*thing that's
<youpi1>damo22: for the iopb, no
<youpi1>io_perm_modify in stack_handoff not either
<youpi1>(and switch_context)
<damo22>youpi1: is it worth me fixing these now? your review addressed this and you said i need to make two separate cases for updating the ktss, not always updating all of them
<damo22>#warning SMP support missing (notify all CPUs running threads in that of the I/O bitmap change).
<damo22>do we need to actually send an IPI for this? or isnt the ktss addressable from any cpu?
<damo22>cant we just clear interrupts and update all of the ktss from the cpu that it is running?
<damo22>s/clear/disable
<damo22>io perm is so rarely used i dont think it needs to be optimised
<youpi1>ioperm is really not worth fixing
<youpi1>it' snot a question of optimization, but of correctness
<youpi1>whenever we change the ioperm, we *have* to change it on all threads
<damo22>what is the current state of it? is it broken?
<youpi1>for the smp case, probably
<youpi1>but again, that's not so much a problem
<youpi1>programs that abandon some ioperm are rare
<youpi1>if they exist at all
<AlmuHS>damo22: I'm remembering that youpi1 or braunr told me some years ago that the scheduler is not fully ready for SMP, and it need some fixes. Maybe this could be a reason because the boot stops just when user services have to start
<AlmuHS>maybe the scheduling produce deadlocks
<gnu_srs1>Finally got the old image, hurd-2014, last updated 2016, to today's latest packages. It took plenty of efforts to download packages from snapshot.debian.org and dpkg-deb -x, iterating, swearing, giving up, etc...