Message board for the users of flat assembler.
> OS Construction > PM32: CPL0 > CPL3 > INT xx !> incorrext
omegicus 16 Jul 2013, 11:31
Can anyone help or any idea about possible bugs (theoretical):
I have 32bit OS in PM32 with GDT: R0C, R0D, R3C, R3D.
When i call R3C code - all works fine, then i call my int 0x27 to put string - all fine. But when i try to int 0x27 for GetChar - it returns incorrect data. When this code works in R0C all ws fine. So problem 100% in Interrupt R0C > Task R3C fragment. TSS correct (becouse in software multitasking R3C > R0C transition works propertly.)
What is the question: have anyone an idea or something to how to INTR must finish itself on Ring0 if it was called from Ring3???
|16 Jul 2013, 11:31||
nop 17 Jul 2013, 05:49
welcome to fasm board omegicus sory i dont know bout pm ring stuf but im sure somebody wil help u soon
|17 Jul 2013, 05:49||
cod3b453 17 Jul 2013, 16:54
When you say "incorrect data" what is incorrect? i.e. which registers or memory regions?
It may be worth looking at the hardware task switching/task management sections in the Intel/AMD system programming manuals, if you haven't already.
|17 Jul 2013, 16:54||
omegicus 17 Jul 2013, 18:28
i mean: in R0 to R0 state i getting IRQ1 (keyboard) key in AL register. all works fine.
But when R0 INT to R3 code: al contains some incorrect data, not key state....
It is not so important question, some way i will do it))), but it's a time.......(((
I thought may be someone have relat. problems... and have an answer...
|17 Jul 2013, 18:28||
baldr 17 Jul 2013, 18:42
It should be guesswork? Show some relevant code/data.
|17 Jul 2013, 18:42||
omegicus 17 Jul 2013, 18:58
mov eax, OM_F_GETC
or al, al
mov bl, al
int27.inc: ; this code get byte from keyboard and put result in AL... in CPL0 -> CPL0 all works fine
IRQ1.inc: ; keyboard handler
PUSH DS ES FS GS
MOV AX, CORE_DS
MOV DS, AX
IN AL, 0x61 ; give finishing information
OUT 0x61, AL ; to keyboard...
POP GS FS ES DS
i don't know what to show... there are lot of code...
while i not turn on Ring3 mode all worked super fine!
Fact1: standart INT works correctly while not needed to return some data to Ring3 back (for example, PrintString via INT works correctly)
Fact2: IRQ0 (Scheduler) works correct anyway: it's switch tasks (Ring0 and Ring3) and working in Ring0 too... all ok.
I have only one idea: maybe INT (R0) must detect from what CPL was interrupt called... and if it was not R0 modify return stack from just EIP/CS/EFLAGS to EIP/CS/EFLAGS/ESP/SS... before IRET call... such as in Scheduler... i'll try this soon and if it IS i'll write about...
|17 Jul 2013, 18:58||
omegicus 18 Jul 2013, 07:11
cool... i understood!
thats was becouse i forot about my mouse driver... it was loaded as mice.exe (such a program resident, it detects mice and install's IRQ12). Becouse I turned on Ring3 -> this code now in Ring3 -> IRQ not in CPL0...
so when i disabled mice.exe loading my code starts working fine.
it's my fault to do something and then modify core... i should have to make Ring3 code and just then make drivers and so....
|18 Jul 2013, 07:11||
< Last Thread | Next Thread >
Copyright © 1999-2023, Tomasz Grysztar. Also on GitHub, YouTube, Twitter.
Website powered by rwasa.