IRC channel logs


back to list of logs

<damo22>i cant find it but something is trying to access 0xff008f instead of phystokv(0xff008f)
<Pellescours>damo22: something userland or kernelland?
<damo22>something is fishy with spl0()
<damo22>ahh i think i know what could be wrong.. the interrupt vector pointers may be set to low addresses so when the interrupts are enabled it crashes
<damo22>we need to reload the ivect[] table after switching the gdt or something
<damo22>or preload them with correct addressing
<damo22>arggh maybe enabling interrupts so early is bad because bios has not inited the APs
<damo22>and put them to sleep
<damo22>i got past a nasty bug
<damo22>CPU_NUMBER() was still wrong
<damo22>youpi: does this function now make sense?
<damo22>its a macro that takes a register as argument
<damo22>is it supposed to write the cpu number to the reg or use it as input for the apic id?
<youpi>CPU_NUMBER is supposed to put in the reg the cpu number (numbered from 0)
<youpi>so not the apic id (which iirc is not necessarily consecutive from 0)
<damo22>yeah i think ive done it correctly in that file
<youpi>note that you probably want to save the other caller-saved registers (esi and edi)
<damo22>how do i know what i need to save?
<damo22>what if cpu_number clobbers ecx and edx?
<youpi>it's the x86 ABI
<youpi>ecx and edx are callee-saved
<damo22>kernel: Page fault (14), code=0
<damo22>Stopped at thread_select.part.0.constprop.0+0xc9: cmpl $0x1,0x58(%eax)
<damo22>eax is 0
<damo22><-- sleep