IRC channel logs


back to list of logs

<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
<p4r4D0xum>youpi: Of course, forgive me my ignorance.
***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>Made my day.
<p4r4D0xum>Sorry for the multi line paste.
<ThinkT510>might be best using a different paste site
<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>yes it is
<youpi>we have overflown the int size
<youpi>thus breaking the support
<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/ 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
<biblio>luckyluke: ok
<luckyluke>I usually enable log cpu_reset,mmu,int on qemu monitor
<biblio>luckyluke: ok
<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>yes, one of the boot tasks
<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>ok I'll try to do the same
<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