<almuhs>are there any way to test my gnumach code without before compile It in Hurd? <almuhs>**are there any way to test my gnumach code before compile It in Hurd? ***Server sets mode: +nt
***Server sets mode: +nt
***Server sets mode: +nt
***Server sets mode: +nt
***dingenskirchen1 is now known as dingenskirchen
<AlmuHS>damo22: tonight I uploaded to my repository a new commit with a draft of ACPI APIC simplified <AlmuHS>I have not tested It in gnumach yet <AlmuHS>This code is not fully cleaned yet. I have to remove some garbage. But compiles <AlmuHS>I have to fix the naming. I don't know what can be the most appropriate <AlmuHS>this afternoon I will try to run It in gnumach <AlmuHS>youpi: the last version of Debian GNU/Hurd doesn't stop the booting if filesystem is damaged <AlmuHS>I have to reinstall my VM because my filesystem is corrupt by this reason <AlmuHS>The most comfortable way was to use the "emergency" console, which Mach usually opened when the filesystem check fails <AlmuHS>but, in the latest versions, this console has disappeared <damo22>losetup -P ~/hurd.img /dev/loop0 <damo22>then when youre finished with it, losetup -D <AlmuHS>my system doesn't find /dev/loop0 <damo22>sudo losetup -P -f --show ~/hurd.img <damo22>so then you can access /dev/loop0pX <damo22>but dont do it while hurd is powered <damo22>so you can fix the system in linux <almuhs>the device doesn't have any known partition table <almuhs>losetup: /dev/loop0: error configuring loop device: ioctl not appropiated to the device <almuhs>losetup: /dev/loop5: failed to set up loop device: Inappropriate ioctl for device <almuhs>sudo losetup -P ~/hurd_qemu/hurd.img /dev/loop5 <almuhs>losetup: /dev/loop5: failed to set up loop device: Inappropriate ioctl for device <almuhs>maybe hurd.img is not compatible. I'm not sure if is possible to access to a qcow file as this way <gnu_srs> /var/tmp/gdb-8.2.1/gdb/thread.c:266: internal-error: thread_info* add_thread_silent(ptid_t): Assertion `inf != NULL' failed. <gnu_srs>almuhs: As root /sbin/losetup -o 1048576 /dev/loop0 hurd.img; e2fsck -y /dev/loop0; losetup -d /dev/loop0 <almuhs>gnu_srs: finally, I solved the problem from qemu <gnu_srs>offset is calculated from fdisk -l ...hurd.img * 2048 62500863 ... 2048*512=1048676 <youpi>gnu_srs: that works only for raw images, almuhs has a qcow image <almuhs>I'm testing my latest smp commit. Mach hangs just after start the booting <almuhs>youpi: do you know if phystokv() macro works if It's called after paging configuration? <youpi>almuhs: it doesn't care about paging, only about segmenting <youpi>it shall *not* be called before segmentation is set up, and it *shall* be called after segmentation is set up <youpi>Mmm, though it seems c_boot_entry calls it very early <youpi>possibly it assumes that grub has set up segmentation <youpi>almuhs: print the pointers, to make sure what is happening <almuhs>I'm printing the pointers, but crash before <almuhs>I think that the phystokv() is failing, and cause a kernel panic <youpi>I don't see how it could be failing <youpi>do you really need to call acpi_setup that early? <almuhs>wait, I go to compile the default upstream gnumach <almuhs>to be sure that the problem is mine <youpi>almuhs: at worse, define ENABLE_IMMEDIATE_CONSOLE <youpi>that'll just throw the text on the vga memory <almuhs>disabling acpi_setup() call the code works. So the problem is there <youpi>really, enable the immedaite console <youpi>you'll then be able to just put printf() to know what is reached <youpi>no use trying to guess when you can just print it <youpi>if that's the only place that talks about defining it, it cannot be anywhere else <youpi>and you have the eip to know which instruction that is <almuhs>c10083a4: f3 a6 repz cmpsb %es:(%edi),%ds:(%esi) <almuhs>but I don't find who calls to this memcmp <youpi>you can put printfs to see the progress <almuhs>really, there are exactly the same registers values <almuhs>in fact, the kernel page fault is in the same rsdt address <almuhs>I suspect that rsdt address is unreachable (or simply, the virtual address is different that physical address) <almuhs>fuck... now Hurd freeze after load exec server... I thank that this problem was solved many months ago <almuhs>youpi: finally, I confirm that the kernel crash is a page fault when this try to access to rsdt <youpi>almuhs: then print the address <youpi>to make sure what is happening <youpi>possibly you got an erroneous address somehow <youpi>almuhs: to get a backtrace, pass --enable-kdb to configure <almuhs>I'm refactoring some functions yet. After this I will try again <almuhs>in my qemu script I have --enable-kdb <almuhs>ok, then I will add this option after <almuhs>fixed a couple of values, back to crash in the same place again <almuhs>yes, I confirm that the crash is in the same step than before: trying to access to rsdt address <almuhs>I suspect that the virtual address is not correct. phystokv() doesn't works after paging <almuhs>by any unknown reason, It's possible to access to RSDP with its physical address. But It's not possible do the same with RSDT ***DNS is now known as snd
<youpi>almuhs: very large addresss are indeed not supported by the gnumach segmentation <youpi>since the shift is by 0xC0000000 <youpi>so you'd need temporary maps to access that <almuhs>The code seems to find RSDP, but crash when tries to access to rsdt <youpi>like I said, you'll need temporary maps <almuhs>yes, the print shows that is away from kernel space <almuhs>what is the function for this? I don't remember <almuhs>and other question. what place do you think that is better to add the caller for this function? <almuhs>just after i386at_init(). But I'm not sure about can be better call It before 
