IRC channel logs


back to list of logs

<Curiosa>damo22: did you manage to boot the smp gnumach with the acpi server and rumpdisk?
<damo22>Curiosa: I havent had a chance, I'm having issues with my VPS
<Curiosa>I’m looking forward!
<Curiosa>Are you afraid all sort of race conditions are suddenly going to manifest that will need to be fixed one by one?
<damo22>im not sure if the other processors are configured to do anything yet
<Curiosa>In that case it should probably work
<damo22>the part i want to test is the interrupts on IOAPIC
<damo22>i did a bunch of work to enable that, but it hasnt been tested very much
<damo22>also the lapic timer
<damo22>basically you need to reroute the interrupts to the IOAPIC if you want SMP to work, because they are wired to interrupt the cpu(s) differently
<Curiosa>So this chip needs to be programmed?
<damo22>there are a few control registers, yes
<damo22>its mostly done, but there may be bugs
<damo22>see gnumach: ioapic.c i think
***FragByte_ is now known as FragByte
<Pellescours>youpi: for ext2fs, do we want to keep the same codebase to support ext3 and ext4 or to make ext4 in another binary as it’s done in linux?
<youpi>I guess for more filesystem support, we'd rather go the rump way
<youpi>idea being _not_ to have to maintain the code :)
<Pellescours>youpi: I suppose that to have san compilers feature, one need to brings hurd support to it
<youpi>I don't think it'd be very invasive
<Pellescours>it’s not, it’s only some fonctions to implements it should be easier than trying to port valgrind to hurd
<youpi>apprently bsd & solaris just use the asan_linux.cpp file
<youpi>that file sounds very portable across ELF platforms
<jrtc27>more portable across things that look like unix at the syscall layer
<jrtc27>relies on syscall(2) or similar existing
<youpi>jrtc27: you mean asan or valgrind?
<youpi>(I didn't see a use of syscall in asan)
<jrtc27>search for internal_syscall in
<youpi>ah, there's sanitizer_common
<youpi>actually I'm thinking it's a matter of interposing and
<youpi>that could be generated from the .defs files
<gnu_srs>Hi, any ideas: cannot start message bus /proc not mounted?
<slex>youpi: hello, do you think is better to write to the mailing list, on how to get the kernel_tak, or i just would spam the mail for a useless thing?
<youpi>slex: as I wrote, just mail the list with the mail you sent me
<youpi>it won't be spam
<youpi>it will be a question, just like we always see on gazilions of lists
<youpi>your mail seems rather precise, so that's all good
<slex>Oh, i'm really sorru, i did not know you were the same persone, realle embarassed :s
<youpi>contrary to various mails we quite often get which are really vague on what they aim to achieve
<slex>(and other typos)
<slex>youpi: yes i have in mind a little toy project, 2 server, then start and finish the smp course, experiment with it and my 2 servers, I can't do that directly on hurd, it is too big and complex, I prefer to do stuff step by step. However again sorry for the mail I was thinking that was another person. bug-hurd will be the right mailing list?
<slex>2 servers (my god i cannot type)
<youpi>it will, yes
<youpi>gnu_srs: I have no idea
<slex>ok, i will reorganize in a better way that mail, making it readable ad more concise. Tomorrow probably i don't have any rush
*** sets mode: +o ChanServ
<gnu_srs>Seems like the device file /servers/startup is corrupt. How to create a correct version?
<gnu_srs>This channel is really helpful :( Maybe help-hurd?
<mbanck>it's Sunday
<youpi>gnu_srs: /servers/startup is just a dumb empty file, and the startup translator sets itself as active translator during boot
<youpi>so there is nothing special to do about it, it's just an empty file
<gnu_srs>then something else is broken. I wonder what. building a package crashes /hurd/* dunno now. But it crashes libdde? mk debian/tmp/usr/share/libdde_linux26/build debian/hurd-dev/usr/share/libdde_linux26/ died with signal 32
<gnu_srs>Resource lost