IRC channel logs

<damo22>luckyluke: good point, maybe the APIC setting should be called IOAPIC

<damo22>since it might be possible to route interrupts via the PIC and still send an IPI via the LAPIC

<damo22>maybe this mode is not supported, and crashes the cpu when an interrupt happens on the pic and APs are started

<damo22>or tries to interrupt all cores

<youpi>gnu_srs: thanks for your socat patch, I have uploaded it to unreleased. It'd probably be useful to forward it to upstream

<youpi>gnu_srs: note that it's better to use X-Debbugs-Cc: debian-hurd@lists.debian.org

<youpi>so that further discussions get Cced to the list

<damo22>hmm the pointer to the stack cant be located at a fixed address, otherwise when you copy the startup vector routine to 0x7000 it will clobber the previous AP's stack_ptr

<damo22>each cpu needs its own unique stack

<damo22>the stacks are being allocated separately, but then a pointer to each structure is stored at the same address

<damo22>really this mixture of C and asm is hard to follow

<Pellescours>damo22: using an array should allow to fix the same address issue right?

<damo22>its already in an array, yes, but there is no mention of the index

<damo22>so its being stored in a single variable pointer

<damo22>the problem is, how do you get access to the index of the cpu in the asm code

<Pellescours>by providing it as argument?

<damo22>there is no argument in a startup vector

<damo22>its booting from scratch

<Pellescours>cpuid?

<damo22>right

<damo22>but will the cpuid match the kernel id?

<damo22>somehow there is an extra indirection from apic id to kernel id

<damo22>i guess i can look it up

<damo22>ok at least i have something to work on after work

<damo22>Pellescours: feel free to try this without apic but with ncpus>1 http://git.zammit.org/gnumach-sv.git/log/?h=feat-smp

<damo22>its getting closer

<damo22>but has the problems mentioned above

<Pellescours>if damo22 https://www.naic.edu/~phil/software/intel/253668.pdf section 8.4.5 I think it can help you

<damo22>hmm i also need to enable the lapic spurious register bit 8

<damo22>to allow IPIs

<Pellescours>I tested your branch, and it reboot (quickly, last message I saw was about AP)

<damo22>yeah i know its broken

<damo22>you can try running with --no-reboot --no-shutdown

<damo22>then the message will persist but you will have to use the console to restart

<Pellescours>yeah

<Pellescours>Last message is AP 1 slaved

<damo22>thats pretty good, but we do need to fix the stack pointers and enable the lapic

<damo22>cpuboot.S is for the AP start up vector

<damo22>"apboot" gets copied to 0x7000

<damo22>since it needs a 16 bit mode address to run

<damo22>i think we need to read the apic id and look up corresponding kernel id, then assign cpu_stack[cpu] to the stack

<Pellescours>probably yes

<Pellescours>time to sleep for me

<Zopolis4>is the x86_64 stuff good to boot on real hw?

<damo22>Zopolis4: i am working hard to get SMP working so i can have more cores in hurd

<damo22>then i can help with 64 bit

<damo22>i *think* smp can work on i386

<iska>Zopolis4 some things are missing but yeah

<iska>no 64-bit userspace yet though (yet)

<iska>damo22 can you update the branch?

<iska>also, the last thing I see is "unexpected ACK from keyboard"

<luckyluke>damo22: why would you use PIC for interrupts and IOAPIC for IPI?

<luckyluke>Zopolis4: it *almost* boots with a 32 bit userspace, if you take the pending patches, but no drivers yet, so you should use a ramdisk

<luckyluke>For a 64 bit userspace, one missing thing is the syscall interface

<luckyluke>However using a ramdisk has space limits, apparently due to the current memory map

<luckyluke>I have a partial fix for that, but lately not much time to work on it

<damo22>luckyluke: IOAPIC interrupts are not working correctly yet, so PIC is kinda useful for handling that, and LAPIC can do IPI

<damo22>that will get us i386 with SMP potentially without changing much

<iska>damo22 it also doesn't reboot, --no-reboot --no-shutdown basically does nothing here

<iska>(I'm using qemu on Guix)

<damo22>i just finished $DAYJOB for the day, i can start working on hurd again

<damo22>im getting somewhere, BSP completes IPI sequence and then it stalls for a couple of seconds and then the AP runs and crashes

<iska>ohhh

<damo22>i just pushed to my branch

<iska>lemme try

<damo22>it booted with the second cpu in a tight loop

<damo22>instead of letting it go to slave_main

<iska>oooo

<iska>nice!

<iska>can you enter kdb from there?

<damo22>for some reason no

<damo22>theres no IDT

<damo22>so it crashes when an interrupt happens on the AP

<damo22>i think its crashing when an interrupt/exception happens on the AP

<damo22>youpi: but it boots when i put the AP into a tight loop and dont let it do anything

<iska>damo22 can you do the same for all other CPUs?

<damo22>i only used 2 in total

<iska>what would happen if you used 4

<damo22>i can try but not yet

<iska>hm

<iska>can you push the remote repo so I could?

<damo22>it is

<damo22>you just insert a for(;;); before slave_main

<damo22>for ( ; ; ) ;

<iska>cool

<damo22>it will hog 400% cpu load

<damo22>while booting

<iska>damo22 at least we got the CPUs to execute :)

<damo22>yes

<damo22>so how do we make the APs ignore interrupts

<damo22>but allow exception handling

<damo22>i got it not to crash

<damo22>but the cpus are waiting for something

<damo22>and i cant enter kdb

<iska>yay!

<iska>damo22 perhaps debug from qemu?

<damo22>gotta sleep

<damo22>but i just pushed something that boots with APs in a loop

<damo22>something is wrong with exceptions/interrupts

<damo22>maybe we need ioapic after all

<Pellescours>damo22: with your latest code, trap page_fault with apic

<Pellescours>It seems, without apic I also have a page_fault, I’m booting with rump, last message is "start pci-arbiter: pci "

IRC channel logs

2022-10-03.log