[SOLVED] Can't get any hardware IRQ

[amonte]

Okay guys !

On a scale of 1 to 10, how happy are you with that explanation?

I'm not happy with that explanation because there's no explanation.

Diff the two source code versions of the working and non-working systems.

As iansjack said, I don't have my code under version control because these are my first steps into OS development, and for the moment I just want a simple, neat code, not obfuscated by a complicated version structure. So I can't diff the codes before and after the issue disappeared.

My suspicion would be that there might have been some corruption in the original source file that was corrected by retyping the line; impossible to prove now I suspect.

I think you got it : before re-typing this line, I saw that I forgot to re-enable interrupts at the end of my ISR and IRQ routines. So I changed that, compiled, and ran the kernel, but the issue were still here.
I changed some little things in my c headers, I was declaring packed structs as

Code: Select all

typedef struct { ... } __attribute__((packed)) mystruct;

instead of

Code: Select all

struct { ... } __attribute__((packed)) mystruct; typedef mystruct mystruct_t; 

.
Compile&run, no changes...
But before compiling, I haven't removed all the *.o junk in my compile directory, so I think my makefile doesn't re-compiled my isr.s & irq.s files, in which the error was.
By changing the now famous line, I told to make that my .o files were not up to date, so it worked...

So, if I do a quick summary of the possible causes of the problem :

• 1°) My makefile did not compiled my crucial changes (the forgot "sti")
  2°) There was some junk in my memory the page fault cleaned
  3°) That was a fail by my computer or by qemu

[bwat]

The important question is, will you make any changes to the way you go about writing software now?

[amonte]

I think I will (when I'll start writing a "real" kernel) :
1) put it under version control
2) use a reliable build system (i.e. better unix makefiles, cmake, ...)
3) manage to get a good debugging system (i.e. qemu-gdb connection, ...)
I still have a lot of things to learn in such low-level development, but it makes me learning things that i'll use for sure in all my higher-level programming stuff, and also in the programming of u-controllers.
Thanks to everyone that have participated in this useful, yet a little bit philosophic topic.

alex

[Gigasoft]

manage to get a good debugging system (i.e. qemu-gdb connection, ...)

I think you are contradicting yourself here.