Just knowing where it breaks could be enough to figure out the problem. Are you able to get GDB to step through the code?CristiV wrote:Well, I've loaded a GDT, using the example on this forum. Not an IDT, yet. But it still breaks somewhere.
0x08 is the value of the vectorEthin wrote:What vector are you sending?
I just used the example provided on the wiki, to see if it would work. Someone said here that the lack of a GDT when switching to the protected mode leads to a triple fault.rdos wrote:I can see several problems in the code. First, a far jmp is done to segment 8040, which is linear address 804000. Next, GDT is loaded based on the code being at 80xx, and finally, none of the selectors in the GDT are actually loaded, and so there is no use in loading the GDT in the first place. This results in 32-bit code being entered with real mode selectors still loaded, which is sure to tripple fault.
I think that is more or less a prerequisite for writing code like this. Real mode has 64k limits on all segments, and the linear address is formed by shifting the segment value four bits left and adding the offset. For protected mode, you load selectors from the GDT and the base & limit in the GDT determines how the linear address is calculated. To load a new CS selector, you must do a far jmp (or far call, ret, iret) to the selector. So, it's not enough to define flat selectors in the GDT, you also must load them. Of note is also that the default operand size is determined by the CS selector bitness, and real mode and 32-bit flat mode have different default operand sizes, and so if you do a far jmp through your flat selector, the code it jumps to needs to have 32-bit default bitness.CristiV wrote:0x08 is the value of the vectorEthin wrote:What vector are you sending?
I just used the example provided on the wiki, to see if it would work. Someone said here that the lack of a GDT when switching to the protected mode leads to a triple fault.rdos wrote:I can see several problems in the code. First, a far jmp is done to segment 8040, which is linear address 804000. Next, GDT is loaded based on the code being at 80xx, and finally, none of the selectors in the GDT are actually loaded, and so there is no use in loading the GDT in the first place. This results in 32-bit code being entered with real mode selectors still loaded, which is sure to tripple fault.
I'm yet to fully understand how GDT, IDT and the real mode work
Someone correct me if I'm wrong, but I believe that that's not a valid interrupt. If memory serves the APIC/XAPIC/X2APIC can only send interrupts 0x10-0xFE, but anything below int 0x20 is a processor exception and should be avoided.CristiV wrote:0x08 is the value of the vectorEthin wrote:What vector are you sending?
It's not a valid interrupt for IPIs that use it as an interrupt vector, but it's valid for a STARTUP IPI. (I seem to recall a different set of vectors are considered invalid for SIPI, but I don't see it mentioned in the latest SDM.)Ethin wrote:Someone correct me if I'm wrong, but I believe that that's not a valid interrupt.
Code: Select all
lock addl %esi, smp_aprunningCode: Select all
lock addq %rsi, smp_aprunningCode: Select all
mov QWORD PTR [rbp-0x1b8],r8Code: Select all
mov DWORD PTR [rbp-0x1b8],eaxI hope you have the best of luck while presenting it!CristiV wrote:New update: Everything works fine now. My thesis is complete, and I'll present it soon.
The problem I had was with the 64-bits GDT entry for the Code segment. That was putting my APs in the compatibility mode.
Thank you all for the help and patience!
Code: Select all
(gdb) info registers
eax 0x0 0
ecx 0x0 0
edx 0x663 1635
ebx 0x0 0
esp 0x0 0x0
ebp 0x0 0x0
esi 0x0 0
edi 0x0 0
eip 0x1 0x1
eflags 0x2 [ IOPL=0 ]
cs 0x800 2048
ss 0x0 0
ds 0x0 0
es 0x0 0
fs 0x0 0
gs 0x0 0
fs_base 0x0 0
gs_base 0x0 0
k_gs_base 0x0 0
cr0 0x60000010 [ CD NW ET ]
cr2 0x0 0
cr3 0x0 [ PDBR=0 PCID=0 ]
cr4 0x0 [ ]
cr8 0x0 0
efer 0x0 [ ]