Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Bochs messages "CPU_LOOP 1"

11 views
Skip to first unread message

Brian

unread,
Nov 19, 2005, 1:58:42 AM11/19/05
to
All,

When running my buggy kernel, the newer version of Bochs I'm using
(2.2.1) starts pumping out the message "CPU_LOOP 1" and becomes
un-interruptable (I have to kill it). What does this message mean?

>From what I can tell, my OS has gone into a loop as well.

I looked at the source code on the web but couldn't find a place where
the string "CPU_LOOP" is defined.

I'm curious to know what this means as it might help me work out what
my OS code is doing.

Thanks,
Brian.

Laurent D.A.M. Menten

unread,
Nov 19, 2005, 7:43:19 AM11/19/05
to
since you get this message i guess you have configured bochs with
internal debugger feature, the CPU_LOOP message is due to bochs
ignorering or reporting error messages. In fact when bochs reaches a
situation where it has trouble simulating (ie a cpu exception) it
reports it as an error and if it is not otherwise instructed it simply
continues. If your kernel has setup an exception handling framework
(IDT, gates for exceptions etc...) the cpu act as it should but if you
have'nt, you get another exception (within context of the first one)
about the first one not cleared and kaboom!!!

I found that including these lines in the bochsrc file solved:

debug: action=ignore
panic: action=fatal
error: action=ask
info: action=report

in my own case, when i start simulating I encounter some errors from
CLVGA claiming about "carachter height=1", "alwayscont" helps having
them no more. Upon a cpu exception you get a message from "CPU0", "die"
will case a cpu dump and bochs to stop. If i had choosen "cont", another
error from CPU0 would arise about "exception with no resolution" and
another "cont" leads to "CPU_LOOP 1"

For informations: the message can be found in <bochs_source>/cpu/cpu.cc

Regards
Laurent.

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS/O d--(---) s: a C++ UL++++ P+ L+++ E--- W++ N+ o-- K--- w--
O- M- V- PS++ PE Y+ PGP- t 5 X++ R* tv++ b++ DI++ D
G+ e++ h-- r+++ y+++
------END GEEK CODE BLOCK------

Paul Barker

unread,
Nov 19, 2005, 7:51:42 AM11/19/05
to
With version 2.1.1, bochs is going un-interruptable when my kernel
triple faults. Do you have exception handling setup properly in your
kernel? Do you handle double faults with a separate TSS (the only
correct way to handle kernel stack overflows)?

I haven't seen this particular message and also can't find it in the
source code. My only advice is to try using bochs' builtin debugger or
gdb to find the problem, or at least try to look up which function in
your kernel EIP refers to when bochs crashes.

HTH,
Paul

Nicholas Sherlock

unread,
Nov 19, 2005, 8:31:58 PM11/19/05
to
Brian wrote:
> When running my buggy kernel, the newer version of Bochs I'm using
> (2.2.1) starts pumping out the message "CPU_LOOP 1" and becomes
> un-interruptable (I have to kill it). What does this message mean?

I imagine that it has detected code like this:

loop:
jmp loop

Cheers,
Nicholas Sherlock

Brian

unread,
Nov 21, 2005, 5:20:38 AM11/21/05
to

Laurent D.A.M. Menten wrote:
> since you get this message i guess you have configured bochs with
> internal debugger feature, the CPU_LOOP message is due to bochs
> ignorering or reporting error messages. In fact when bochs reaches a
> situation where it has trouble simulating (ie a cpu exception) it
> reports it as an error and if it is not otherwise instructed it simply
> continues. If your kernel has setup an exception handling framework
> (IDT, gates for exceptions etc...) the cpu act as it should but if you
> have'nt, you get another exception (within context of the first one)
> about the first one not cleared and kaboom!!!
>
> I found that including these lines in the bochsrc file solved:
>
> debug: action=ignore
> panic: action=fatal
> error: action=ask
> info: action=report
Cool that 'fixed' it- I now get:
exception(): 3rd (14) exception with no resolution, shutdown status
is 00h, resetting
Which makes a lot more sense.
Sort of.

Anyway- something to go on with...

Brian

unread,
Nov 21, 2005, 5:26:15 AM11/21/05
to
The problem with using the builtin debugger is that it happens after
quite some time. I've got a basic task that just keeps asking for
memory and eventually it enters into this CPU_LOOP thing. After 100s of
successfull iterations, it suddenly goes weird.

Now that I know its a triple fault in the Page Fault handler, I've
narrowed it down a lot...

Thanks for your help.

0 new messages