SS greater than 0x9000 crashes(Not exactly,proberbly SP)

[m]

Hi all.

These days I'm rewriting my boot sector program, which dosen't jump to PM. As long as I set SS to a value greater than 0x9000, Bochs will not accept it(even 0x900F). My snippets:

Code: Select all

MOV AX,0x9000
MOV SS,AX

will work, but even

Code: Select all

MOV AX,0x900F
MOV SS,AX

will not. Bochs just blank out the screen.

(I intended to set the stack base just below EBDA which is typically at 0x9FC00.)

Anybody knows what's going on? Thanks in advance. (Sorry but I haven't debugged it or tried on a real machine.)

[~]

Hi all.

These days I'm rewriting my boot sector program, which dosen't jump to PM. As long as I set SS to a value greater than 0x9000, Bochs will not accept it(even 0x900F). My snippets:

Code: Select all

MOV AX,0x9000
MOV SS,AX

will work, but even

Code: Select all

MOV AX,0x900F
MOV SS,AX

will not. Bochs just blank out the screen.

(I intended to set the stack base just below EBDA which is typically at 0x9FC00.)

Anybody knows what's going on? Thanks in advance. (Sorry but I haven't debugged it or tried on a real machine.)

Would it be admitted for you to post full or part of the source code? Maybe it's a Bochs issue, and should be better if first is evaluated what happens when run on real hardware.

[Combuster]

you will have to make sure SP is in the correct range -
if you make SS = 0x9001 and SP = 0 the first push/call will store memory to 0xA000E (which is in video memory). which most likely gets overwritten by any text drawing routines, smashing your stack.

I've tried it out in bochs, and i could even use SS=0x9F00 without problems, because i set SP correctly (SP=0xC00 SS:SP->0x9FC00).

[m]

Gee...

Sorry for troubling... Forgot to initialize SP...

But there're no PUSH or CALL or INT or other stack-related operations in my boot sector program yet...

And, why does Bochs keep restarting if I set SP between 0x0002 and 0x0010?

e.g. Even a functionless one:

Code: Select all

org 0x07C00

MOV SP,0X10
MOV AX,0x9001 ;Or greater than this
MOV SS,AX

JMP $

times 510-($-$$) db 0
dw 0xAA55

crashes.

Thanks.

[~]

Maybe it overwrites some interrupt vector?

Did you already tried it over real hardware?

Maybe the DS segment points to a vital area. I will see what it does to my PC...


----------------------------------

Now I have tested it and it DOES nothing to my testbed, real-hardware PC, and it even is able to fully load my kernel with no problem at all.

I insist, it could be an issue with Bochs. Sometimes it has happened to me very strange things while using it, like using string copying functions that work nicely but crash right away when tested in the testbed, or vice versa.

[Combuster]

did you bother upgrading to the last version yet?

[m]

Maybe it overwrites some interrupt vector?
...
Maybe the DS segment points to a vital area.

Err, I don't think that's the point...It shouldn't interfere because I didn't reference DS in the code above. (My Bochs is compiled with --enable-cpu-level=5 (Pentium) and DS is really initialized to 0x0000 after a reset, but setting DS=CS=0x07C0 doesn't help.)

Did you already tried it over real hardware?

Yes. I use the following snippet which performs a minimum function:

Code: Select all

org 0x07C00

;To show that this has nothing to do with DS
MOV AX,CS
MOV DS,AX

;Set up the stack
MOV AX,0x000E
MOV SP,AX
MOV AX,0x9001 ;Before here SS=0x0000
MOV SS,AX

;Try to access video buffer to make sure if it can reach here
MOV AX,0xB800
MOV GS,AX
MOV AL,'T'
MOV AH,0x0F
MOV word[GS:0],AX

JMP $

times 510-($-$$) db 0
dw 0xAA55

This works on a real machine, but crashes Bochs(even if I comment out the VGA access):

If SP=0x0002~0x0010 Bochs just keeps restarting with no VGA output(the green "Drive A:" indicates it's restarting); if SP=0x0011 Bochs keeps restarting at a relatively lower frequency(about 4~5 times per second). But both cases occur no matter what value is given to SS.

Stack-related operations with SP set to 0 or 1 will generate #SS and then #DF and make the CPU enter shutdown state. But what's wrong with SP set to 0x0002~0x0011? (And there's no such operation in the snippet above...)

did you bother upgrading to the last version yet?

Sorry but I'm not quite sure about what you mean... You mean Bochs? I'm using the released 2.3(not the snapshots). I build it from source code, configuring with all default arguments.

Regards

[~]

I (don't) think that there would likely be a periodical interrupt vector such as the one of timer/s; and since it only happens in Bochs and not in real hardware that must be a Bochs issue they have not fixed and probably they will be interested in knowing it. And anyway it doesn't do anything to my Bochs so I don't know what it can be, maybe that's a bug introduced on update or at compile-time from source.

[pcmattman]

Could you show us your Bochs log? A lot can be figured out from that, especially when you press the power button and the state is logged - including the state of ESP and SS.

[m]

Hi.

This time I found a lot more strange stuffs...

I (don't) think that there would likely be a periodical interrupt vector such as the one of timer/s

Yes, it must have something to do with interrupt, because if I add a CLI at the start of the program, it will work. But what surprises me are:

1. On a real machine even if I add a STI explicitly everything will work perfectly;

2. Bochs for Win32 accept the code;

3. When I enable Bochs internal debugger the crash disappears(IP comes to JMP $);

And anyway it doesn't do anything to my Bochs so I don't know what it can be, maybe that's a bug introduced on update or at compile-time from source.

I recompiled it but crashes still occur...

Could you show us your Bochs log? A lot can be figured out from that, especially when you press the power button and the state is logged - including the state of ESP and SS.

What I find in the log that can be a clue is that it may be the fault of INT 0x1C, which is for the user timer. But:

4. INT 0x1C should have an empty routine initially, so if it occurs only EFLAGS, CS and IP will be pushed, and IF will be reset. And such operations shouldn't take up so much stack space.

("especially when you press the power button",yeah,of course--it keeps restarting! When I "finally" realized what was going on, bochsout.txt had grown to over 20 MB. )

It's really a strange problem to me(but may be a waste of time for you because nobody would have such a small stack )... Before I can make sure that it's a bug of Bochs I still would like to know more of what you think about it...

Thanks!

[edit] Why it will triple a fault if I press Alt when the focus is given to Bochs' window? The fault indicates that eSP < 16 and it's too small for a PUSHAD instruction...
[/edit]

[frank]

Some interrupts also push all registers upon entry in order changing the values of any of them. On a real computer, IRC the stack pointer may just wrap around and not give an error.