<biblio>luckyluke: glad to know. I just got update from your git branch. <luckyluke>biblio: yeah now I have another issue, it seems the modules are started and I see the code executed in user-space, but after a bit there is another triple fault and a reboot <luckyluke>it should be reproducible with the test I added <slex>youpi: hello, if i set a bootstrap port to the kernel_task, then i can ask it to the kernel_task to query the nameserver? In an environment where i just have the kernel and the name server, so not the hurd <p4r4D0xum>Hello, couple years ago I've installed GNU/Hurd on a very old laptop. <p4r4D0xum>Recently I tried to upgrade the system and I wasn't be able to do it due some *new* check sum <p4r4D0xum>any idea how by pass this issue so I can upgrade the hurd? <youpi>p4r4D0xum: pasting the exact error would help a lot in understanding what you are referring to ***Forza_ is now known as Forza
<p4r4D0xum>Pastebin’s SMART filters have detected potentially offensive or questionable content in your paste. <p4r4D0xum>The content you are trying to publish has been deemed potentially offensive or questionable by our filters, because of this you’re receiving this warning. <p4r4D0xum>This paste can only be published with the visibility set to "Private". <p4r4D0xum>My apt-get term log is potentially offensive. :D <p4r4D0xum>ThinkT510: Already shortened the log. Hope it's enough. <Pellescours>youpi: in hurd, in utils/w.c:95, there is a flag defined as (PSTAT_USER_BASE << 3) but PSTAT_USER_BASE = 0x20000000 gcc says that there is an overflow with int in 32 bits, is it a real warning ? <youpi>we have overflown the int size <biblio>luckyluke: I will try to reproduce with the test. <biblio>luckyluke: did you mean - $ make check // after building gnumach ? <biblio>luckyluke: I am getting total 1 skip 1, if I run $ make check <biblio>luckyluke: I found tests/Makefrag.am but could not build it yet. <biblio>luckyluke: $ make debugiso // worked <luckyluke>biblio: yes, sorry, I added the debugiso target to simplify testing <luckyluke>it will wait for gdb to attach, then you can set a breakpoint in the user space addresses if you want (at 0x804901d for example) and from the qemu monitor you can enable more logs <biblio>luckyluke: yes sure. Just trying to test with gdb now. <biblio>luckyluke: $gdb ./gnumach then from inside (gdb) target remote :1234 . is it correct ? <luckyluke>yes, then you can set a breakpoint and continue <luckyluke>I usually enable log cpu_reset,mmu,int on qemu monitor <luckyluke>it seems at some point there is a page fault in the user task accessing a variable on the stack, but I don't understand how this becomes a triple fault <luckyluke>I mean, why the page fault happens in the first place, and why this is not handled better by the kernel <biblio>luckyluke: ok i will try to check. <Pellescours>are you able to determine which task is generating the page fault? <luckyluke>I'm trying with a very simple executable that should just loop and call mach_print <luckyluke>I suspect this might have something to do with the task switching, maybe the exception handler is not correctly set up <luckyluke>youpi: how did you test syscalls on xen/54 bit? <youpi>IIRC I just ran ext2fs.static <youpi>and looked how far it sailed <luckyluke>I still have a triple fault, looks similar to my simpler test program <luckyluke>I should maybe try on xen and see how it works there, and see what is different