<Zopolis4>youpi: but even with the rpc stuff pending gnumach x86_64 works and is good to start testing binutils and the like on? <iska>Zopolis4 I mean since the kernel runs, I think it is <youpi>Zopolis4: testing, no because binutils needs to be taught that hurd-amd64 is a thing, first <iska>so basically we need to port libc/gcc first <Zopolis4>i.e. not literally testing, but moreso hacking <damo22>so i assume we need a development environment that isnt hurd and cross compile everything? <youpi>? no we can cross-compile from hurd <iska>damo22 we should be able to make 64-bit binaries on 32-bin machines ***nckx is now known as nckhexen
<damo22>but with one core that will be painful <damo22>wouldnt it be quicker to cross compile from linux -> 64 bit hurd? <iska>damo22 there's working SMP ;) <iska>It's already been tested on dual-core <iska>no idea, didn't test yet myself, but will soon (on real hardware) <damo22>we should get that merged before trying to compile 64 bit hurd <Zopolis4>do x86_64-only packages count as failures for hurd-i386 on buildd.debian.org? <Zopolis4>because a hurd-amd64 could knock out a few failures <youpi>Zopolis4: usually people write amd64-only, i.e. linux-amd64-only, so it wouldn't be a failure <youpi>that being said it doesn't really matter anyway, debian-ports archs don't care about package failures <iska>Zopolis4 rust is probably failing just because building takes too mach memory <damo22>is the smp_stage2 branch all upstream? <iska>building from linux is faster, but good luck setting that up :) <jab>damo22: I thought the smp support was for dual core only... <jab>is that still the case? <iska>damo22 I think they just didn't send the patches <damo22>im compiling gnumach from sv to see if smp works with no apci <damo22>i wrote it, it doesnt quite work afaik <damo22>no, upstream gnumach smp does not work without apic <damo22>ok i diffed the two trees, there is a manageable patch left <damo22>did AlmuHS assign her copyright for gnumach? <Pellescours>I tried to test APIC, and with rump, I have a lot of message from piixide saying that irq timeout <damo22>Pellescours: i merged smp_stage2 into gnumach but it hangs at boot <Pellescours>For my apic tests, I tried against the current gnumach upstream <Pellescours>And also I don’t know if PAE can work on i386 but when I compile gnumach with PAE i386, it doesnt boot, no message, direct back to grub <Pellescours>I assigned 4G to my gnumach, but only 3GB are used. iirc it’s normal <Pellescours>PAE is disabled by default, that’s why gnumach see only 3GB <Pellescours>After, if you are able to boot gnumach in x86_84, this means that at least PAE works in 64bits <damo22>smp_stage2 has some changes to interrupt.S are they needed? <damo22>it looks like an old reverted version <Pellescours>If I followed the changes of smp_stage2, it’s still mono-cpu. The procedure to start other cpu was not yet implemented, right? <damo22>thats not what people were saying here <Pellescours>Ok I read bad then, I didn’t saw all the code in mp_desc.c <damo22>i get to 5 multiboot modules and then hang <damo22>i should try with smp_stage2 directly <damo22>almu's code assumes apic will be turned on always for smp <damo22>but if you enable it, it breaks at compile time due to outdated irq handling <Pellescours>yes, and now in upstream, if you compile with apic and apic is not available it panic <damo22>but almu is working on an old tree <damo22>i tried porting her work just now to upstream but it breaks <Pellescours>I think with upstream if yout try to compile with linux-groups compilation fails too <damo22>well it shouldnt, i recall fixing that <Pellescours>smp_stage2 should not be so far from upstream, there is some recent merge commit with upstream <damo22>yes, i have been filtering the diff <damo22>is i386/i386/trap.c - (void) addr; thing needed? <damo22>is that that weird bug you found? <Pellescours>the interrupt.c changes fix a trap with i386 compiler ("loop termination" bug iirc) <Pellescours>you need the upstream one, so you don’t need the "Spurious changes to interrupt.S" f36fc994a90a5a7fa598024b54e602d41fa84832 <damo22>what about the locore.S change? its a one liner but only applies to 64 bit <Pellescours>you probably need to have the "addq" version but if you build in i386 you won’t be impacted <damo22>maybe i will try that commit with apic enabled and smp <Pellescours>with apic enabled I have this "../linux/dev/arch/i386/kernel/irq.c:366:19: error: ‘curr_pic_mask’ undeclared (first use in this function)" <damo22>oh yea, i forgot, linux drivers dont work with apic <damo22>probably libirqhelp is needed for pci-userspace <damo22>or you can hack it to use a RPC to acpi <damo22>i just force pushed a few branches there <damo22>i think the problem is, it still needs to enumerate the apics even if apic is not being used for interrupts <damo22>because that is where it gets the smp info from for how many cpus there are <damo22>its not being done when --disable-apic is set <damo22>we need to call acpi_apic_init always if we are using smp <damo22> if (acpi_apic_init() != ACPI_SUCCESS) { <damo22> panic("APIC not found, unable to boot"); <damo22>or maybe i reverted something in master <damo22>ioapic_configure() does not need to be called if we want to use smp without apic interrupts <Pellescours>just to see, I tried your smp-apic branch with rump (without fix for irq) to see how far it goes. And it hangs at "Configuring GDT and IDT" <damo22>someone should tell almu to either rebase onto upstream, or just work on top of my version <damo22>Pellescours: there are two commits that are interesting and not upstreamed from smp-apic <damo22>i think the EOI thing might change the behaviour of apic on qemu <damo22>i was testing it ages ago but never finished <Pellescours>I’m not able to boot because of APICs irq issues but now I see a lot of rumpdisk error messages <Pellescours>I’m gonna recheck that I compiled with both but yeah the kernel I boot on goes longer <damo22>curious about the other change then <Pellescours>I’m testing but it will probably won’t change anything as my lapic will have directed_eoi <damo22>from what i remember, qemu might have a strange ioapic implemented where it doesnt advertise the bit needed for directed eoi or something <Pellescours>On the first boot I got a panic (trap), I didn’t pause on time so loose the message, and next reboots, device timeout on read, so bad too <Pellescours>I will retry without change to ensure I didn’t broke anything <Pellescours>ok so without any modification I also have the timeouts error messages. So I can’t say anything on the impact of the 2 changes <damo22>youpi: #define LAPIC_ENABLE_DIRECTED_EOI 0x1000 <-- this bit is for suppressing the broadcast of EOIs to all APICs... is that the same as enabling directed EOI? <damo22>i thought directed eoi means you get a EOI that is IRQ specific <iska>Pellescours gnumach uses its own 1G physical address space (for the linux glue), that's why only 3G are available. <youpi>damo22: I don't know the details about EOI <damo22>System software desiring to perform directed EOIs for level-triggered interrupts should set bit 12 of the Spurious Interrupt Vector Register and follow each the EOI to the local xAPIC for a level triggered interrupt with a directed EOI to the I/O APIC generating the interrupt (this is done by writing to the I/O APIC’s EOI register). System software performing directed EOIs must retain a mapping associating level-triggered interrupts with <damo22>looks like we are doing it correctly in the ioapic code <damo22>how do we have a functioning timer with apic? it is set to interrupt periodically, is that enough? <damo22>and the hardclock handler is assigned <damo22>we currently have two ivect[] set to hardclock, 0 and the timer_pin (which can be set by an irq override) <damo22>im guessing 0 is an external interrupt source from the PIC/PIT <damo22>with smp enabled and only minimal apic <iska>I have little knowledge in x86 <damo22>maybe interrupts are not disabled when GDT is set up <iska>with how hard it is to get 64bit and smp I wonder how long a RISC-V port would take <youpi>gdt_init is not about interrupts, int_int is ***Noisytoot_ is now known as Noisytoot
<iska>youpi int_int is a confusing name <iska>is it possible to execute a program with its' state saved <Guest93>iska: I think that saving the state of a task should be tribial <Guest93>What is not obvious in my opinion is how and where to serialize port rights <Guest93>I don’t think the Hurd is designed to do that <Guest93>It seems to me like an harder achievement to do it in a micro kernel than a monolithic one <Guest93>And even in Linux all solutions to do it are brittle <iska>Guest93 It may be possible to extract port requests then re-ask <iska>then update the port numbers