OSDev.org

The F that you not see is right before the granularity four bits : by example, on the 32-bit entries: 011001111b, the first bit
is 4 Kib granularity, the second is for 32-bit entry, and the two next are reserved, and then cames the other F (1111b) of 0FFFFFh.
And answering back the question that DavidCooper said, i isolated both, the mode switching routines and the rest of the codes:
Separately both works, together no of both works.

Ok, now i have adjusted the code again.
Now i put both RESETEX and SSHOWSTAT routines in protected mode using the same routine as READEXT and WRITEEXT, i mean, only the part about entering and exiting protected mode.
there's my standart entering/exiting routine: And now that i put them inside this routine, the system have started to work.
But now i have a more mysterious error:
The floppy boots up, the kernel starts backuping the disk, while displaying the progress on the screen, and then reboots.
The worst is, it reboots at a random time.
The biggest value i saw in progress line was 190, at other tries i saw 80, 27, 1, 8, 56, 134 etc.
Note that this is the same as the number of loops that calls READEXT, so each number of this is num*63*16 sectors.
And note that this never reached 250 loops, so the only error variables are the READISK thread, Showstat and READEXT routines.
Another thing: this like be assossiate with be number of loops and not with the time, because when i change some IDE configurations to slow down disk acesses the code take more time to reboot.
And the last thing, BIOS interrupts are disabled in the starting of code and are not enabled again, hardware interrupts aren't a problem.

Anyway, thanks by the help

guilherme wrote:The F that you not see is right before the granularity four bits : by example, on the 32-bit entries: 011001111b, the first bit
is 4 Kib granularity, the second is for 32-bit entry, and the two next are reserved, and then cames the other F (1111b) of 0FFFFFh.
And answering back the question that DavidCooper said, i isolated both, the mode switching routines and the rest of the codes:
Separately both works, together no of both works.

Oh yes, 1st bit is granularity? Then what is bit 7? In your code, the granularity is set to 0 which means 1 byte granularity. You are in no way using the full memory.

Cheers!

A few things for you to check. Are you writing your data right through the memory hole that usually (or maybe always) exists between the 15 and 16 megabyte points? If this contains memory mapped ports it could cause strange problems (not to mention the mess it will make of one megabyte's worth of your data), although there must still be some other fault if you're sometimes only getting one run through the loop before a freeze.

Does 63 x 16 x 512 = 7e000h or 7d000h? I make it the latter, and your count in ecx (1f800h) which you use for rep movsd is indeed a quarter of 7d000h. This is trivial and can't be causing the freeze.

Are you sure that your count in cx is preserved every time you call Int 13h?

Perhaps you might also try commenting on your code line by line before you invite people to help you find a bug in it.
What, for example, is the Xor di,di meant to do? (Apart from making di=0, of course - the question is, why does it need to be 0? I shouldn't have through the code to hunt to find out.) What does the rest of the stuff that follows do exactly? How many times can you add a word to OFFBUFF1 before there's a carry? Looks like 8? Then you change the segment to the next block of 64KB. I've not seen this DAP stuff before so wasn't obvious to me what this code did: instead of being able to read a simple explanation in comments I've had to spend time trying to work it all out. It looks as if it's correct, but I could have put that time to better use looking elsewhere if you'd commented on your code properly.

You've clearly also made some progress towards debugging this yourself by displaying on the screen the progress as the code runs. You're the person best placed to improve on this perhaps by displaying the contents of memory at certain points along the way to see if the data really are being loaded in where you expect them to be. You might at some stage want to display the contents of all the registers and variables periodically too, just to see if anything's going wrong. You're clearly a lot more intelligent than most of us gave you credit for before: I'm now confident having read through your code that you are actually up to the task.

Ok (Again...)
Firstly Thanks Davidcooper, and secondly i have to mention
something that i had check:

1: i manually disabled the ISA memory hole

2: IF800h is a qurter of FE000h and not of FD000h

3: I ERROR when i said that bit 1 was granularity, i meant bit 7, and i think that the zero prefix is confusing you. There's a fragment of my post:

by example, on the 32-bit entries: 011001111b, the first bit is 4 Kib granularity...

I meant bit 7, look:

-------[ - GRANULARITY BYTES - | --- LAST LIMIT 4 bits --- ]
prefix| bit 7| bit 6| bit 5| bit 4| bit 3| bit 2| bit 1| bit 0|
- 0 -- | - 1 - | - 1 - | - 0 - | - 0 | - 1 - | - 1 - | - 1 - | - 1 - |


And the DI, is an error counter, and need to be destroyed at each sucesfull operation, using a Xor di,di, and increased at each error. More than 5 errors will force code to skip the current sector and Xor di,di.

Anyway, i have more one test to do, and i'll answer back, i may find the problem now.

guilherme wrote: i think that the zero prefix is confusing you

Now I am one feeling pathetic.That 0 was the root of the misconception.

guilherme wrote:I ERROR when i said that bit 1 was granularity, i meant bit 7

Exactly. That was what I was talking about.

DavidCooper wrote:Perhaps you might also try commenting on your code line by line before you invite people to help you find a bug in it.

Agreed.

DavidCooper wrote:You're clearly a lot more intelligent than most of us gave you credit for before: I'm now confident having read through your code that you are actually up to the task.

Will agree to this as well when he'll run his code under an emulator with debugger and then track down his problem.

Regards,
Chandra

Thanks by your help (Finally an post without starting with Ok...).
Ok (That was too good to be true...), i want to know some things:

Wich is the best emulator for debugging (don't matter the OS)?

And principally:
How an bug associated to the software can crash the code at an random time, if the hardware is always the same?
I tried very many different computers, and tried at least eight BIOS configurations.
I tried different processors, i386, i486, AMDk6-2, AMDK5, AMD Sepron, Pentium I, II and 4, celeron D, i3, i5 and even a octal core xeon (it was an firewall server), and all they, in any configurations that i thought that could make some difference show the same result.
And when i test it with faster hardwares, and faster hard-disks the errors happens faster, so
it like to be associated not to the time, but to the progress of the code.

Obs.: The progress counter never reached 250, so you don't need to care with READEX, ENCODE and the whole tread DISCHARGE, the code only runs inside READISK routine before rebooting
.
Another Obs.: the interrupt flag is cleared in the first instruction of code, and is not enabled again, so hardware interrupts don't matter anymore (and i disabled undesirable hardware IRQ's)

and the last Obs.: I already tried enabling interrupt flags, this didn't make any difference.


THANKS!.

guilherme wrote:How an bug associated to the software can crash the code at an random time, if the hardware is always the same?

Hardware is never the same - clocks tick, harddisks are rotated in different positions, electrolytes are in various states of discharge, cosmic radiation is guaranteed unpredictable. Use an emulator (not a virtual machine or recompiler!) if you want such strict hardware guarantees.

What you are seeing is probably some sort of race condition.

guilherme wrote:And the last thing, BIOS interrupts are disabled in the starting of code and are not enabled again, hardware interrupts aren't a problem.

Doing a at the beginning of your code does not guarantee that interrupts will remain disabled. Some bios calls re-enable interrupts.

I want to know, wich emulator have an real-time debugger?

guilherme wrote:I want to know, wich emulator have an real-time debugger?

What do you mean by 'real-time debugger' ?

i mean an debugger to see the value of the registers and flags when the code is running.

hm, Bochs debugger?

QEMU has a built-in console as well that lets you view some information about registers and memory, accessible by pressing Ctrl + Alt + 2. I would only recommend it if you are unable to use Bochs for some reason, as it can hardly be called a debugger.

Another solution that works with both Bochs and QEMU is compiling your kernel with debugging symbols and then using GDB to debug it. I have had some success with this, although I haven't experimented with it fully yet.

guilherme wrote: 1: i manually disabled the ISA memory hole

I had no idea that it was possible to disable the memory hole. Good work!

2: IF800h is a qurter of FE000h and not of FD000h

I think you're right after all (about it being E rather than D) - I don't use hex normally, and now I can remember why I've always been so keen to avoid it. I do hope my problem with hex isn't contagious, but you've just used F's instead of 7s in the quote above.

I don't know if I'm helping or hindering you, but I'll read through your code again and see if anything jumps out at me. One question though: when the stats are ticking up, do the time gaps appear absolutely regular or is it too fast to judge?