IRC channel logs


back to list of 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>/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>>>>>> user space <<<<<
<damo22>db{0}> show all tasks
<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>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 (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
<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>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