IDT trouble ... and I'm not seeing it.

[Candy]

Hi all,

I've picked up the OS kernel again and I've gotten to the point that the kernel is being loaded. The first thing I do though - "int 0x30" - triple faults it immediately. Thing is, I have no idea why.

I've disabled the TSS and set the IST selector to 0, double-checked all fields and I think it is correctly formatted. IDTR has valid and sensible contents... The actual contents:

Code: Select all

idtr:base=0xfffffa0000004000, limit=0xfff

0xfffffa0000004300 <bogus+       0>:	0x3d	0x93	0x08	0x00	0x00	0x8e	0x00	0x00
0xfffffa0000004308 <bogus+       8>:	0x00	0xf8	0xff	0xff	0x00	0x00	0x00	0x00

Any ideas what I'm missing? Running in 64-bit long mode with higher-half kernel...

[Combuster]

Since you seem to be using Bochs, do you happen to have the actual crashlog?

[Candy]

No, but I do now have the bug. The CS descriptor referenced wasn't properly marked as being long-mode only code (in part because nothing ever uses it - well, this does!). As a reminder for future visitors, L flag must be set and D flag may not be set.

[Candy]

Bochs says:

Code: Select all

00012538698e[CPU0  ] interrupt(long mode): must be 64 bit segment
00012538698e[CPU0  ] interrupt(long mode): must be 64 bit segment
00012538698e[CPU0  ] interrupt(long mode): must be 64 bit segment
00012538698i[CPU0  ] CPU is in long mode (active)
00012538698i[CPU0  ] CS.mode = 64 bit
00012538698i[CPU0  ] SS.mode = 64 bit
00012538698i[CPU0  ] EFER   = 0x00000501
00012538698i[CPU0  ] | RAX=fffff80000009275  RBX=0000000000020000
00012538698i[CPU0  ] | RCX=fffffa0000001340  RDX=0000000000000000
00012538698i[CPU0  ] | RSP=0000000000007bc0  RBP=0000000000100000
00012538698i[CPU0  ] | RSI=fffffa0000000340  RDI=0000000000000000
00012538698i[CPU0  ] |  R8=0000000000000050   R9=0000000000000000
00012538698i[CPU0  ] | R10=fffffa0000004dd0  R11=00000000ffffffff
00012538698i[CPU0  ] | R12=0000000000000000  R13=0000000000017b6f
00012538698i[CPU0  ] | R14=0000000000000000  R15=0000000000000000
00012538698i[CPU0  ] | IOPL=0 id vip vif ac vm RF nt of df if tf sf zf AF pf cf
00012538698i[CPU0  ] | SEG sltr(index|ti|rpl)     base    limit G D
00012538698i[CPU0  ] |  CS:0008( 0001| 0|  0) 00000000 00000000 0 0
00012538698i[CPU0  ] |  DS:0000( 0001| 0|  0) 00000000 ffffffff 1 1
00012538698i[CPU0  ] |  SS:0000( 0005| 0|  0) 00000000 0000ffff 0 0
00012538698i[CPU0  ] |  ES:0000( 0001| 0|  0) 00000000 ffffffff 1 1
00012538698i[CPU0  ] |  FS:0018( 0003| 0|  0) 00000000 00000000 0 0
00012538698i[CPU0  ] |  GS:0018( 0003| 0|  0) 00000000 00000000 0 0
00012538698i[CPU0  ] |  MSR_FS_BASE:0000000000000000
00012538698i[CPU0  ] |  MSR_GS_BASE:0000000000000000
00012538698i[CPU0  ] | RIP=fffff80000009275 (fffff80000009275)
00012538698i[CPU0  ] | CR0=0xe0000011 CR2=0x0000000000000000
00012538698i[CPU0  ] | CR3=0x00001000 CR4=0x00000020
00012538698p[CPU0  ] >>PANIC<< exception(): 3rd (13) exception with no resolution

which is not awfully helpful, albeit technically correct.

[Bender]

Hmm, not sure if this could help but check this out: http://bochs.sourceforge.net/cgi-bin/lx ... ception.cc -- Line 125. That should probably give the reason why you get that message, and it exits with a #GP as given by the lines:

Code: Select all

128>> exception(BX_GP_EXCEPTION, cs_selector.value & 0xfffc);

The bochs log says something similar.