Page 1 of 1

"prefetch: RIP > CS.limit"....huh?

Posted: Tue Jun 21, 2005 2:12 pm
by Jubbens
Bochs still dislikes my project. It gives me this message immediatly on boot. Can someone translate it for me? Thanks.

[CPU0 ] >>PANIC<< prefetch: RIP > CS.limit

Re:"prefetch: RIP > CS.limit"....huh?

Posted: Tue Jun 21, 2005 2:23 pm
by oswizard
We need more information.

Generally, this message means that the requested EIP (RIP on x64) is out of bounds for the code segment limit. The only way, AFAIK, you can get this error is if your GDT is corrupted. In real mode, segments just wrap around, so this must have occurred in protected mode.

Please post more information, such as (at least) the register dump at the end of the bochs log, your GDT code, etc. and maybe then someone can help you better.

Mike

Re:"prefetch: RIP > CS.limit"....huh?

Posted: Tue Jun 21, 2005 2:26 pm
by Jubbens
Sorry for the lack of information.

Actually this DID occur in real mode. No GDT. Here's the dump from bochs:

00002493031i[CPU0 ] real mode
00002493031i[CPU0 ] CS.d_b = 16 bit
00002493031i[CPU0 ] SS.d_b = 16 bit
00002493031i[CPU0 ] | EAX=0fff1000 EBX=00000000 ECX=000e0102 EDX=00000100
00002493031i[CPU0 ] | ESP=0000fffe EBP=00000000 ESI=0000a030 EDI=0000ffdf
00002493031i[CPU0 ] | IOPL=0 NV UP DI PL ZR NA PE NC
00002493031i[CPU0 ] | SEG selector base limit G D
00002493031i[CPU0 ] | SEG sltr(index|ti|rpl) base limit G D
00002493031i[CPU0 ] | CS:1000( 0000| 0| 0) 00010000 0000ffff 0 0
00002493031i[CPU0 ] | DS:1000( 0000| 0| 0) 00010000 0000ffff 0 0
00002493031i[CPU0 ] | SS:0000( 0000| 0| 0) 00000000 0000ffff 0 0
00002493031i[CPU0 ] | ES:1000( 0000| 0| 0) 00010000 0000ffff 0 0
00002493031i[CPU0 ] | FS:0000( 0000| 0| 0) 00000000 0000ffff 0 0
00002493031i[CPU0 ] | GS:0000( 0000| 0| 0) 00000000 0000ffff 0 0
00002493031i[CPU0 ] | EIP=00010000 (00010000)
00002493031i[CPU0 ] | CR0=0x00000010 CR1=0 CR2=0x00000000
00002493031i[CPU0 ] | CR3=0x00000000 CR4=0x00000000

Re:"prefetch: RIP > CS.limit"....huh?

Posted: Tue Jun 21, 2005 2:32 pm
by oswizard
Odd... Well I guess that proves me wrong!

Your IP address (not to be confused with IP address ;) ) is too big for real mode (0x00010000) but I thought that it should just wrap around to 0x0000...

When does this happen? In your bootloader? Try placing "jmp $" instructions (jump in an infinite loop) in front of any suspicious jumps, calls, etc. and see if bochs hangs, instead of crashing. Also verify that the ORG (if this is a flat binary) is set correctly - that seems to be a common problem for users on this forum.

Mike

Re:"prefetch: RIP > CS.limit"....huh?

Posted: Tue Jun 21, 2005 4:14 pm
by Jubbens
I've isolated this error down to my code for setting up the stack. I'm just putting it in low memory, but this area should be unpopulated. But I suppose this is the problem anyway? I put it at 32kb, and this solved the error.

Code: Select all

 cli
 mov ax,0x0000
 mov ss,ax
 mov sp,0x0500
 sti

Re:"prefetch: RIP > CS.limit"....huh?

Posted: Tue Jun 21, 2005 4:26 pm
by AxelDominatoR
You set the stack to 0x500. From 0x0 to 0x500 there are interrupt tables and other things. Stack grows from top to bottom ( so 0x4FF, 0x4FE and so on... ) and you're overwriting important data, probably.

I usually use 0xFDFC for stack start

Axel

Re:"prefetch: RIP > CS.limit"....huh?

Posted: Wed Jun 22, 2005 2:16 am
by slash
I think your DS and ES registers are not set correctly.
Try this

Code: Select all

cli
mov ax,0x7c0
mov ds,ax
mov ax,0x0
mov es,ax
mov ss,ax
mov sp,0x500
sti

Re:"prefetch: RIP > CS.limit"....huh?

Posted: Sun Jun 26, 2005 12:17 pm
by mystran
Doesn't the realmode wrap-around only happen when the A20-gate is disabled? Since the segment descriptors point beyond the 1MB mark, I'd assume the A20 has been enabled, in which case you shouldn't get any wrap-around anymore (AFAIK).

Re:"prefetch: RIP > CS.limit"....huh?

Posted: Tue Jun 28, 2005 12:51 am
by srg
mystran wrote: Doesn't the realmode wrap-around only happen when the A20-gate is disabled? Since the segment descriptors point beyond the 1MB mark, I'd assume the A20 has been enabled, in which case you shouldn't get any wrap-around anymore (AFAIK).
When you get to offset FFFF on a real mode segment and add 1, it wraps arroudnd to 0000. The A20 gate is there because of some old dos programs that rely on a wrap arround at 1MB, a 286 and later, in real mode will allow you a 64K segment that starts at 1MB, so the gate restricts the address space.

srg

Re:"prefetch: RIP > CS.limit"....huh?

Posted: Tue Jun 28, 2005 2:44 am
by Pype.Clicker
actually, what you say about wrapping around is true when working with 16bits registers. E.g.

Code: Select all

mov bx,0xffff
mov al,[bx] ; will read out DS:FFFF
inc bx
mov ah,[bx] ; will read out DS:0000
However, if you operate with 32bits registers (and eip *is* 32 bits), you can generate an offset that is >64K, which will make the segmentation unit report a fault. I can remember of early osdeving time where i had my computer hanging up in real mode because i used

Code: Select all

mov ebx,0xb8000
mov es,0
mov [es:ebx],'H i '   ; triggers a segfault, then a triple fault
My guess here is that you sent your eip somewhere out of existing code and you're executing bunch of "00 00" instructions (that should be add "al,[bx+si]", though we don't care) until getting out of the 64K allowed.

Nothing to do with A20 gate, i fear.