Triple page fault in user mode on INT instruction

[Ycep]

Hi!
I hadn't done anything on my OS for about a month, and I recently started working on it again, e.g. I have rewritten the memory manager to optimize it for use with paging, finished the FAT filesystem, and now I'm working on user-mode.
I have made kernel pages and user-mode GDT entries user accessible for now.
I am using a .COM pure binary to test user-mode programs.
MOV instructions and memory accessing through DS segment seems to work without problems, but when the program executes an system call handler, e.g. (INT 0x90), it triple page faults.
I have enabled CPU0 logging in bochsdbg and this is I've found this happens because of 0xFFFFFFFC memory access (page not exists)??

Code: Select all

00017417572d[CPU0  ] interrupt(): vector = 90, TYPE = 4, EXT = 0
00017417572d[CPU0  ] interrupt(): INTERRUPT TO INNER PRIVILEGE
00017417572d[CPU0  ] page walk for address 0x00000000c080000e
00017417572d[CPU0  ] page walk for address 0x00000000fffffffc
00017417572d[CPU0  ] PTE: entry not present
00017417572d[CPU0  ] page fault for address 00000000fffffffc @ 0000000000002019
00017417572d[CPU0  ] exception(0x0e): error_code=0002
00017417572d[CPU0  ] interrupt(): vector = 0e, TYPE = 3, EXT = 1
00017417572d[CPU0  ] interrupt(): INTERRUPT TO INNER PRIVILEGE
00017417572d[CPU0  ] page walk for address 0x00000000fffffffc
00017417572d[CPU0  ] PTE: entry not present
00017417572d[CPU0  ] page fault for address 00000000fffffffc @ 0000000000002017
00017417572d[CPU0  ] exception(0x0e): error_code=0002
00017417572d[CPU0  ] exception(0x08): error_code=0000
00017417572d[CPU0  ] interrupt(): vector = 08, TYPE = 3, EXT = 1
00017417572d[CPU0  ] interrupt(): INTERRUPT TO INNER PRIVILEGE
00017417572d[CPU0  ] page walk for address 0x00000000fffffffc
00017417572d[CPU0  ] PTE: entry not present
00017417572d[CPU0  ] page fault for address 00000000fffffffc @ 0000000000002017
00017417572d[CPU0  ] exception(0x0e): error_code=0002
00017417572i[CPU0  ] CPU is in protected mode (active)
00017417572i[CPU0  ] CS.mode = 32 bit
00017417572i[CPU0  ] SS.mode = 32 bit
00017417572i[CPU0  ] EFER   = 0x00000000
00017417572i[CPU0  ] | EAX=00000000  EBX=00000000  ECX=0000201a  EDX=00000000
00017417572i[CPU0  ] | ESP=00003006  EBP=00003006  ESI=c0100ca0  EDI=00000000
00017417572i[CPU0  ] | IOPL=0 id vip vif ac vm RF nt of df IF tf sf ZF af PF cf
00017417572i[CPU0  ] | SEG sltr(index|ti|rpl)     base    limit G D
00017417572i[CPU0  ] |  CS:0023( 0004| 0|  3) 00000000 ffffffff 1 1
00017417572i[CPU0  ] |  DS:001b( 0003| 0|  3) 00000000 ffffffff 1 1
00017417572i[CPU0  ] |  SS:001b( 0003| 0|  3) 00000000 ffffffff 1 1
00017417572i[CPU0  ] |  ES:001b( 0003| 0|  3) 00000000 ffffffff 1 1
00017417572i[CPU0  ] |  FS:001b( 0003| 0|  3) 00000000 ffffffff 1 1
00017417572i[CPU0  ] |  GS:001b( 0003| 0|  3) 00000000 ffffffff 1 1
00017417572i[CPU0  ] | EIP=00002017 (00002017)
00017417572i[CPU0  ] | CR0=0xe0000011 CR2=0xfffffffc
00017417572i[CPU0  ] | CR3=0x00030000 CR4=0x00000200
00017417572p[CPU0  ] >>PANIC<< exception(): 3rd (14) exception with no resolution

As you can see the first access is the actual interrupt handler address, but then 0xFFFFFFFC? Why?
I'll give any code needed you think where may the bug be.

[Octacone]

Take a look at your segment registers, only CS should be 0x1B and others should be 0x23, if your fourth (0 being the first) GDT entry describes a user mode data segment.

Your OS triple faults because it firstly page faults and then double faults and then triple faults because your ISR handler can’t be executed because you don’t have a valid TSS set up.

If I remember correctly your 0x90th entry needs to have an RPL of 3.

Those are just some general things to look for. I don’t know if that will fix your problem. You still need to find out why it page faults in the first place.

[Ycep]

...

Code: Select all

00017417572i[CPU0  ] | SEG sltr(index|ti|rpl)     base    limit G D
00017417572i[CPU0  ] |  CS:0023( 0004| 0|  3) 00000000 ffffffff 1 1
00017417572i[CPU0  ] |  DS:001b( 0003| 0|  3) 00000000 ffffffff 1 1 <<<<
00017417572i[CPU0  ] |  SS:001b( 0003| 0|  3) 00000000 ffffffff 1 1 <<<<
00017417572i[CPU0  ] |  ES:001b( 0003| 0|  3) 00000000 ffffffff 1 1 <<<<
00017417572i[CPU0  ] |  FS:001b( 0003| 0|  3) 00000000 ffffffff 1 1 <<<<
00017417572i[CPU0  ] |  GS:001b( 0003| 0|  3) 00000000 ffffffff 1 1 <<<<

Read the post before replying.

Those are just some general things to look for.

So what the ****? I'm too dumb to see general things myself?

I don’t know if that will fix your problem. You still need to find out why it page faults in the first place.

Hmmm... Let me see. I post a problem on the forum and somebody comes and replies me with "you need to find out why". It seems like you are just replying and posting on this forum threads just to increment the post counter.

[Ycep]

I just don't understand why does Bochs try to access 0xFFFFFFFC after the actual address before even disassembling the interrupt handler. Maybe bad TLB cache?

[iansjack]

Probably not a good idea to be rude to people who are trying to help, even if their post doesn't solve your problem

I won't risk your sarcasm by suggesting the obvious - that you single-step through your system call to see what is going wrong.

[Octacone]

...rude_post...

Looks like the better you are towards someone, the worse they are towards you.
Keep being rude towards other members (that only want to help and mean no harm) and you will surely get all the love and help you need.
That is a really nice way to make friends / get people to like you.
This is just over the top, you're definitely going to my foes list. Don't want to waste my time talking to people like you.
Sorry for trying to solve your issue.

[Ycep]

Probably not a good idea to be rude to people who are trying to help, even if their post doesn't solve your problem

I was not rude. Actually, I am very aware that you need to be good to people if you want them to help you, and I am always nice to somebody who wants to help. But the difference is that yet he is quite inexperienced and wants to help by giving me "general things to look at". That was rude.

I won't risk your sarcasm by suggesting the obvious -

But I am much more tolerant to the more experienced members of this forum, so I will reply indeed.

that you single-step through your system call to see what is going wrong.

Well it doesn't even reach to the interrupt handler. It triple faults on the INT 0x90 instruction.

[iansjack]

I had posted a suggestion as to what the error pretty obviously is but, because of your attitude, I've now erased that suggestion.

I don't need your attitude.

[Ycep]

As I've already said, I am very nice to everybody who wants to help except if they are rude to me. You (iansjack weren't rude)

I don't understand, what was my attitude to you? Every time you helped me I was quite nice to you. Why this?

Solved.