Page 2 of 2

Posted: Sun Oct 21, 2007 3:06 pm
by os64dev
either prefix 'TSS tss[max_tasks];' with static making 'static TSS tss[max_tasks];' or put the line outside the function. The later being the preferred method.

Posted: Sun Oct 21, 2007 6:20 pm
by mohammed
okay i will insert it inside the function !!
any thing else ??
here is my new code there is a warning that is saying data definition has no type or storage class

Code: Select all

#define ACS_TSS_GATE    0x09
#define max_tasks      1
task();
initialize_tasks()
{
typedef struct   {       
unsigned long link,
        esp0,
        ss0,
        esp1,
        ss1,
        esp2,
        ss2,
        cr3,
        eip,
        eflags,
        eax,
        ecx,
        edx,
        ebx,
        esp,
        ebp,
        esi,
        edi,
        es,
        cs,
        ss,
        ds,
        fs,
        gs,
        ldtr;
unsigned short  trace,
        io_map_addr;
}__attribute__((packed))TSS;
TSS tss[max_tasks];
/*          number  base     limit               type                  granularity */
gdt_set_gate(3       ,  tss[0],    sizeof(TSS),   ACS_TSS_GATE, 0xCF);  /*selector is 0x18*/
gdt_flush();
tss[0].cs = 0x08;
tss[0].eip = (unsigned int)&task;                     
tss[0].eflags = 0x202L;                       
  __asm__ __volatile__("ltr 0x18 \n\t"
                               "jmp  0x18\n\t");

}
task()
{
puts("i am task one!!!\n");
__asm__ __volatile__("iret");
for(;;);
}

Posted: Sun Oct 21, 2007 6:23 pm
by Brynet-Inc
Did you even understand what people have been telling you? :roll:

Posted: Mon Oct 22, 2007 3:44 am
by Combuster
I tend to agree with brynet-inc - You do not know your language well enough to be programming operating systems.

Kowing the base language for development inside out is a definate requirement. You must know what the compiler does with what code, and have a good idea about the machine code generated by it. That way you can see from the code what the processor should do. Next there's a bit of experience - if you have written a few large projects you know what you can and cannot do with a language. Based on the fact that you have half the top 10 of beginners errors in your code and being unable to see it I can only conclude that this subject is too advanced for you.

I suggest you start a smaller project and run it to completion on your own, then work on some larger projects and make them work properly. After that, your knowledge of C will hopefully be at such a level that writing the code is the easier part of OS development.

Posted: Mon Oct 22, 2007 4:02 am
by JamesM
Combuster wrote:I tend to agree with brynet-inc - You do not know your language well enough to be programming operating systems.

Kowing the base language for development inside out is a definate requirement. You must know what the compiler does with what code, and have a good idea about the machine code generated by it. That way you can see from the code what the processor should do. Next there's a bit of experience - if you have written a few large projects you know what you can and cannot do with a language. Based on the fact that you have half the top 10 of beginners errors in your code and being unable to see it I can only conclude that this subject is too advanced for you.

I suggest you start a smaller project and run it to completion on your own, then work on some larger projects and make them work properly. After that, your knowledge of C will hopefully be at such a level that writing the code is the easier part of OS development.
I have suggested this to him before. It has been ignored.

Posted: Mon Oct 22, 2007 4:26 am
by Combuster
JamesM wrote:I have suggested this to him before. It has been ignored.
Well then, I hope it helps if more people tell him that this is not the right place.

Posted: Mon Oct 22, 2007 7:10 am
by mohammed
:oops:

Code: Select all

#define ACS_TSS_GATE    0x09
#define max_tasks      1
task();
typedef struct   {       
unsigned long link,
        esp0,
        ss0,
        esp1,
        ss1,
        esp2,
        ss2,
        cr3,
        eip,
        eflags,
        eax,
        ecx,
        edx,
        ebx,
        esp,
        ebp,
        esi,
        edi,
        es,
        cs,
        ss,
        ds,
        fs,
        gs,
        ldtr;
unsigned short  trace,
        io_map_addr;
}__attribute__((packed))TSS;
TSS tss[max_tasks];
initialize_tasks()
{
/*          number  base     limit               type                  granularity */
gdt_set_gate(3       ,  tss[0],    sizeof(TSS),   ACS_TSS_GATE, 0xCF);  /*selector is 0x18*/
gdt_flush();
tss[0].cs = 0x08;
tss[0].eip = (unsigned int)&task;                     
tss[0].eflags = 0x202L;                       
  __asm__ __volatile__("ltr 0x18 \n\t"
                               "jmp  0x18\n\t");

}
task()
{
puts("i am task one!!!\n");
__asm__ __volatile__("iret");
for(;;);
}
easy on me guys i never worked with those low level things in C even if i made a million of projects it won't tell me how to play with the stack !
Edit : a general protection fault exception happened :D

Posted: Mon Oct 22, 2007 7:55 am
by JamesM
Mate, You're not 'playing with the stack'. It's knowing the difference between a global and local allocation that makes us think you don't know what you're doing at all...

Posted: Mon Oct 22, 2007 8:09 am
by Combuster
easy on me guys i never worked with those low level things in C even if i made a million of projects it won't tell me how to play with the stack !
Bull. not allocating global things on the stack is a rule in all projects, not just OSdev

a general protection fault exception happened
Yes and? Many of the useful responses have been given before:
2) You do not switch tasks with LTR. If you are using hardware task switching, you set up a blank TSS for the current task to save its state in to and call LTR on that. You would then have a second TSS for the new task and far jump to the new TSS to initialise it.
Do you have the output of bochsout.txt (or whatever your error log file is called)? That will help no end with trying to debug the problem further.
4) are you doing software or hardware switching? This seems to be a mush of the two (not in a good way).
6) your debugging SUCKS. Have you actually tried to isolate the line that kills your kernel? I assume it's the LTR line but it might not be.
7) The way you ask questions SUCKS. "This is my code, it doesn't work. Why doesn't it work? ?!?!?!!1 fix it 4 mez kthxbai lolz!!!111"
Did you even understand what people have been telling you?
You do not know your language well enough to be programming operating systems.
I can almost guess what message bochs's throwing at you. It is the answer to your problem.

Posted: Mon Oct 22, 2007 12:29 pm
by os64dev
ok, as for a last attempt because i am still feeling sorry for being a bit rude to freevista. Why don't you read the manuals about task switching and tell in words what needs to be done. Then next write some code that implements what you have written down. So is should not resemble this code. Good luck.

There are already a lot of hints in this thread so you should be able to do it.

I will be glad to give comments on what you have done then.

Posted: Wed Apr 23, 2008 6:12 pm
by spektro
Hi.

I have a similar problem. I am using VMWare with grub to boot my system. My assembly code is in AT&T syntax.

I get a general protection fault at the very first time I try to load a blank TSS. The error code is 0x18, which is the TSS selector (TSS_INDEX * sizeof(gdt_entry)). TSS_INDEX = 3

The code:

tss_load:
mov $0x18, %ax
ltr %ax
ret

If I comment out the LTR instruction, the fault doesn't happen.

Any idea?

Posted: Thu Apr 24, 2008 3:54 am
by Combuster
get the intel manuals, look up the LTR function, and check for every call to #GP wether that applies to you (wether by oversight or bug)

Or use bochs, which will just tell you for what reason it GPFs

Posted: Tue Apr 29, 2008 10:24 pm
by spektro
I've found out what was wrong. I wasn't setting the busy flag of the TSS descriptor properly. I didn't noticed before that the TSS descriptor was a little diferent from a normal segment descriptor.

Begginer's mistake. Thanks for the help. :D