IRC channel logs

2026-10-03.log

back to list of logs

<damo22>youpi: ive tested full smp again vs slave pset smp. full smp is slow and hangs during boot. how do we debug this?
<damo22>slave pset smp compiles gnumach successfully with -j 7 on a -smp 8 system
<damo22>using a /sbin/smp /bin/bash shell
<damo22>sorry i meant i used a -smp 6 system
<damo22>it seems like the full smp system lags for some reason, im guessing some locks are contended
<damo22>sigttou: this branch has most of the changes required for xen + smp https://code.zammit.org/damo22/gnumach-sv/src/branch/ci-xen-smp
<damo22>but i cant test it easily
<GNU_Hurd_Rocks>damo22: last time I tried smp it wouldn't want to boot on hardware so I might take a look at it again soon :3
<damo22>im testing in qemu
<GNU_Hurd_Rocks>can verify that works though, within limits
<sigttou>damo22: thanks, noted! I need to pick things up on that topic again, currently still working on some SMP locking issues.
<damo22>sigttou: thats interesting did you find anything there?
<sigttou>damo22: yes! I am currently writing some reproducers which help me to pin the issue down.
<damo22>nice
<damo22>maybe you can add a unit test to gnumach
<sigttou>Good Idea. - Last one I found was this: https://lists.gnu.org/archive/html/bug-hurd/2026-09/msg00122.html It's a bit of a hazzle to debug/trace locking issues, but that's the fun of it :)
<damo22>although the test suite runs gnumach entirely and then runs a userspace test
<damo22>if you can reproduce a problem in userspace, you can write a test
<damo22>sigttou: one thing you can do is compile with MACH_LOCK_MON lock monitoring and then db> show all slocks
<damo22>i added timing info to that i think
<damo22>git show 5e25bd3c
<sigttou>that's helpful, thanks! currently not on the dev box, so I sadly can't try it out now, but will check on Monday.
<damo22>sigttou: https://cgit.git.savannah.gnu.org/cgit/hurd/gnumach.git/commit/?id=5e25bd3cbd2be0e510d53e2b35ddb2c54a8e0ac5
<damo22>it needs work to populate the function names instead of the function pointer addresses
<damo22>db_printsym(...) {
<damo22> db_task_printsym(off, strategy, TASK_NULL);
<damo22>youpi: should that really be TASK_NULL or kernel_task?
<youpi>I don't know about that code
<damo22>i tried kernel_task but it still prints hex offsets instead of elf symbols
<damo22>map_for_val = (task == TASK_NULL)? VM_MAP_NULL: task->map;
<damo22>it seems to need a valid task
<damo22>ah no, it detects the current task if its missing