<biblio>luckyluke: could you share example how can I enable log cpu_reset,mmu,int in qemu monitor. <biblio>luckyluke: this is output from $ make debugiso after i connect from gdb ***janneke_ is now known as janneke
<luckyluke>biblio: that's strange. do you have grub-mkrescue installed? <luckyluke>to enable more qemu logs, you can enter the qemu monitor (ctrl-a c) then use the log command <biblio>luckyluke: yes, I have grub-mkrescue installed. I also added /usr/sbin:/sbin in my PATH <biblio>luckyluke: I was able to copy gnumach.gz and boot existing hurd img until it gets restated after booting for a while. <biblio>luckyluke: I am using Debian 11.2 <luckyluke>I'm also on debian... do you get the same if you directly start qemu, e.g. qemu-system-x86_64 -m 512 -cdrom test.iso <biblio>luckyluke: yes. CDROM error code 0009. <biblio>luckyluke: "On a system that uses EFI to boot, you may see an error like this" just found in a forum <biblio>luckyluke: I will try find a solution or use old laptop without EFI for testing. <luckyluke>it seems that if you install grub-pc-bin then grub-mkrescue will generate a bootable iso also without EFI <biblio>luckyluke: it worked. :) I install grub-pc-bin from the forum but I need to remove test.iso manually to force regeneration <biblio>luckyluke: thanks. I will continue debugging. <luckyluke>biblio: I found an issue with ktss, it needs to be changed for 64 bit <Pellescours>luckyluke: I don’t know if this can help but I have a pagefault when I build gnumach locally and run it in i386 <luckyluke>Pellescours: it seems one of the issues I had was because the TSS structure needed to be fixed for 64 bit operations, and this caused a triple fault because then the exception stack was not valid. I think what you see is another issue <Pellescours>my page fault appear just after the RTC time message during boot (before the kernel boot another process) <youpi>just to make sure: does the RTC time make sense? <youpi>(possibly it reads bogus data and pokes bogusly, thus creating mayhem) <Pellescours>I don’t know how to attach a gdb to a kernel running in qemu <youpi>it's a bit tricky, iirc I had put some notes on the wiki <youpi>microkernel/mach/gnumach/debugging <luckyluke>Pellescours: you can enable the gdbserver from the qemu monitor (ctrl-a c if you started it from shell), then you can start gdb and attach it with "target remote :1234" <luckyluke>I can add some info to the wiki maybe, I'm using it quite extensively recently :) <luckyluke>do I have to send a patch against the hurd web repository? <slex>how can i get the kernel task to set a bootstrap port? <slex>passing as argument --kernel-task='${kernel-task}' is not working. The result of setting that option depends by the position of the option in the argument list <slex>so if it is the second argument it gives 2, if it is the third it gives 3. I just tried :( <Pellescours>#0 0xc1007a4c in delay (n=1000000) at ../i386/i386/loose_ends.c:46 <Pellescours>#1 0xc1014195 in Panic (file=0xc10557bc "../i386/i386/trap.c", line=346, fun=0xc1052c30 <__FUNCTION__.1> "kernel_trap", s=0xc1055808 "trap") at ../kern/debug.c:178 <Pellescours>It seems that it’s the delay function that make the page_fault <Pellescours>actually no, at this step the page fault already appened <biblio>luckyluke: i think minor change is missing in i386asm.sym (last git push) <slex>hey guys someone knows how to get the kernel_task? it is a port, i need it to set the bootstrap port of my nameserver to the kernel <slex>not usinh the hurd, with hurd specific calls are present <luckyluke>biblio: thanks, I missed that. I'm not sure it's really used though, even the esp0 and ss0 definitions. <biblio>biblio: I got compilation error. for esp0 and ss0 while compiling <luckyluke>ah, so maybe they're used when compiling for i386, or in some other place where rsp0 sohuld be used <biblio>luckyluke: do you have any suggestion what should I look for now ? I am just reading wiki for tss <luckyluke>there might be some change needed to have the arguments retrieved correctly in the kernel <luckyluke>with my simple testloops.c, I see that after the first syscall the task is terminated <luckyluke>I'm not really sure testloops.c is really correct, but if use the startup files of libc then it uses mach_msg which I don't expect to work yet <biblio>luckyluke: yes this I understand. <luckyluke>maybe instead of mach_print it could be useful to try with mach_task_self() or similar, which don't take arguments <slex>are these thests fot high mem kernel? <luckyluke>slex: what do you mean? using a lot of physical memory? <slex>putting the kernl in high mem addresses <luckyluke>it's linked in the upper 1G on i386, starting from 0xc0000000 <luckyluke>on 64 bit it seems there are some issues going over the 4G limit, so far I couldn't even compile it because of linker issues <slex>ok ty, it seems i will be not able to get the kernel_task port for tonight, better to go to sleep <biblio>luckyluke: done i guess "adding 64bit boot support from grub" <slex>because i need to set the bootstrap port of my nameserver to the kernel, but without using the hurd and some of its calls from glibc. think at my environment in this way. I just have the kernel and the nameserver that starts, then i need to ake the nameserver reacheble <luckyluke>biblio: well, I have something that seems to work at least for the boot part, but still needs a cleanup and review :) <biblio>luckyluke: indeed :) . I mean, is syscall argument issue might be related to pending 2nd task ? <luckyluke>I don't know, could be, although it seemed more related to mig and the data types used in rpc <luckyluke>slex: as far as I understand, if your server is started at boot, it won't have a bootstrap port, but it will have to work without it <slex>luckyluke: it is a bit unclear here to me too, but looking at the huts at somepoint a bootstrap port is registered to the kernel task for the proc server <slex>i also don't know fi allocating a new port and then using task_set_bootstrap_port on that port for mach_self(), makes really sense <luckyluke>other tasks could probably get the bootstrap port, if they know the task <luckyluke>and you can probably exchange the task port in the boot script <luckyluke>in the same way ext2fs and exec currently do <slex>luckyluke: yes indeed, knowing the task is all what i need.