IRC channel logs

<gnu_srs1>which program hands control over to sbin/init?

<damo22>startup?

<gnucode>damo22: that sounds right.

<gnucode> https://darnassus.sceen.net/~hurd-web/hurd/bootstrap/ I wish that page wasn't so outdated.

<youpi>that's the aeternal problem: people never remember to update documentation

<gnucode>That's why you all have me. :)

<gnu_srs1>Still no solution. dpkg-deb -x is limited :( Any ideas?

<gnucode>gnu_srs1: have you tried pouring water on your machine?

<gnu_srs1>Not yet :)

<gnucode>gnu_srs1: hahaha!

<gnu_srs1>Just a thought: It would be nice to have access to releases of GNU/Hurd too as for Debian. Especially interesting is before/after daedalus/excalibur or bookworm/trixie.

<Pellescours>is the 64 bit stable to try for a long run pr are there still important missing pieces ?

<Pellescours>s/pr/or

<youpi>depends what you call "a long run"

<youpi>there are still issues with data page-out

<youpi>so if you have a lot of memory you're fine, but otherwise you'll get hangs

<youpi>the buildds are fine with 10G

<youpi>but for building rustc for instance, I had to use a box with 16G

<Pellescours>this issue il also here for 32 bits machine no ?

<damo22>thats interesting, i use non-PAE 32 bit and i still see hangs occasionally with heavy use

<ZhaoM>hi what's the latest update about pfinet?

<youpi>it might be similar

<youpi>but it's surprising that it's so much more often on 64b

<ZhaoM> https://darnassus.sceen.net/~hurd-web/hurd/translator/pfinet/ says lwip can repace pfinet

<youpi>see the contributing page

<youpi>we need to check that lwip doesn't bring regressions

<ZhaoM>ah I see it

<Pellescours>lwip dynamic routes are not implemented (while damo22 implemented them for pfinet some years ago)

<damo22>im happy with pfinet for now, but we need to fix rumpnet for driver

<damo22>we should replace netdde with rumpnet

<gnucode>I honestly want to swap my pfinet for lwip, just to see if it works. And report if and when it breaks.

<Pellescours>yup, your problem is sending packet right ?

<Pellescours>gnucode: you can do it easily

<damo22>my problem is rumpdev_bpf is not installed in the debian package

<damo22>i need to fix that and then try to finish the driver

<Pellescours>(you can copy it to your /usr/lib temporarly i think)

<damo22>yeah

<damo22>i have a lot of stuff in progress, but im keen to fix smp

<Pellescours>+1

<Pellescours>smp asm pieces are here for a 64 bit gnumach ?

<damo22>Pellescours: if you have some time, it would be good to identify any global variables used in cpu_setup()

<damo22>so we can move them to percpu

<damo22>then my fix-smp-amd branch might just wotk

<damo22>work*

<Pellescours>yes

<damo22>i think x86_64/x86_64/ is a symlink to ../../i386/i386

<damo22>so it should work

<Pellescours>ok I thought it neede to be changed to switch ap to 64 bit mode

<youpi>it most probably needs something there yes

<damo22>youpi: kernel_page_dir[] what do we do with this for parallel smp init? its a global array?

<damo22>can we set the temporary mapping once for all cpus?

<damo22>and then set the page dir per cpu

<damo22>and only remove it once all cpus have used it

<damo22>then do a IPI to flush tlb on all cpus

<damo22>-smp 4 always seems to work with my branch but any other number fails

<damo22>ah got it to crash KVM: injection failed, MSI lost (Operation not permitted)

<slex>Hi guys, just for learning i'm usiing MIG, so i generated some userspace server and an in kernel little service. Now the client must communicate with the kernel service so i have to register for it a new port and then i can use the demuxer generated by mig for the inkernel service.I have to write the code for calling the demuxer, can i use mach_msg_server for the inkernel service (i think no), so if NO what is the best approach

<slex>?

<azert>slex: are in-kernel servers still supported by gnumach?

<azert>anyway, why?

<youpi>damo22: we can probably do that, yes

<slex>a

<damo22>youpi: should i pick off some patches from my parallel smp init work that can be merged before making it parallel?

<damo22>its still not working

<youpi>you can, yes

<youpi>all patches that make sense and don't break the existing support are worth commmitting

<damo22>ok

<damo22>it seems by doing that, it reduces the code to be changed from a working state

<youpi>yes

<damo22>EIP=00083ca6

<damo22>on cpu4 and everything is stuck on parallel smp

<damo22>maybe bspdone cannot be accessed by AP ?

<damo22>the eip is getting corrupted

<damo22>EIP=3ebbf127

<gnu_srs1>Is it possible to debug the client in qemu in some way?

<damo22>i do

<damo22>i think the best thing i can do is strip down my changes into chunks that i can verify dont break anything and keep doing it until i find what breaks

<damo22>and all the good ones, merge in first

<Pellescours>youpi: is there a possibikity of deadlock here https://github.com/flavioc/hurd/blob/master/libpager/lock-object.c#L77 ? it does a pthread_cond_wait with p->interlock being locked but the pthread_cond_broadcast is done here https://github.com/flavioc/hurd/blob/master/libpager/lock-completed.c#L55 with p->interlock being also locked

<Pellescours>i mean that for the brodcast to be able to happen it must take the lock which is hold by the waiter thread

<Pellescours>(unless I don't understand all pieces here)

<Pellescours>ah nevermind, pthread_cond_wait release the lock before blocking, so it's fine

<youpi>damo22: yes

<Pellescours>should'nt a pthread_rwlock_wrlock being called here instead of a rdlock https://github.com/flavioc/hurd/blob/master/rumpdisk/block-rump.c#L343 ?

<youpi>Pellescours: "rw" is not about data on disk

<youpi>it's about data structures, bd notably

<Pellescours>ah ok yeah, it's to ensure we won't release the disk wile doing an operation on it. I see

<Pellescours>i'm trying to find the issue with rumpdisk in case of resource shortage or memory contention. can a fallback allocation (not contiguous) help in case of memory contention ?

<AlmuHS>Pellescours: have you tried to update rumpdisk sources to netbsd current?

<Pellescours>not recently, the problem is the patch updating, I don't sucess to use debian tools to update them

<gnu_srs1>quilt?

<AlmuHS>then we need it to solve the rumpdisk updating to be able of run it in real hardware

<gnu_srs1>How important are the /etc/alternatives symbolic links for the boot process?

<youpi>the runsystem symbolic link is essential

<gnu_srs1>ok, what about random/urandom?

<youpi>is that still an alternative? iirc it got hardwired

<youpi>with a recent-enough glibc it becomes essential, yes

<gnu_srs1>I'm installing some older hurd/glibc/etc packages as an intermediate solution.

<youpi>how old is the box?

<youpi>using dpkg -x is essentially bypassing all the migration tweaks that can be essential

<gnu_srs1>libc0.3_2.38-11.

<youpi>so after debian 2023 ?

<gnu_srs1>I tried to upgrade the box 2023-12-24, but the upgrade filed

<gnu_srs1>failed**

<youpi>what do you mean by "2023-12-24", is that the time it was installed ?

<gnu_srs1>I tried to upgrade then and it failed. I'm now dpkg-deb -x upgrading to libc0.3_2.38-11, hurd_0.9.git20231217-1+b2, and depending packages.

<gnu_srs1>It boots :) I corrected the links of random-hurd.sh and urandom-hurd.sh

<Pellescours>gnu_srs1: yes quilt

IRC channel logs

2024-12-09.log