IRC channel logs

<damo22>"youpi: gdt_init is not about interrupts" ... no but if an interrupt happens while the gdt is being set up that would break things

<damo22>i cant see how this is hanging

<damo22>is the gdt required to be set up on all APs?

<youpi>damo22: ints are not enabled at that point

<youpi>int_init sets the vectors

<youpi>and interrupts are enabled much later on

<damo22>youpi: ljmp $0x8, $M(0f) <--- in cpuboot.S isnt it just supposed to jump to the next instruction to flush the queue?

<damo22>why is it jumping to $M(0f)

<damo22> http://git.zammit.org/gnumach-sv.git/log/?h=feat-smp

<youpi>where are you looking at?

<youpi>ah, cpuboot.S

<damo22>yes sorry

<youpi>in boothdr.S it is documented that the jump is used to load the new segment set by lgdt

<damo22>in apboot it looks like it sets the selectors in 16 bit mode to 0 (is that valid?) and then enters protected mode

<youpi>I don't know the details

<damo22>but i dont understand the M(0f) jump

<damo22>it should be ljmp $0x8, 0f

<damo22> ljmp $0x8, $0f

<damo22>somehow (0 - apboot + 0x7000) is the address of the next instruction?

<damo22>(0f - apboot + 0x7000)

<youpi>it is possibly just cargo-culted code

<damo22>i found an explanation in the intel 32/64 manual

<damo22>youpi: should the APs share the same boothdr.S code?

<damo22>as i understand, starting the APs is slightly different to starting the BSP, because we are not using interrupts on the APs and they need to be added to the kernel somehow instead of start it from scratch

<damo22>after "call cpu_ap_main" what is the cpu supposed to do?

<damo22>i believe it is executing garbage

<damo22>how do you add an AP to the kernel so it sleeps waiting for more instructions?

<damo22>ok it should call slave_main

<damo22>im getting further, im stuck on Sending IPI to APIC ID 1

<damo22>ah, APs start up in real mode

<damo22>so you need some 16 bit code to make it switch to 32 bit

<damo22>cpu_number: 0

<damo22>Sending IPIs to APIC ID 1...done

<damo22>AP 1: Waiting for BSP to complete SMP init

<damo22>somehow the BSP never finishes

<damo22>Sending IPIs to APIC ID 1...donAP 1: Waiting for BSP to complete SMP init

<damo22>Started cpu 1 (lAPIC ID 1...donAP 1: Waiting for BSP to complete SMP init

<damo22>Started cpu 1 (la

<damo22> 00001) 0

<damo22>BSP: Completed SMP init

<damo22>AP m:odO!e 0: acpi --host-priv-port=${host-port} --device-master-port=${device-p

<damo22>Starting cpu with APIC ID 1 setup

<damo22>getting somewhere

<damo22>youpi: after running mp_desc_init(1) (on the first AP) a variable containing the value 1 changed its value to 16910336 without even writing to it

<damo22>on the AP

<damo22>im running this version http://git.zammit.org/gnumach-sv.git/log/?h=feat-smp

<iska>damo22 so did you make SMP usable?

<damo22>iska: its almost booting

<iska>ohhhh

<iska>very close then

<damo22>the BSP is waiting for the APs to complete initialisation

<damo22>but they are up

<damo22>something wrong with the addressing

<iska>would it have been easier if gnumach was in virtual memory?

<damo22>what does that mean?

<iska>(like the original mach was)

<damo22>the APs need to be configured to access memory the same way as the BSP

<damo22>but calling gdt_init() crashes the processor

<iska>hmmm

<iska>can you remind what BSP and AP is

<damo22>BSP is like cpu0

<damo22>APs are all the rest

<iska>ahhh

<damo22>BSP coordinates the smp inititalisation

<damo22>see my last few commits on top of Almu's code

<damo22>i fixed the IPI sequence

<damo22>etc

<damo22>i think the problem is interrupt_stack[] is just defined in the C code but has no allocation for the stack?

<iska>hmmm, try it out

***mbanck is now known as azeem

<damo22>Sending IPIs to APIC ID 1...done

<damo22>Started cpu 1 (lapic id 00000001)

<damo22>BSP: Completed SMP init

<damo22>cpu_setup: 1

<damo22>AP 16910336 slaved

<damo22>maybe i cannot access a previous variable stored in memory after switching the selectors / gdt

<damo22>?

<damo22>maybe its sitting on the stack and the stack was switched

<iska>damo22 can you help me build your gnumach?

<iska>gcc errors because of a cpu_number() #define

<damo22>im getting close

<damo22>let me push what ive got again

<damo22>something is changing the value of cpu

<damo22>and thus it never completes the init because its waiting for a bogus cpu number to be ready

<damo22>iska: see my updated branch

<iska>damo22 same error

<iska> https://paste.debian.net/1255712/

<damo22>iska: i get this:

<damo22>AP=(1) after

<damo22>AP 16910336 slaved

<iska>ahh

<iska>what hardware can do that?

<youpi>damo22: remember that you can use watchpoints to trap variable changes

<damo22>you need to run autoreconf -fi in the base gnumach/ directory, then mkdir build && cd build && ../configure --enable-kdb --disable-apic --enable-ncpus=8

<damo22>iska: ^

<iska>aahh

<youpi>damo22: with db_set_hw_watchpoint

<damo22>i got AP 1 slaved, then a character "m" and nothing, i think the BSP tried to boot the system but something about bringing the AP online crashed it

<damo22>im running qemu with --no-reboot --no-shutdown

<damo22>yah its crashing the cpu

<damo22>what happens if the BSP is running in 32 bit flat mode and the APs try to run in protected mode?

<damo22>youpi: i cant see where the uniprocessor gnumach jumps to protected mode? CR0_PE is not set anywhere

<youpi>grub does it already

<youpi>'CR0'

<youpi> Bit 31 (PG) must be cleared. Bit 0 (PE) must be set. Other bits

<youpi> are all undefined.

<youpi>from the multiboot standard

<damo22>okay

<damo22>thing is, APs come up in real mode when you send IPI

<youpi>that's not really surprising since that's the bootup state for a processor

<damo22>so we should be using PE

<damo22>for the APs as well

<damo22>ok something is wrong with the cpuboot.S

<damo22>or mp_desc.c

<Pellescours>damo22: for this commit http://git.zammit.org/gnumach-sv.git/commit/?h=feat-smp&id=e803b9fc75146c5f0b8384603e557664c501cc66, if you want to be correct the condition should be "if (NCPU > 1) || defined(APIC)" otherwise you’ll break APIC because stuctures won’t be initialized

***ay is now known as Andrew

<luckyluke>Shouldn't APIC be always enabled when NCPU>1?

<luckyluke>Iirc it's needed to send IPI

IRC channel logs

2022-10-02.log