IRC channel logs
2025-03-19.log
back to list of logs
<mightysands>Oh cool ! janneke, I read your blogpost about getting guix/hurd working on a Thinkpad X60 ! <janneke>ACTION hasn't really looked into using audio/video/ using a guix hurd as a daily driver or desktop <janneke>there's too many things that need to be fixed addressed firest <gnu_srs1>FYI: I have patches for libdrm and mesa to build most drivers. Current problem is a bus error when running glxdemo/glxgears with llvmpipe. :( <gnu_srs1>libdrm patches will soon be submitted upstream. However, the mesa patches will not be sent upstream until the llvmpipe problem is solved. Help needed :D <youpi>note: I have updated the preinstalled hurd-amd64 image <Pellescours>I did a ps aux and I found that compared to Linux, the memory reported are quite high. Do you think it’s expected/normal? <Pellescours>everything reported in my ps have SZ field with at least 100M <Pellescours>in Linux I rarely see something reaching the megabyte <camm>youpi: Thanks! GCL Hurd is looking good. Some questions: <youpi>Pellescours: SZ is the virtual size. The default heap pre-allocation is 128M, so no wonder. Rather read RSS <camm>1) gdb hangs if the process forks a child, e.g. popen or posix_spawn <camm>2) Can hurd-amd64 access heap memory over 0x80000000? <youpi>2): I don't remember the exact figure, but the addressing space for user is very large <camm>3) Prompted by your earlier comments, I've abandoned mremap in favor of plain mmap. Apparently it can run right over the 386 heap map at 0x20000000 without unmap. Any problems here? <youpi>3): The lower 3G is fully adressable by userland <camm>I was under some impression that mmap would fail if there was already an entry in the maps table at that address. <youpi>the vm_map mach call would, yes, but mmap works around that <camm>4) My hurd-amd64 kvm cannot be upgraded, and locks up randomly, but basically shows things working (20241115). Any way to stabilize further? <youpi>that's my first message when I came back here <camm>Regarding 1), you are unaware of any existing issue where children work as expected outside of gdb, but under hang at read in open, and waitpid after posix_spawn? Seems like the children are never called. If this is unfamiliar, no worries, will just grab the latest and see what is current. <youpi>it's just not possible for people to throw issues at me and how that I would magically have ideas about them or time to work on them <youpi>sorry for being grumpy, but I've had my 10h workday, I have *not* been able to process my mail for that whole day and now I'm receiving a flurry on irc as well <camm>Of course, I am just polling you general knowledge -- no need to waste more time at this point, will retest. Thanks for the new image! <Pellescours>ok, the RSS is much more reasonable (even if higher than Linux). I see that after a fresh boot, ext2fs has RSS around 6M. But after some compilation and installation of files, I got it being 60M. I don’t know if it seems reasonable, or if it can show a memory leak <youpi>if ext2fs had memory leaks, buildds wouldn't be able to build packages for days long :) <Pellescours>youpi: does m4 build on x86_64? I try to build it but I get error ""Insufficient heuristics for detecting a stack overflow. Either define CFG_STACKVMA and HAVE_STACKVMA correctly, or define SIGSEGV_FAULT_STACKPOINTER correctly, or undefine HAVE_STACK_OVERFLOW_RECOVERY!" <azert>gnu_srs1: cool, do you keep the libdrm patches in some public repo? I’d be curious to see your approach to the ioctls <youpi>Pellescours: see the source package in unreleased which has a patch