IRC channel logs

<damo22>youpi1: the kernel_pmap thing where it temporarily creates a mapping so paging can be enabled is difficult to get working with multiple processors because each processor needs to set up paging individually so i think there should be N temporary pmaps otherwise the accesses need to be serialised?

<damo22>i dont know which approach i should take

<damo22>i think i need to share the kernel_pmap and serialise the paging setup

<damo22>hmm RTC time is 2023-01-22 03:54:04

<damo22>SIGQUIT

<damo22>/hurd/startup: : No such file or directory

<damo22>File name for server /hurd/proc (or nothing to reboot): Stopped at machine_idle+0x11: leave

<damo22>machine_idle(0,1,f58fafdc,c100bac6,f5904d20)+0x11

<damo22>idle_thread_continue(f5903de0,c100af10,f58fafe4,0,f59047e0)+0x59

<damo22>>>>>> user space <<<<<

<damo22>db{0}> show all tasks

<damo22> ID TASK NAME [THREADS]

<damo22> 0 f5906ea0 gnumach [9]

<damo22> 1 f5906dd0 acpi [3]

<damo22> 2 f5906d00 pci-arbiter [3]

<damo22> 3 f5906c30 rumpdisk [2]

<damo22> 4 f5906b60 ext2fs [24]

<damo22> 5 f59069c0 /hurd/startup [1]

<damo22> 6 f5906a90 (/hurd/startup) [0]

<damo22>-smp 2 almost booted

<damo22>:D

<damo22>it got to /hurd/startup but could not load proc

<damo22>see feat-smp-develop

<damo22>Pellescours: youpi1: flavioc: luckyluke: ^

<damo22>interestingly, -smp 1 has the same issue

<damo22>File name for server /hurd/proc (or nothing to reboot):

<damo22>seems the timer was calibrated too fast, now it boots on -smp 1 but gets stuck on -smp 2 with more tasks but no threads

<damo22>does anyone know if i need to have an lapic timer set on all processors, or can i drive the timer from one processor's lapic timer only?

<damo22>previously there was only one processor being interrupted by the PIC timer

<damo22>but with APIC, there is a timer present on each processor

<damo22>does it matter if the APs are not being interrupted periodically?

<luckyluke>damo22: nice work! if you want to run some simpler tests to stress smp, you can have a look at https://gitlab.com/luckyd/gnumach/-/tree/prepare64_wip/tests (I'm not sure they should be part of gnumach source, as they only run on Linux currently)

<luckyluke>afaik, the system timer (driving round-robin, timers etc) could be running on one cpu, I don't think APs need to be interrupted periodically

<luckyluke>btw, zour work on APIC will probably be very useful to enable user-space drivers on the 64 bit kernel :)

<luckyluke>(sorry I sometimes mix "y" and "z", wrong keyboard layout...)

<damo22>of course, thats one reason i am doing this

<damo22>ive got it to a point where it kind of works, but i dont know what is missing

<luckyluke>about /hurd/startup, IIRC it's the first task to run loading shared libraries, I'm not sure it's relevant...

<damo22>should i try your unit tests?

<luckyluke>you can give it a try, I wrote them mainly to pinpoint some issues for rpc compatibility on 64-bit and for regression testing, there's not much about concurrency or the processor rpcs currently

<luckyluke>btw, you need to add MIGUSER to ./configure currenlty

<damo22>how do i run the tests? i have a smp i386 kernel i want to test

<luckyluke>make check will run all the basic tests

<damo22>do i need qemu installed in hurd?

<damo22>i usually develop inside hurd

<luckyluke>ah, no, they only run on Linux

<luckyluke>unless qemu can run with full emulaiton on hurd? I don't know honestly, I've never tried

<damo22>how do i compile hurd kernel in linux?

<luckyluke>$ [...]/configure --host=i686-gnu CC='gcc -m32' LD='ld -melf_i386' (see README)

<damo22>i see

<luckyluke>btw, did I understand correctly that -O0 breaks gnumach currently?

<damo22>how do i compile mig on linux? the readme guide doesnt seem to work

<damo22>im not sure i havent tried -O0

<damo22>do i need the gnumach headers somewhere?

<luckyluke>yes, you need mig somewhere, and compile it with your gnumach's headers. I use this to test a clean build https://paste.debian.net/1268095/

<luckyluke>I think these tests would be useful to keep somewhere other than my personal repo, but I'm not yet fully sure if it's better to create a test-specific repo, since I also have some boot scenarios with hurd (ramdisk, rump disk driver, etc)...

<luckyluke>also, it would be useful to integrate it with cross-hurd somehow, but then a full test will take a lot of time...

<damo22>i dont know if it worked, it failed 2 tests but didnt seem to use the QEMU_OPTS i set

<damo22>luckyluke: do your tests build gnumach with -O2 ?

<damo22>ahh its still broken in master

<luckyluke>I don't set cflags, so probably no

<luckyluke>You can run the single test also, e.g. make run-hello

<damo22>test suite needs to check error code

<damo22>its currently looking for "error"

<luckyluke>damo22: if one of the failing tests is vm_wire_all() I have a possible fix, but I'm not sure I'm testing it in the correct way, so maybe you can ignore that

<damo22>but that outputs somewhere in my log

<luckyluke>yes that's very simple... it could print main() return code

<damo22>-smp 1 -M q35,accel=kvm seems to pass

<damo22>with my branch

<damo22>but -smp 2 does not

<luckyluke>ah, which tests are failing?

<damo22>all

<damo22>it hangs somewhere

<luckyluke>you can also attach with gdb, if you make debug-hello

<damo22>its stuck waiting for APs to come up

<damo22>but that doesnt usually happen

<gnu_srs>youpi1: Hi, seems like the buildds are stuck: rdkit (2d 7h 5m, ironforge), dovecot (2d 21m, mahler)

<gnu_srs>Needs-Build: 133

IRC channel logs

2023-01-22.log