<damo22>youpi: the acpi translator does not get enough time to start up before the rpc is called i think. afaik there is already a race condition in pci-arbiter that we dodged <damo22>rumpdisk: acpi_get_pci_irq: Success <damo22>ok its definitely a race condition, i ran it slow and it worked <damo22>how do i make an RPC block until some part of main.c has completed executing? <damo22>and what happens if an RPC is called before the demuxer is running? <damo22>HAHA i had two AHCI controllers connected to qemu and it detected irq1 ***silver.libera.chat sets mode: +o ChanServ
***silver.libera.chat sets mode: +o ChanServ
***valerius_ is now known as valerius
***valerius is now known as 073AAK6Z9
<damo22>youpi: i looked into the bug with "sd1: QEMU DVD-ROM, ATAPI unsupported CDROM drive" it appears the gnumach ahci driver does not support ATAPI, but the ide driver does is that correct? <luckyluke>biblio: the initial gdt in boothdr.S is used only to enable long mode, iirc it is reconfigured later <biblio>luckyluke: I am still debugging. it failed to start first thread after booting. <biblio>luckyluke: "boot_entry64: movq $(_intstack+INTSTACK_SIZE),%rax and andq $(~15),%rax" <biblio>luckyluke: i did not get the logic ~15 here. Also, "movq $_intstack+INTSTACK_SIZE" shouldn't we add the stack size with the address of _intstack instead ? <luckyluke>biblio: how are you booting? If you're using rump, it won't work yet as the device_intr() RPC are not yet implemented for 64 bit <luckyluke>Although on my system, trying to boot with rump just hangs at the irq... <luckyluke>For the intstack, it probably has some alignment requirements. I think I took that part from the xen boothdr <biblio>luckyluke: yes I got it now. I was going to ask damo22 about it. <biblio>luckyluke: i will test run-ramhurd. <biblio>luckyluke: let me know if you want me to check any particular part while debugging. <biblio>luckyluke: previously, I followed the doc. copy gnumach.gz after building to a running hurd and reboot <biblio>luckyluke: i think some of the scripts are using hardcoded path. I will adjust manually and test again. <luckyluke>biblio: yes for mig-user-not-found you need to have a 32-bit mig for userspace <luckyluke>There are many hardcoded paths, for the tests booting hurd... The should probably be in a different repo <luckyluke>It would be also great to package a cross-compiler, like the one built by cross-hurd <biblio>luckyluke: i build mig from debian salsa. using TARGET_CPPFLAGS=-I"$GNU"/include ../configure --prefix="$GNU" --host=i686-unknown-linux-gnu. But still I am getting "mig-user-not-found" while building initrd for your test. Is there anything i am missing... <youpi>damo22: (acpi translator time to start): You mean, as a bootstrap translator? It's up to it to defer resuming the next translators late enough for RPCs to be working <youpi>“how do i make an RPC block until some part of main.c has completed executing?” You don't, you just let the rest of the world start when you are ready <youpi>“and what happens if an RPC is called before the demuxer is running?” That part is no problem: provided that the port is open, the message will merely be in the queue <youpi>“it appears the gnumach ahci driver does not support ATAPI, but the ide driver does is that correct?” Yes, it's probably "just a matter" of plugging things together <youpi>~15 looks relatively fine enough to me, since documentations talk about 16-byte alignment <youpi>biblio: i686 versions of mig are available in debian <youpi>you can simply install the mig-i686-gnu:i386 package <biblio>youpi: it worked - from debian i386 repo. Now i have 32bit mig. But still getting "mig-user-not-found: command not found" <youpi>also, check config.log where all the details are logged <biblio>youpi: I added dpkg --add-architecture i386 and remove my built mig from PATH. so that it will use mig from installed packages. <luckyluke>biblio: iirc I added a configure option for MIGUSER for my tests, but you also need to adjust all the other paths to your emvironment