IRC channel logs


back to list of logs

<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
<youpi>basically yes
<Zopolis4>by testing i mean teaching and the like
<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
<iska>Zopolis4 of course
<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 ;)
<damo22>working smp without apic??
<iska>It's already been tested on dual-core
<damo22>how does the timer work?
<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
<damo22>8 cores will speed up building
<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>damo22 nope
<iska>building from linux is faster, but good luck setting that up :)
<iska>Guix might help you
<damo22>why isnt it upstream?
<jab>damo22: I thought the smp support was for dual core only...
<jab>is that still the case?
<damo22>smp supports 256 cores
<damo22>as far as i know
<damo22>my machine has 8
<iska>damo22 I think they just didn't send the patches
<damo22>we need to fix that
<damo22>im compiling gnumach from sv to see if smp works with no apci
<iska>mach has apic AFAIK
<damo22>i wrote it, it doesnt quite work afaik
<damo22>no, upstream gnumach smp does not work without apic
<damo22>what is it missing?
<damo22>is github down?
<damo22>ok i diffed the two trees, there is a manageable patch left
<jab>that's awesome!
<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
<damo22>i better diff it again
<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
<damo22>im using 4GB memory
<Pellescours>I assigned 4G to my gnumach, but only 3GB are used. iirc it’s normal
<damo22>how do you disable pae
<damo22>at compile time?
<Pellescours>yes, but 3G is with the debian packaged gnumach
<Pellescours>when I compile with --enable-pae then it don’t boot
<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
<damo22>RTC time is 2022-10-01 01:58:20
<damo22>cpu stacks reserved
<damo22>starting cpus
<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
<Pellescours>for that, disable-linux-group
<Pellescours>That will work
<damo22>i cant rely on rumpdisk yet
<damo22>too many variables
<Pellescours>So need to fix linux irq, or rumpdisk one
<damo22>i already fixed linux irq
<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)
<damo22>where is that?
<Pellescours>the 2 last commit
<Pellescours>the 2nd last one
<damo22>do i need that commit?
<damo22>or revert it
<Pellescours>you need it
<Pellescours>you need the upstream one, so you don’t need the "Spurious changes to interrupt.S" f36fc994a90a5a7fa598024b54e602d41fa84832
<damo22>i thought that was the case
<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>so in theory this should work
<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
<Pellescours>what is needed to have rump with apic?
<damo22>probably libirqhelp is needed for pci-userspace
<damo22>so it looks up the irq
<damo22>that is all
<damo22>or you can hack it to use a RPC to acpi
<damo22>instead of using intrline
<damo22>i just force pushed a few branches there
<damo22>to clean up the patches
<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>but that is currently disabled
<Pellescours>that’s done in gnumach
<Pellescours>what is the issue then?
<damo22>its not being done when --disable-apic is set
<Pellescours>but apic is needed for APIC
<Pellescours>but apic is needed for SMP*
<damo22>we need to call acpi_apic_init always if we are using smp
<Pellescours>that’s what we do
<damo22>no we dont:
<damo22>#if defined(APIC)
<damo22> if (acpi_apic_init() != ACPI_SUCCESS) {
<damo22> panic("APIC not found, unable to boot");
<damo22> }
<damo22> ioapic_configure();
<damo22> lapic_enable_timer();
<damo22>#if (NCPUS > 1)
<damo22> smp_init();
<damo22>its wrong
<damo22>or maybe i reverted something in master
<damo22>from master*
<Pellescours>APIC need to be enable if we allow NCPU > 1
<Pellescours>can SMP work without APIC?
<damo22>ioapic_configure() does not need to be called if we want to use smp without apic interrupts
<damo22>yes i think its possible
<damo22>or we should at least try
<Pellescours>it’s easy to change then
<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"
<Pellescours>imo smp_stage2 is not ready
<damo22>smp-apic branch??
<damo22>i forgot about that
<damo22>thats very old
<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> and
<damo22>i think the EOI thing might change the behaviour of apic on qemu
<damo22>and the timer pin thing also
<damo22>i was testing it ages ago but never finished
<Pellescours>should I test them with apic only or apic and smp?
<damo22>probably apic only
<Pellescours>I tested with smp and apic, and… it don’t hang
<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
<Pellescours>Ah I compiled the wrong gnumach repo
<Pellescours>so the 2 commits of SMP are not here
<Pellescours>so it’s like no smp
<Pellescours>it does not change anything for SMP, I just checked
<Pellescours>your changes make things worse, now I’m not able to use rump, reads timeouts
<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
<damo22>im not sure though
<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
<Pellescours>time to sleep for me
<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 dont think it is
<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: yes she did
<youpi>(assign copyright)
<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> the I/O APICs in the system.
<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>that doesnt sound right
<damo22>im guessing 0 is an external interrupt source from the PIC/PIT
<damo22>i dont know how it is wired up
<damo22>it currently hangs on gdt_init
<damo22>with smp enabled and only minimal apic
<iska>what's gdt?
<iska>I have little knowledge in x86
<damo22>same with me
<damo22>maybe interrupts are not disabled when GDT is set up
<damo22>that could be bad
<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
<youpi>int_init, I mean
<iska>is it possible to execute a program with its' state saved
<iska>basically checkpoints
<Guest93>iska: I think that saving the state of a task should be tribial
<Guest93>From within the kernel
<Guest93>serializing threads probably also
<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
<Guest93>I might be wrong about that
<iska>Guest93 It may be possible to extract port requests then re-ask
<iska>then update the port numbers