problem while testing on real hardware

Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
asdfgh
Member
Member
Posts: 42
Joined: Fri Apr 18, 2008 9:14 pm

problem while testing on real hardware

Post by asdfgh »

hi i have a os which works well in bochs and qemu evn in qemu 64 bit ...
but when i chk it on real system the screen freezes aftr loading grub what might be the reason ..

it worked well on pentium celeron procesor but whn i try it on newer processors i jus hangs !!!

i changed the text display mode is it due to it or i dont initialise apic ..
is any of this the reason and i dont change any intel reserved bits !!
User avatar
gzaloprgm
Member
Member
Posts: 141
Joined: Sun Sep 23, 2007 4:53 pm
Location: Buenos Aires, Argentina
Contact:

Re: problem while testing on real hardware

Post by gzaloprgm »

Some emulators tend to memset all memory to zeros. If your code does assumes some variable is in zero without actually setting it, some problem might happen.

Try using -Wall in the compiler line to check if you'r doing something weird with pointers.

Cheers,
Gonzalo
Visit https://gzalo.com : my web site with electronic circuits, articles, schematics, pcb, calculators, and other things related to electronics.
jal
Member
Member
Posts: 1385
Joined: Wed Oct 31, 2007 9:09 am

Re: problem while testing on real hardware

Post by jal »

asdfgh wrote:the screen freezes aftr loading grub
Do you mean that it is grub that freezes after loading, or do you mean that, after grub has loaded your OS and presumably calls it, it's your OS that's freezing?

I'm assuming the latter, in which case you should try to (yes really) debug it.


JAL
asdfgh
Member
Member
Posts: 42
Joined: Fri Apr 18, 2008 9:14 pm

Re: problem while testing on real hardware

Post by asdfgh »

i did debuggin.. thr is no problem whn executing in emulator it works fine..
but whn testing on hardware that too 64bit hardware. newer processors it hangs and it is the os tat hangs aftr the grub loads it.

any idea on why it happens ?
User avatar
gzaloprgm
Member
Member
Posts: 141
Joined: Sun Sep 23, 2007 4:53 pm
Location: Buenos Aires, Argentina
Contact:

Re: problem while testing on real hardware

Post by gzaloprgm »

but whn testing on hardware that too 64bit hardware. newer processors it hangs and it is the os tat hangs aftr the grub loads it.
Try removing everything in main() and checking if GRUB loaded your kernel ok by drawing something on screen.

The fact that a processor is 64 bits does not mean anything if you don't switch to long mode (64 bit).

Cheers,
Gonzalo
Visit https://gzalo.com : my web site with electronic circuits, articles, schematics, pcb, calculators, and other things related to electronics.
System123
Member
Member
Posts: 196
Joined: Mon Jul 07, 2008 1:25 am

Re: problem while testing on real hardware

Post by System123 »

I had the same problem. The way I solved it was to mask out all the IRQs I was not using. ie: 3-5 and 7-15. The problem is actually IRQ 7 which is the LPT port IRQ. If there is no LPT driver in your OS then this IRQ fires repeatedly and keeps the CPU from doing anything else. The problem does not occur on an emulator though.
Gizmic OS
Currently - Busy with FAT12 driver and VFS
jal
Member
Member
Posts: 1385
Joined: Wed Oct 31, 2007 9:09 am

Re: problem while testing on real hardware

Post by jal »

System123 wrote:The problem is actually IRQ 7 which is the LPT port IRQ. If there is no LPT driver in your OS then this IRQ fires repeatedly and keeps the CPU from doing anything else. The problem does not occur on an emulator though.
Yes, IRQ 7 used to be the LPT IRQ. However, on modern systems it is also the infamous 'spurious interrupt', which afaik gets fired when you don't handle other interrupts.


JAL
jal
Member
Member
Posts: 1385
Joined: Wed Oct 31, 2007 9:09 am

Re: problem while testing on real hardware

Post by jal »

asdfgh wrote:i did debuggin.. thr is no problem whn executing in emulator it works fine..
but whn testing on hardware that too 64bit hardware. newer processors it hangs and it is the os tat hangs aftr the grub loads it.
So you did not do proper debugging, as otherwise you would have found at what statement your OS hangs. Also, check your 'e' key, since it is repeatedly missing in your typing.
any idea on why it happens ?
Yes, your code is buggy.


JAL
User avatar
gzaloprgm
Member
Member
Posts: 141
Joined: Sun Sep 23, 2007 4:53 pm
Location: Buenos Aires, Argentina
Contact:

Re: problem while testing on real hardware

Post by gzaloprgm »

Also, check your 'e' key, since it is repeatedly missing in your typing.
=D>

I think you should really map every irq to a dummy isr to avoid this spurious interrupts!

Cheers,
Gonzalo
Visit https://gzalo.com : my web site with electronic circuits, articles, schematics, pcb, calculators, and other things related to electronics.
System123
Member
Member
Posts: 196
Joined: Mon Jul 07, 2008 1:25 am

Re: problem while testing on real hardware

Post by System123 »

gzaloprgm wrote:I think you should really map every irq to a dummy isr to avoid this spurious interrupts!
Remapping every IRQ to a dummy isr does not solve the problem. All my IRQs had ISR functions. You HAVE TO Mask the IRQ.

EDIT//

The easiest way to see if it is this IRQ is add a function to your ISR handler to pront the interrupt number to the screen of the interrupt that just fired. If this Int number corresponds to IRQ 7 then you have found the problem.
Gizmic OS
Currently - Busy with FAT12 driver and VFS
jal
Member
Member
Posts: 1385
Joined: Wed Oct 31, 2007 9:09 am

Re: problem while testing on real hardware

Post by jal »

System123 wrote:Remapping every IRQ to a dummy isr does not solve the problem. All my IRQs had ISR functions. You HAVE TO Mask the IRQ.
The IRQ7 thing can afaik be triggered by not handling interrupts quick enough. However, even if you have an ISR in place, if it is a piece of hardware causing the interrupt, it will still issue the interrupt until you have told the hardware to no longer issue it.


JAL
asdfgh
Member
Member
Posts: 42
Joined: Fri Apr 18, 2008 9:14 pm

Re: problem while testing on real hardware

Post by asdfgh »

jal wrote:So you did not do proper debugging, as otherwise you would have found at what statement your OS hangs. typing.
there was no problem while executing in bochs and the os hangs while booting in multicore systems.

will the os not execute in dual core processors??
System123
Member
Member
Posts: 196
Joined: Mon Jul 07, 2008 1:25 am

Re: problem while testing on real hardware

Post by System123 »

asdfgh wrote:will the os not execute in dual core processors??
No, AFAIK this OS will hang on all systems. You have to stop the spurious interrupt in order to free the CPU time. Just mask the IRQ 7 and all your problems will go. If you don't know how to mask interrupts here is the code.

Code: Select all


procedure UnMaskIRQ(IRQNo : byte);
var
IMR : byte;
begin
if IRQNo <= 7 then
  begin
     IMR := ReadPort($21);
     asm
     mov ecx, IRQNo
     and ecx, 7
     mov eax, 1
     shl eax, cl
     xor al, $FF
     xor ecx, ecx
     mov ecx, eax
     mov al, IMR
     and al, cl
     mov IMR, al
     end;
     WritePort($21,IMR);
  end
else

if (IRQNo > 7) and (IRQNo <= 15) then
  begin
     IMR := ReadPort($A1);
     asm
     mov ecx, IRQNo
     and ecx, 7
     mov eax, 1
     shl eax, cl
     xor al, $FF
     xor ecx, ecx
     mov ecx, eax
     mov al, IMR
     and al, cl
     mov IMR, al
     end;
     WritePort($A1,IMR);
  end;
end;

procedure MaskIRQ(IRQNo : byte);
var
IMR : byte;
begin
if IRQNo <= 7 then
  begin
     IMR := ReadPort($21);
     asm
     mov ecx, IRQNo
     and ecx, 7
     mov eax, 1
     shl eax, cl
     xor ecx, ecx
     mov ecx, eax
     mov al, IMR
     or al, cl
     mov IMR, al
     end;
     WritePort($21,IMR);
  end
else

if (IRQNo > 7) and (IRQNo <= 15) then
  begin
     IMR := ReadPort($A1);
     asm
     mov ecx, IRQNo
     and ecx, 7
     mov eax, 1
     shl eax, cl
     xor ecx, ecx
     mov ecx, eax
     mov al, IMR
     or al, cl
     mov IMR, al
     end;
     WritePort($A1,IMR);
  end; 
end;

Try the code and let us know if it helps.

Regard
System123
Gizmic OS
Currently - Busy with FAT12 driver and VFS
asdfgh
Member
Member
Posts: 42
Joined: Fri Apr 18, 2008 9:14 pm

Re: problem while testing on real hardware

Post by asdfgh »

System123 wrote:No, AFAIK this OS will hang on all systems
but even without masking the irq7 it executes on celeron and other pentium 3 processors properly.
User avatar
kmtdk
Member
Member
Posts: 263
Joined: Sat May 17, 2008 4:05 am
Location: Cyperspace, Denmark
Contact:

Re: problem while testing on real hardware

Post by kmtdk »

well
teorical it is supossed to "hang" on every system.
However it can be because of the BIOS.
But A way to test it, would be to mask all interupts,
make them print on the screen ( witch one) and then hlt the system)[ But not with the IRQ 1, bacuse it hits many time.]

then you might can see what INterupt is causing the problem.

And just to mention it:
some interupts Pushes data onto the stack. REmember to pop that data back ...( or else the stack gets "killed")


KMT dk
well, what to say, to much to do in too little space.
when it goes up hill, increase work, when it goes straight, test yourself but when going down, slow down.
Post Reply