Bochs error

[vibhory2j]

while working on my os i found a error in bochs. the error is as follows :

Bochs is exiting with the following message:
[CPU ] load_seg_reg: SS: new_value == 0

the os hanged after initializing a couple of things in the kernel.
wht could this be and how can i rectify it.
please help me.
thanks in advance for any help.

[octavio]

post some code.

[vibhory2j]

which code should i need to post??

for the time .. here is my assembly language for kernel entry point:

[BITS 32]

[global start]
[global keyb_int]
[global syscall]
[global scheduler]

start:
mov esp, _sys_stack ; This points the stack to our new stack area
jmp stublet

; This part MUST be 4byte aligned, so we solve that issue using 'ALIGN 4'
ALIGN 4
mboot:
; Multiboot macros to make a few lines later more readable
MULTIBOOT_PAGE_ALIGN equ 1<<0
MULTIBOOT_MEMORY_INFO equ 1<<1
MULTIBOOT_AOUT_KLUDGE equ 1<<16
MULTIBOOT_HEADER_MAGIC equ 0x1BADB002
MULTIBOOT_HEADER_FLAGS equ MULTIBOOT_PAGE_ALIGN | MULTIBOOT_MEMORY_INFO | MULTIBOOT_AOUT_KLUDGE
MULTIBOOT_CHECKSUM equ -(MULTIBOOT_HEADER_MAGIC + MULTIBOOT_HEADER_FLAGS)
EXTERN code, bss, end

; This is the GRUB Multiboot header. A boot signature
dd MULTIBOOT_HEADER_MAGIC
dd MULTIBOOT_HEADER_FLAGS
dd MULTIBOOT_CHECKSUM

; AOUT kludge - must be physical addresses. Make a note of these:
; The linker script fills in the data for these ones!
dd mboot
dd code
dd bss
dd end
dd start

; This is an endless loop here. Make a note of this: Later on, we
; will insert an 'extern _main', followed by 'call _main', right
; before the 'jmp $'.
stublet:
push ebx         ; store the pointer to the Grub multi boot header for later use
extern kmain

call kmain
jmp $


global gdt_flush ; Allows the C code to link to this
extern gdtp ; Says that 'gdtp' is in another file

global idt_load
extern idtp


gdt_flush:
lgdt [gdtp] ; Load the GDT with our 'gp' which is a special pointer
mov ax, 0x10 ; 0x10 is the offset in the GDT to our data segment
mov ds, ax
mov es, ax
mov fs, ax
mov gs, ax
jmp 0x08:flush2 ; 0x08 is the offset to our code segment: Far jump!
flush2:
ret ; Returns back to the C code!

; Service Routines (ISRs) right here!
idt_load:
   lidt [idtp]
   ret

; here goes the isr definitions


;The Following functions are used in enabling and disabling Paging
[global _read_cr0]
_read_cr0:
   mov eax, cr0
   retn

[global _write_cr0]
_write_cr0:
   push ebp
   mov ebp, esp
   mov eax, [ebp+8]
   mov cr0, eax
   pop ebp
   retn

[global _read_cr3]
_read_cr3:
   mov eax, cr3
   retn

[global _write_cr3]
_write_cr3:
   push ebp
   mov ebp, esp
   mov eax, [ebp+8]
   mov cr3, eax
   pop ebp
   retn

extern do_syscall
extern sched
extern keyb_handler


scheduler:
   call sched
   jmp repeat


repeat:   
   iret

keyb_int:
   call keyb_handler
   jmp re_keyb_int

re_keyb_int:
   iret


;syscall:
   ;call do_syscall
   ;jmp re_syscall

;re_syscall:
   ;iret


; Here is the definition of our BSS section.
; the identifier '_sys_stack'
SECTION .bss
resb 8192 ; This reserves 8KBytes of memory here
_sys_stack:

[Pype.Clicker]

unless you have an explicit "mov ss, 0" somewhere, this is likely an automated "pop ss" that popped the wrong thing.

I suggest you get the "EIP" value reported by bochs on the crash, and look what you have there. If that doesn't make it clearer, try to set a breakpoint there, dump the cpu & stack content at that point and come back with that plus the sources of what's being executed at faulty EIP.

[vibhory2j]

here are the details:

section of bochsout.txt
00126650360i[CPU ] | EIP=00101522 (00101522)
00126650360i[CPU ] | CR0=0xe0000019 CR1=0x00000000 CR2=0x00000070
00126650360i[CPU ] | CR3=0x0000c000 CR4=0x00000000


section of objdump
00101510 <sched_del>:
101510:   8b 4c 24 04    mov 0x4(%esp,1),%ecx
101514:   8b 15 e8 50 10 00    mov 0x1050e8,%edx
10151a:   39 4a 70    cmp %ecx,0x70(%edx)
10151d:   74 08    je 101527 <sched_del+0x17>
10151f:   8b 52 70    mov 0x70(%edx),%edx
101522:   39 4a 70    cmp %ecx,0x70(%edx)
101525:   75 f8    jne 10151f <sched_del+0xf>
101527:   8b 41 70    mov 0x70(%ecx),%eax
10152a:   89 42 70    mov %eax,0x70(%edx)
10152d:   39 0d ec 50 10 00    cmp %ecx,0x1050ec
101533:   75 06    jne 10153b <sched_del+0x2b>
101535:   89 15 ec 50 10 00    mov %edx,0x1050ec
10153b:   c3    ret


void sched_del(struct task* del_task)
{
// we remove task from tasks queue
struct task *tmp = first;

while(tmp->next != del_task)
   tmp = tmp->next;

tmp->next = del_task->next;

if(last == del_task)
   last = tmp;
}

But after playing with the source code ... the above mentioned exception disappeared. and a new exception is occuring : page fault at address 0x0

thanks in advance for any help

[paulbarker]

I suggest you attack your kernel with assertions. Define an assert macro which works like the standard, and use it wherever you can.

For example the C function you have posted should at least assert its argument is non-NULL, and maybe should assert that first is also non-NULL.

[Pype.Clicker]

Code: Select all

   while(tmp->next != del_task)
   tmp = tmp->next;

that won't be terminating if del_task is accidentally not in the list. I strongly suggest you always check pointers like e.g.

Code: Select all

  while (tmp && tmp->next!=del_task)
      tmp = tmp -> next;
  if (!tmp) return ERROR;
  ...

Moreover, you may find yourself in trouble if you manipulate the scheduler's list without preventing other threads (or the scheduler itself) to do the same in the meantime ... Think about proper synchronization control of your code.