loops...

[eddyb]

yah u'll found the code and the .img here http://neoxos.110mb.com/MyOS.zip

[eddyb]

so:
1)the PIT is setup correctly
2)the time handler is executed at ~ 10 ms
3)when i enter a loop, the time handler isn't executed anymore

*3* Why?

can u test this:this is a zip with .img file
load it.
u will see a simple prompt, and at each 4 seconds, some number will be shown on screen(that mean the timer handler is executed).
type test and press enter.
this enters a loop. if u'll see the numbers that are shown, let me know. if not, u have the same problem like me.

[JamesM]

right.

This is from timer.c:

Code: Select all

int i;
        if(nr_tasks){
        void (*task)(void);
        if(act_task>=nr_tasks-1)
                act_task=0;
        else
                act_task++;
        task = tasks[act_task];^M
        if (task)^M
        {^M
                task();^M
        }
        }

What does it do? Your code which writes a number out to the screen is BENEATH it, so if task(); never returns, that code will never be run.

also, you have duplicate symbols declared in timer.c and timer.s:

You have a function called timer_handler in timer.c. You have a symbol (defined as a function) called _timer_handler in timer.s. You also, more confusingly, have a VARIABLE called act_task in timer.c, but in timer.s you define that as a routine!

What. The. Hell.

[eddyb]

my sorry: only start.s is part of the project, the rest of .s files are generated by compiler(i forgot to delete that files).

AND I'VE SAID A LOT: THAT HANDLER CAN BE RUN INFINITES TIMES BEFORE I ENTER A LOOP(ANY LOOP).

Have u tested it?

[Brendan]

Hi,

Have u tested it?

I tested it, and it did work.

Could you put a loop in there and then upload an image that doesn't work?


Cheers,

Brendan

[jal]

AND I'VE SAID A LOT: THAT HANDLER CAN BE RUN INFINITES TIMES BEFORE I ENTER A LOOP(ANY LOOP).

You know very well that shouting is extremely rude. Do you really expect people to help you like this? Instead I have the urge to tell you to go f**k yourself, you incompetent sorry excuse for a human being. But I'll fight that urge for now.


JAL

[zaleschiemilgabriel]

Don't do that! Look, JamesM tried to help you. He even took a look at your code, which is what you should do more of... Just fix your own damn code! It's harder for other people to figure out what you wrote, so if you expect fast results, try spending more time testing your code than waiting for an answer, please! Maybe James will help you if there really is a problem with the code and/or with his tutorial, but you just have to be patient!

EDIT: That zip file contains a "start.asm" file, but no "start.s" file... Please get your own things straight, learn to be patient.

[eddyb]

Hi,

Have u tested it?

I tested it, and it did work.

Could you put a loop in there and then upload an image that doesn't work?


Cheers,

Brendan

u typed test, pressed enter and that numbers(ticks counter) continue to appear?
At me, don't

[JamesM]

Eddyb: Correct, I did that, and just like your example the numbers stopped appearing.

So, I have *ahem* solved your problem.

This is from part of your keyboard handler code - it calls cmd():

Code: Select all

void keyboard_handler(struct iregs *r)
{
    unsigned char scancode;

...

    if (ch_h == '\n')
    {
      cmd(text_m);

cmd():

Code: Select all

void cmd(char *txt)
{

        switch(get_cmd(txt))
        {
        case 1:
                puts("MyOS is running on this machine");
                break;
        case 2:
                puts("Now we have only 2 cmd:\n sys : Information about system\\
n help : A simple help");
                break;
        case 3:
                settextcolor(0, 0);
                break;
        case 4:
                settextcolor(1, 1);
                break;
        case 5:
                settextcolor(2, 2);
                break;
        case 6:
                settextcolor(3, 3);
                break;
        case 7:
                settextcolor(4, 4);
                break;
        case 8:
                settextcolor(5, 5);
                break;
        case 9:
                settextcolor(6, 6);
                break;
        case 10:
                settextcolor(7, 7);
                break;
        case 11:
                while(1);
                break;
        default:

                puts("UNKNOWN command\nTry help;");
                break;
        }

        puts("\nMyOS>");
}

And then the crux of the matter - how the keyboard IRQ handler is called.:

Code: Select all

void irq_handler(struct iregs *r)^M
{^M
    /* This is a blank function pointer */^M
    void (*handler)(struct iregs *r);^M
^M
    /* Find out if we have a custom handler to run for this^M
    *  IRQ, and then finally, run it */^M
    handler = irq_routines[r->int_no - 32];^M
    if (handler)^M
    {^M
        handler(r);^M
    }/* If the IDT entry that was invoked was greater than 40^M
    *  (meaning IRQ8 - 15), then we need to send an EOI to^M
    *  the slave controller */^M
    if (r->int_no >= 40)^M
    {^M
        outportb(0xA0, 0x20);^M
    }^M
^M
    /* In either case, we need to send an EOI to the master^M
    *  interrupt controller too */^M
    outportb(0x20, 0x20);^M
}

(Ignore the ^M's, they're Emacs borking at MS-DOS style line endings)

Da daaaaa!! *applause*. Your EOI is not delivered until AFTER the handler function returns. And since the handler function goes into an infinite loop, it will never return. To the interrupt is never acknowledged, so no more interrupts will take place.

Myself and several others, Brendan included, told you it was an EOI related problem. But apparently you know best.

[eddyb]

OMG!!! How was so simple...
yah.... i'll implement something that doesn't do this problem

[JamesM]

Don't say thanks at all. It's fine. I don't mind.

[zaleschiemilgabriel]

I was just about to say that there's a problem with your keyboard or mouse handler, but I deleted that post.
Out of curiosity, how much did you really try to find the problem?

[eddyb]

Don't say thanks at all. It's fine. I don't mind.

Sorry, I forgot. thanks a lot!

[Brendan]

Hi,

u typed test, pressed enter and that numbers(ticks counter) continue to appear?
At me, don't

Hehe - I didn't realise I was meant to press keys...

Ok, I got it to lock up.

There's a loop that goes like this:

Code: Select all

0x001002e9: mov edx, dword ptr ss:[esp+0x4]  ; 8b542404
0x001002ed: mov eax, 0x00000000              ; b800000000
0x001002f2: cmp byte ptr ds:[edx], 0x00      ; 803a00
0x001002f5: jz .+0x0000000c                  ; 740c
0x001002f7: mov eax, 0x00000000              ; b800000000
0x001002fc: inc eax                          ; 40
0x001002fd: cmp byte ptr ds:[eax+edx], 0x00  ; 803c1000
0x00100301: jnz .+0xfffffff9                 ; 75f9
0x00100303: ret                              ; c3

This looks a lot like badly written "strlen()" to me. When I stopped it, EDX was 0x6610197C and EAX was 0x00FAD4FE, which means it started searching from a bad pointer and never finds a zero. I guess it would eventually (but it might take weeks).

The return address on the stack is 0x00101819, which means it was called from this code:

Code: Select all

001017f1: push esi                           ; 56
001017f2: push ebx                           ; 53
001017f3: sub esp, 0x0000000c                ; 83ec0c
001017f6: mov ebp, dword ptr ss:[esp+0x20]   ; 8b6c2420
001017fa: mov edi, 0x00000000                ; bf00000000
001017ff: mov esi, dword ptr ds:[edi*4+0x10e130] ; 8b34bd30e11000
00101806: sub esp, 0x0000000c                ; 83ec0c
00101809: push ebp                           ; 55
0010180a: call .+0xffffeada                  ; e8daeaffff
0010180f: mov ebx, eax                       ; 89c3
00101811: mov dword ptr ss:[esp], esi        ; 893424

00101814: call .+0xffffead0                  ; e8d0eaffff    HERE!

00101819: add esp, 0x00000010                ; 83c410
0010181c: cmp ebx, eax                       ; 39c3
0010181e: jnz .+0x00000032                   ; 7532
00101820: sub esp, 0x0000000c                ; 83ec0c
00101823: push ebp                           ; 55
00101824: call .+0xffffeac0                  ; e8c0eaffff
00101829: mov ecx, eax                       ; 89c1
0010182b: add esp, 0x00000010                ; 83c410

I don't have a decent disassembly or anything, but this looks like "if(strlen(ch1) == strlen(ch2))" to me (from the file "cmd.c"), which might mean that "void cmd(char *txt)" is being called with a dodgy pointer.

Then I took a look at "kb.c" (which contains code to call "cmd()"). I stopped looking when I saw this:

Code: Select all

/* Handles the keyboard interrupt */
char text_m[] = "";


void keyboard_handler(struct iregs *r)
{
    unsigned char scancode;

    /* Read from the keyboard's data buffer */
    scancode = inportb(0x60);

    /* If the top bit of the byte we read from the keyboard is
    *  set, that means that a key has just been released */
    if (scancode & 0x80)
    {
        /* You can use this one to see if the user released the
        *  shift, alt, or control keys... */
    }
    else
    {
        /* Here, a key was just pressed. Please note that if you
        *  hold a key down, you will get repeated key press
        *  interrupts. */

        /* Just to show you how this works, we simply translate
        *  the keyboard scancode into an ASCII value, and then
        *  display it to the screen. You can get creative and
        *  use some flags to see if a shift is pressed and use a
        *  different layout, or you can add another 128 entries
        *  to the above layout to correspond to 'shift' being
        *  held. If shift is held using the larger lookup table,
        *  you would add 128 to the scancode when you look for it */
		char ch_h;

		ch_h = kbdus[scancode];
        putch(ch_h);


		if (ch_h == '\n')
		{
			cmd(text_m);
			memset(text_m, 0, strlen(text_m));


		}
		else
		{
			text_m[strlen(text_m)] = ch_h;

		}
    }
}

The first line ("char text_m[] = "";") tells the compiler to reserve 1 byte for an empty string. The rest of the code uses a pointer to this empty string to trash everything in memory while you type.

My theory is that a pointer to some sort of string was overwritten by keypresses, eventually causing "strlen()" to search from a random address looking for a zero that doesn't exist.


Cheers,

Brendan

[JamesM]

Too late, Brendan! Fixxored already!