IRC channel logs


back to list of 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:
<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
<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
<damo22>its getting closer
<damo22>but has the problems mentioned above
<Pellescours>if damo22 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>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
<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>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>can you push the remote repo so I could?
<damo22>it is
<damo22>you just insert a for(;;); before slave_main
<damo22>for ( ; ; ) ;
<damo22>it will hog 400% cpu load
<damo22>while booting
<iska>damo22 at least we got the CPUs to execute :)
<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>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 "