OSDev.org

Really odd problem.....IDK if it's something that can be solved without code or not, IDK what part of my code to show, etc. so I'm just going to hope this is a general-case problem.

When I run my kernal in Bochs, it's fine and dandy. On my real PC, though, it get's a Stack Fault. I've checked for un-initialized stuff, I've got everything in lower 1mb (so a20 Shouldn't be problem) , and my bootloader has been tested and works on the real pc before.

Checked the Bochs troubleshooting list in the FAQ? In my experience, Bochs zero-initializing memory is a real pain in debugging. I tend to set key memory locations to bogus values ("0xdead 0xbeef 0xdeaf 0x1234" etc. ), and check that my assumptions are correct at every other corner of my code, wrapped in [tt]#ifndef NDEBUG[/tt]...

Yes, I have. I guess it's remove-til-it-works debuging....

Hmmm...It only occurs after interrupts are enabled. It seems as if (correct me if I'm wrong) the IRQs for some reason aren't remapped, and IRQ2 (what the heck is that one anyway?) is firing causing a 'fake' exception.

It'll probably be easier to debug with that stray push messing the stack up gone.....

IRQ2 is the chained exception - it is what the slave PIC uses to tell the master PIC there is an exception. The CPU should never receive this interrupt.

However, stack fault is interrupt 12 - and IRQ 2 would by default be mapped to interrupt 10, which is the TSS fault (all numbers decimal), so what might be triggering is IRQ 4. IRQ 4 is COM1's interrupt. If you do stuff with COM1, or if the BIOS enables it by default (which I highly doubt), this could be IRQ4 being interpreted as a stack fault.

On the other hand, this could really be a stack fault. However, unless you are working in CPL 3 or have a task gate for the stack fault, a real stack fault would result in a triple fault - because the interrupt pushes stuff on the stack - so if the stack was bad, it couldn't push stuff on to it.

The stack fault occurs (for real) if a limit violation is detected (I.E. the GDT entry is not set to the proper length - check the G bit) or a not-present segment is in the SS register. Both of those are rare, and with the reason above I think it is a hardware IRQ causing this.

Sorry for the long-winded reply, but I hope it helps.

Mike

Ya, I noticed it was COM about 18 hours ago, still working on it .

Well considering I also have a function that the exception handler that calls to double-check some values and i total it pushes about 100 bytes AFTER the exception is called, I'm rather sure that the stack is fine, yet if I ignore it it goes into a crazy loop until something crazy happens and it starts sending out invalid opcode exceptions, bochs gets a 'running in bogus memory' If I return from a divide by 0, IDK what causes that.

I've also tried sending the code to disable all but IRQ's 0 and 1, (keyboard+PIT) so I don't see how IRQ4 could be firing......

Ahh, finally got it! It was the GDT - I killed it and reset it after entering kernel and it worked.

Thanks Mike!