TripleFault?

[newbie_os_dsgnr]

Hi, I am following Christopher Giese's Pmode tutorials, and so far, I feel I'm getting on to something, I'm starting with his first tutorial file PM1.ASM, so I went off and cleared out some code to remove the real mode stuff and just to get the code to hang. Don't worry Chris, I'm not trashing the code, I feel it seems the best way to rip the code up to see how it works..., It seems to triple fault, is there anyway I can trap that via exception or isr?, apart from doing this sequence... in nasm...

mov eax, 0b800h
mov es, eax
mov byte [es:dword 0b8000h], '!'
and scattering it across the code to see how far it goes, the code is a DOS .com file a la
org 100h
bits 16
...etc...
(Thanks Chris G and his tutorials for that! http://www.execpc.com/~geezer/os)....my question is what can cause a triple fault?....am running linux with a vmware box....in a dos session...

Many thanks in advance,
tommie.

[slacker]

alot of things can cause a triple fault...

[Tim]

The easiest way to debug a triple fault is to run the code under Bochs. That way, it will tell you why it triple faulted, and the state of the CPU at the time of the fault.

You can't handle a triple fault with an ISR, by definition (it's a fault incurred when handling a double fault).

[Pype.Clicker]

the most common case of triple fault is an invalid entry in the IDT for an exception. And of course, the absence of an IDT will lead to a tripple fault for every exception/IRQ/int xx.

[newbie_os_dsgnr]

Ok, this code selection will show you what I've ripped out to see would this work, what I am hoping would appear is R!P {Real, !, Protected respectively}, It appears as R but it doesn't get further than ! ie ! does not show, any ideas why?
here's the code under NASM....
[org 0x100]
[bits 16]
start: cli
mov ax, 0xb800
push ax
mov es, ax
mov byte [es:0], 'R'
ldgt [gdtr]
mov eax, cr0
or al, 1
mov cr0, eax
pop ax
mov es, ax
mov byte [es:2], '!'
jmp CODE_SELECTOR:ProtMode
[bits 32]
ProtMode: mov eax, DATA_SELECTOR
mov ds, eax
mov ss, eax
mov eax, LINEAR_SELECTOR
mov es, eax
mov byte ptr [es:dword 0xb8004], 'P'
mov byte ptr [es:dword 0xb8005], 0x1b
hanging:
jmp hanging

gdtr:
db gdt_end - gdt - 1
dw gdt

gdt: ;
gdt_null:
NULL_SELECTOR equ $-gdt
dd 0
dd 0
gdt_linear:
LINEAR_SELECTOR equ $-gdt
dw 0xffff
dw 0
db 0
db 0x92
db 0xcf
db 0
gdt_code:
CODE_SELECTOR equ $-gdt
dw 0xffff
dw 0
db 0
db 0x9a
db 0xcf
db 0
gdt_data:
DATA_SELECTOR equ $-gdt
dw 0xffff
dw 0
db 0
db 0x92
db 0xcf
db 0
gdt_end:;

Hope u could help me out....
Thanks,
Tommie.

[Pype.Clicker]

Ok, this code selection will show you what I've ripped out to see would this work, what I am hoping would appear is R!P {Real, !, Protected respectively}, It appears as R but it doesn't get further than ! ie ! does not show, any ideas why?
here's the code under NASM....

Code: Select all

...
mov eax, cr0
or al, 1
mov cr0, eax
pop ax
mov es, ax
mov byte [es:2], '!'
jmp CODE_SELECTOR:ProtMode
[bits 32]

Hey, dude, what do you expect, here ? you're loading ES with a real mode segment (0xB800) in protected mode !! . That segment isn't in your gdt --> it will raise a "Segmentation Fault", but you have no valid IDT --> triple fault & reset ...

If you really need so precise debugging information (but imho, you should just remove it and pray), use something that is not memory related like changing the background color (using VGA palette ports) or the overscan color (see marker() macro in SOS)

[newbie_os_dsgnr]

Ok! I can see that so that's a whoopsie there.......tried that and still triple faulted!! Just got an R on the upper left corner of screen, no 'P'....do you recommend that I should have the IDT set up to make life easier for me to trap the pesky exceptions..., if so, is there an easy code sample to do this for a 16bit .com file executable?

Many regards,
Tommie.

[Pype.Clicker]

Okay, now get a look at your GDT. you have 0-based DATA and CODE segments, while your .COM file can virtually loaded anywhere in memory...

I would suggest you to get a look at some pmode tutorial before you go on, or you'll be losing time.

for a quickfix, you should do the following (in the real mode part):

Code: Select all

xor ebx,ebx
mov bx,cs
shl ebx,4
mov [gdt+codesel+baselo],bx
shr bx,16
mov [gdt+codesel+baseme],bl
mov [gdt+codesel+basehi],bl

do the same for datasel.
"baselo", "baseme" and "basehi" are the offset for the base fields in the GDT descriptor, you must %define them first ...

[newbie_os_dsgnr]

Okay, now get a look at your GDT. you have 0-based DATA and CODE segments, while your .COM file can virtually loaded anywhere in memory...

I would suggest you to get a look at some pmode tutorial before you go on, or you'll be losing time.

for a quickfix, you should do the following (in the real mode part):

Code: Select all

xor ebx,ebx
mov bx,cs
shl ebx,4
mov [gdt+codesel+baselo],bx
shr bx,16
mov [gdt+codesel+baseme],bl
mov [gdt+codesel+basehi],bl

do the same for datasel.
"baselo", "baseme" and "basehi" are the offset for the base fields in the GDT descriptor, you must %define them first ...

Cool! Will do that and check it out and get back to you....
Many thanks for your time and patience.....
Regards,
Tommie.

[newbie_os_dsgnr]

right! here's the code I did to patch up the gdt......

xor ebx, ebx
mov bx, cs
shl ebx, 4
mov eax, ebx
mov [gdt_linear+2], bx
mov [gdt_code+2], bx
mov [gdt_data+2], bx
shr ebx, 16
mov [gdt_linear+4], bl
mov [gdt_code+4], bl
mov [gdt_data+4], bl
....

still triplefaulting?!....a question, regarding IDT...
I have seen IDT set up this way...
...code....
isr0:
pusha
.....
popa
iret

IDTR: dw IDTEnd - IDT ; Limit
dw IDT ; base
IDT:
offset_lo dw isr0 ; where isr0 routine is coded above
codesel dw 0x8 ; code selector
zeroes db 0
settings db 0x8E
offset_hi db 0

should offset_hi be set up in the same way as the code for patching up the gdt? i.e. mov [idt + 7], bx
BTW having studied some earlier postings re: IDT's I couldn't help wondering but the data selector is used in place of the code selector - why? Prior to loading IDT, I'll assume that pic's have been reprogrammed previously - am familiar with this bit! Woohoo..that's how I learn.....

Many thanks,
Tommie.

[Pype.Clicker]

- you should not patch your LINEAR descriptor as this one is used to acces memory in a pure linear fashion (i.E. we want linear_selector:0xB8000 to be mapped to video memory

- the base of gdtr and of idtr must be patched (because they must be linear address, according to the docs)

- don't bother with IDT until you have a character displayed correctly proving you reached protected mode.

[newbie_os_dsgnr]

Hello,

I feel so good and happy that I've finally cracked it...please feel free to browse the source code attached. Kudos to Chris Giese and Alexei A. Frounze for their tutorials....next up on my todo is IDT descriptors and their respective isr's....

Regards,
Tommie. ;D

[attachment deleted by admin]