strange reboot

[bubach]

i was adding a 720 bytes hardcoded buffer (no mm yet) for saving a bit of the screen.
at first i discovered that i did not load more then 17 sectors correct so adding the buffer made my os crash.
but with the loading fixed my os reboots when the jump to kernel is done.
i get no error messages, it simply reboots.
the things i have added is as i said a buffer and code to save/restore screen content to/from that buffer.
without it, everything is working fine.
the strange thing is that i never call the code! it just lies there, and somehow makes the computer to reboot.... >:(

any idea at all, what might be wrong?

/ Christoffer

[Curufir]

Well the big piece of information we need to know is the address of this buffer.

Some things that might be happening.

You're still in real mode, haven't turned on the A20 line and trash the IVT by writing above 1Mb, first timer interrupt kills the system.

When you load your code that extra 720 bytes overwrites your kernel loading code, after the final sector read everything screws up.

When you fixed your loading code you made an error and are now overwriting the start of the kernel, so instead of jumping into the kernel you jump into the buffer.

Basically it sounds like you've trashed some existing code that is being called by something. You haven't given a huge amount of information to go on though.

[bubach]

hmm.. thats 'cuz i don?t have that much info..
i am in pmode (a20, gdt, idt etc. is ok), kernel loads fine without the buffer.
i make the buffer with "times (720) db 0" (i think it is), and i can see that the kernel image has grown 720 bytes in size, so i am not overwriting something.

and overcourse it is a bit hard to debug, when the damn thing reboots all the time. i have done "jmp $" up until it jumps to kernel in the bootsector...
and the it can?t be the code that actually uses the buffer since it is not called anywhere.

[distantvoices]

bubach, can you by any chance use bochs in debug mode?

what, if those 720 bytes overwrite something crucial and you just don't know?

overcourse --- I think, you wanna say of course, or am I wrong? *dg*

[bubach]

opps, spelling....
i firmly belives that bochs debugger is a curse put on poor os developers, no normal person can get any usefull information out of that hell-creature.
no offence to all mega-tokkians that actually uses it..

if it by any chance do overwrite something, it should be the things that come after the buffer, right? and that is only debug functions, which i dont use..

[Curufir]

I'd still guess the problem is likely to be in the loader code somewhere. Try bringing the code back below 17 sectors (Just comment out some strings or something) and see if it reboots. I've got this strange feeling the start of the kernel is being overwritten when you read that final sector.

[Candy]

opps, spelling....
i firmly belives that bochs debugger is a curse put on poor os developers, no normal person can get any usefull information out of that hell-creature.
no offence to all mega-tokkians that actually uses it..

if it by any chance do overwrite something, it should be the things that come after the buffer, right? and that is only debug functions, which i dont use..

Now that's the third time somebody called my personal favorite and main object for given purpose a hell-creature, abomination or such. The other two were Basic and Emacs. (typical: all have 5-char names).

bochs debugging can be used to determine the ground movements anything is doing. Using logic you can translate all these movements to upper layer movements through your program, and through human interpretation you can convert these changes into the problem in the code. You can instantly inspect any memory-bound object for correctness, you're not limited by one memory plane and you can examine page tables. You can let it run step-by-step to get to the next instruction etc.

There are some limitations, but the Bochs debugger is one of the very few tools for lowlevel OS debugging. As such, I'm grateful that it exists.

[Pype.Clicker]

A normal person would not code an OS, would he ?

a printed copy of http://bochs.sourceforge.net/doc/docboo ... ugger.html will of course help ... my favourite commands are

x /nuf addr Examine memory at linear address addr
dump_cpu
trace-on

Now, that being said, that's the kind of tool i only use when completely desesperated and when any other debuggin technique has failed.

[dh]

bochs has a debugger? well well well.

[ASHLEY4]

I had the same problem as you bubach, if you put some inc files to move address up, that are basically packers, it will work as normal.

NOTE: I am not saying this is a cure, but just try it to see if its the same, like everone is saying you are over run some thing or you offset is wrong or alignment.
The trouble is i can not remember how i fixed it

\\\\||////
(@@)
ASHLEY4.

Batteries not included, Some assembly required.

[bubach]

i?ll try it some more after i had my re-exam in physics tomorrow..

as i said, no offence to the people that do use the debugger, but i think that it wasn?t made for human use at all. the testing i?ve done, gives me not a clue on how to help me out in my development. and the source it steps throught doesn?t look like mine at all, not even the last lines that was exec. before chrashes..

[AR]

Are you creating the buffer in .data or .text? It really shouldn't make any difference but you could try moving it into the data segment if it isn't already.

Bochs only displays the actual disassembly for what it's running, if you compile some code in NASM and do a step by step through it, it should be identical.

You have to use the debugger not the main program, the main program is merely an emulator for running a "bug-free" OS' like Linux/Windows, the debugger should be in the precompiled binary pack or you can compile it as a debugger manually. Bochs is very useful if you know what to do with the error reports, it states whats gone wrong (Although the error can be quite cryptic at times) and then dumps the contents of the registers, a quick check of EIP and the linkmap from LD shows which function the error occured in making it relatively simple to fix as opposed to booting on real hardware where it'll just tripple fault and that's that. The ability to simply freeze the OS and query arbitrary memory locations, see dirty page tables and dump the last 16 items on the stack at any stage of execution can make bug fixing much quicker.

On the note that "it wasn?t made for human use at all", I found it extremely frustrating to start with but you get use to it quickly, just type 'help' in the debugger then query individual commands using 'help "x"', the main commands I find indispensable are pb (Physical Breakpoint), trace-on (prints each instruction), x (Query memory at any location) and dump_cpu (contents of every register). When messing with the GDT/IDT, 'info gdt'/'info idt' prints a useful list of the descriptors and what their settings are, 'info tss' for the current task descriptor, etc, etc.

[bubach]

Bochs only displays the actual disassembly for what it's running, if you compile some code in NASM and do a step by step through it, it should be identical.

my os is in pure fasm, but the few times i tested the debuger (and yes, i use the special bochsdbg.exe) the code looks nothing like mine. and it takes ages of (was it step/i ?) to get to the actuall bootsector (as i dont know how to get there in any other way).... eh, screw it. i can live without it as i code in asm, which makes it easyer to debug just watching the code, then i c.

i just had my re-exam, and atleast this time it didn?t feel like i was a complete idiot, so maybe i have a 50% change of passing..

i?ll be back for more info later, when i have tested some more.

/ Christoffer

[AR]

Try:
pb 0x7c00
c
Then step through it

In a loop if you don't want to step the whole loop then just step to the actual "LOOP" instruction, place a breakpoint on the other side and do a continue.
http://bochs.sourceforge.net/doc/docboo ... ugger.html

I would assume the reason the code doesn't match would be FASM is an optimising assembler? NASM is pretty much what you see is what you get.

[bubach]

opps, i tested with my old bootloader and it worked fine, so apperently it didn?t load past the 17 first sectors.. >:(