OSDev.org

Without more code (or debug output)

your issue could be one of the above answers, it could be an interrupt that fired (with no IDT), or it could just be anything.

At the very least read up on what causes triple faults: http://wiki.osdev.org/Triple_Fault

A triple fault is usually a sign that the exception handler called is faulty, or worse, that the whole exception handling in your system is screwed up. (LDT or GDT issues, bogus pointers or faulty memory mappings are frequent offenders.)

StartOS wrote:The GDT code alone works and doesn't crash anything.
It's the segment reloader.

I think the best course of action would be:
-either to set up a good debugging environment, if you want to figure out how to solve such problems
-or to post the code or at least the compiled binary of your kernel, if you only want to figure out what is wrong in this specific case.

onlyonemac wrote:I bet you're going to say it's got something to do with a .ORG directive. Well guess what? Neither did he give us a .ORG directive nor did he tell us where the code is being loaded, so without that information I can't give him (or you) a better answer.

Hint: Look at his second post.
The code's position is precisely known.

onlyonemac wrote:Take a look at his code before you start trying to "sell" your favourite emulator.

The most likely cause is that he got the GDT or it's loading wrong.
The easiest way to check that is in the Bochs debugger.
Assuming he have the tools to work with floppy images, of course.

So, in the end, it's about setting a functional debugging environment.

kiznit wrote:So did alexfru and I. We listed what the problems could be and suggested using Bochs to sort it out.

Both you and alexfru used way too much jargon for a newbie. One practically had to know the problem oneself before one could understand the explanation.

iansjack wrote:So not really very useful to suggest that we should read the (not provided) code.

At least I did my best with the provided information.

Artlav wrote:Hint: Look at his second post.
The code's position is precisely known.

It is not, unless I have missed something obvious.

onlyonemac wrote:

kiznit wrote:So did alexfru and I. We listed what the problems could be and suggested using Bochs to sort it out.

Both you and alexfru used way too much jargon for a newbie.

Wait, wha?

alexfru wrote: GDTR is wrong (doesn't point to the GDT)
GDT[1] is wrong
Old cs.base ≠ new cs.base, which your subroutine, as written, expects

where's jargon? Or do you think that it is more reasonable to call the above "too much jargon" than for a newbie to actually understand what they're dealing with and what they're writing in the first place?

onlyonemac wrote:At least I did my best with the provided information.

I don't doubt that you did your best.

What I'm saying is that guesses aren't really good answers. The best answer is "debug your code" (and that's also the most useful answer in the long run). It follows from that that it is sensible to use an emulator that provides the best debugging facilities. I'm a great fan of qemu, and I realize that it has a debugger, but for debugging code at an early stage it is not as capable as Bochs. (Actually, my recommendation would have been to look at SimNow, which provides even better low-level debugging, IMO.)

But whatever tools are used the answer to the question is "learn how to debug code", not "it may be this, it may be that, it may be something else altogether".

Sure, a debugger is a useful tool. But you could have also given him some tips about where the problem is most likely to lie, without using the term "cs.base" which makes no sense unless you're already aware that you're supposed to be looking at the base address of the code. Using the ".base" notation is also likely to be confusing if the newbie has come from a C/C++ background where that is used for members of a structure, when there is no structure here. Likewise kiznit said only "2) Your jump offset (reload_CS) is invalid" without explaining in what way it was invalid. As far as the newbie is concerned, he has told the code to jump to the label where the relevant instruction is; he is not likely aware of relative and absolute jumps nor the issues of base addresses. As far as he's concerned, he's just loading this code into some random memory location and executing it, then telling it to jump to a label and not knowing why it doesn't get there. Explaining to him how code is loaded in memory and how labels work is much more helpful than telling him to use a debugger when he does not yet fully appreciate how to debug the issue, as he is not aware of how the code is loaded. Thus I attempted to explain how the code is loaded. That is the issue here. What debugging tools he uses to resolve the issue is his choice, and we may give him some tips or thoughts on what tools are the most useful but that doesn't mean that we should exclude ourselves from helping him to understand what the actual problem is. After all, what's to say that if he saw the memory addresses being referenced in the debugger that he would actually understand what that means and how to fix it anyway.

If the problem was that the jump was to the wrong location then you would expect the faulting address to be that invalid location, not the jump instruction itself. An invalid GDT, as other people were suggesting, would fault at the jump instruction. (Note that I haven't made any suggestions as to the cause of the fault - I prefer to lead people to find their own solution rather than being prescriptive.)

So it's important to be sure exactly where the faulting instruction is, and the nature of the first exception (before the triple fault). Is it an Invalid OpCode or is it a GPF (for example). I think we can be sure that it's not a Page Fault, but there are other possibilities. What's the best way to determine those facts (assuming that we want to base a solution on facts rather than supposition)? That's where I would say that a good debugger is the tool of choice. So back to square one; the first step in resolving this problem is to use a virtual machine with a good debugger. Then, with some facts to work on, it is possible to make some sensible hypotheses and test them.

Another possible issue that I just thought of might be that there is no directive to tell the assembler to use 16-bit or 32-bit code. I'm not sure which assembler you are using or where (if anywhere) you have specified the type of code to generate, but I assume (judging from your few given test results) that your code is 16-bit, and so you probably need an assembler directive to generate 32-bit code just before the label "reload_cs".

onlyonemac wrote:Another possible issue that I just thought of might be that there is no directive to tell the assembler to use 16-bit or 32-bit code. I'm not sure which assembler you are using or where (if anywhere) you have specified the type of code to generate, but I assume (judging from your few given test results) that your code is 16-bit, and so you probably need an assembler directive to generate 32-bit code just before the label "reload_cs".

Haven't you learned anything from this thread yet?

kiznit wrote:Haven't you learned anything from this thread yet?

What the heck is that supposed to mean? I'm supposed to "learn" to stop trying to solve people's problems?

onlyonemac wrote:What the heck is that supposed to mean? I'm supposed to "learn" to stop trying to solve people's problems?

Correct. Help them learn how to solve their own problems instead.

kiznit wrote:Correct. Help them learn how to solve their own problems instead.

And telling them to use a debugger is not going to achieve that. Telling them HOW TO USE a debugger MIGHT, but we can still be more helpful. We have a wiki to beat up the newbies about using the correct tools; we don't need to discourage them on the forums as well. If we want them to actually stick at it, we need to help them solve their problems before they give up. Giving them the aditional problem of having to figure out how to use a debugger is not necessary. I've already given them two suggestions to solve their problem. Once they've tried the obvious (the suggestions that I have given), then we can guide them with setting up a debugger AND EXPLAIN HOW TO USE IT TO SOLVE THIS PROBLEM.

Octocontrabass wrote:Instead of guessing, check the Bochs log. It's pretty good at telling you what you've done wrong, if you know how to read it.

EXACTLY. YOU HAVE TO KNOW HOW TO READ IT. SO TELL THE POOR GUY HOW TO READ IT FOR HELL'S SAKE!!!

onlyonemac wrote:

Octocontrabass wrote:Instead of guessing, check the Bochs log. It's pretty good at telling you what you've done wrong, if you know how to read it.

EXACTLY. YOU HAVE TO KNOW HOW TO READ IT. SO TELL THE POOR GUY HOW TO READ IT FOR HELL'S SAKE!!!

But... We can't... He hasn't posted any Bochs log.

PS: I think your caps lock key is stuck.

onlyonemac wrote:EXACTLY. YOU HAVE TO KNOW HOW TO READ IT. SO TELL THE POOR GUY HOW TO READ IT FOR HELL'S SAKE!!!

ALL CAPS is a bad manner.

Roman wrote:ALL CAPS is a bad manner.

So is refusing to help someone until after they've fumbled around with trying to figure out how to use a debugger that they are not yet experienced enough to understand.

EDIT: Also it's funny that people always say "caps lock is stuck" when it should be "shift is stuck".