Call for testing - Bochs is coming to new release

[stlw]

The new release of Bochs is just around the corner.

From the most visible features :

1. Configure CPU to emulate using a single .bochsrc option. The option selects CPU configuration to emulate from pre-defined list of supported configurations.
When this option is used, Bochs CPU emulation engine is automatically configured to emulate a specific real hardware CPU, including exact CPUID matching reference hardware.
* It is also possible to choose the CPU to emulate from Bochs command line using command line interface to .bochsrc: "cpu::model <cpu_name>"
* Query for supported CPU models using command line option: -help cpu.
2. Aligned Bochs CPU implementation to latest published Intel docs (including AVX2 support, BMI and latest VMX extensions). No FMA yet.
3. Rework of CPU code for another 10% of emulation performance. Also added a patch to patch tracker which double performance of 2-wide SMP emulation.
4. Dozens of devices and CPU emulation bugfixes and enhancements

Thanks for those who sent CPUID dumps from CPU-Z when asked, some of your CPUID were used as reference CPU models in coming Bochs release.
If you want to see other CPUID in the list / have any suggestions - I am here.

This is call for testing, to find another bug before we decide to issue official 2.4.7 build.

Stanislav

[Combuster]

Do you have a specific version to be tested or shoud I get either the CVS or SVN head revision? There are repositories for both systems.

A link would make it even easier for the lazy here

[stlw]

Do you have a specific version to be tested or shoud I get either the CVS or SVN head revision? There are repositories for both systems.

A link would make it even easier for the lazy here

The new relelase is in SVN.
You can download most recent stable SVN snapshot:

Code: Select all

svn co https://bochs.svn.sourceforge.net/svnroot/bochs/trunk/bochs bochs

Or try to download most recent tarball from (Download GNU tarball):
http://bochs.sourceforge.net/cgi-bin/to ... _ideq12580
Didn't work for me with IE9

All compilation options are supported and should work - Linux, Windows with Cygwin and MingW (I recommend MinGW), Windows wih MSDEV using nmake or project files.
There are less configure-time opts again - be careful !

Stainislav

[xenos]

It seems I still need to get used to the new / fewer configure-time options When I try to build the current SVN version with debugger support enabled, the build fails. Whenever I add "--enable-debugger --enable-disasm" to the configure command line, I get the following error during make:

Code: Select all

bx_debug/libdebug.a(dbg_main.o): In function `bx_dbg_interpret_line(char*)':
/data/C/osdev/bochs/bx_debug/dbg_main.cc:241: undefined reference to `bx_add_lex_input'
bx_debug/libdebug.a(dbg_main.o): In function `bxerror':
/data/C/osdev/bochs/bx_debug/dbg_main.cc:441: undefined reference to `bxtext'
bx_debug/libdebug.a(dbg_main.o): In function `bx_dbg_user_input_loop()':
/data/C/osdev/bochs/bx_debug/dbg_main.cc:293: undefined reference to `bx_add_lex_input'
bx_debug/libdebug.a(parser.o): In function `bxparse':
/data/C/osdev/bochs/bx_debug/y.tab.c:2203: undefined reference to `bxlex'
collect2: ld returned 1 exit status
make: *** [bochs] Error 1

Maybe I'm just missing something obvious...

I'm running Ubuntu 10.04.

Edit: I just found that bx_debug/lexer.c is empty - I'll try to find out, why...
Edit 2: Funny, it seems that I somehow deleted the contents of lexer.c and didn't notice. Now I simply replaced lexer.c in the source tree with the version from the SVN repository and everything works fine.

I guess I'll spend a lot of time testing and having fun Thanks a lot for the time and effort you spend for this project, it's certainly one of the most valuable tools for OS developers!

[Artlav]

So, should i post the bugs here?

SVN pullout from an hour ago ( svn co https://bochs.svn.sourceforge.net/svnro ... runk/bochs bochs ), compiled with .conf.linux.
DLX Linux image downloaded from Bochs site.

Start up, fail down just before O in LILO is printed: " >>PANIC<< fetchdecode: Unknown opcode group 160"
Full log here: http://orbides.1gb.ru/bochsout_110830_dlx.txt

The host system is Linux on Loognson2F CPU (MIPS64el), which is quite likely related to the problem.
Don't know if it's fixable for this release, but having it fixed in the long run would be cool.

[Combuster]

First thing tested: out-of-tree builds are broken. Seems to trip over the new code as libiodev.a and libcpu.a completed without a hitch:

Code: Select all

mkdir bochs-build && cd bochs-build
../bochs-svn/configure
make

(...)

cd cpu/cpudb && \
make  libcpudb.a
make[1]: Entering directory `/home/marcel/dev/bochs-build/cpu/cpudb'
g++ -c -I.. -I../.. -I../../../bochs-svn/cpu/cpudb/../.. -I../../instrument/stubs -I../../../bochs-svn/cpu/cpudb/../../instrument/stubs -g -O2 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES   ../../../bochs-svn/cpu/cpudb/pentium_mmx.cc -o pentium_mmx.o
../../../bochs-svn/cpu/cpudb/pentium_mmx.cc:25:17: error: cpu.h: No such file or directory
make[1]: *** [pentium_mmx.o] Error 1
make[1]: Leaving directory `/home/marcel/dev/bochs-build/cpu/cpudb'
make: *** [cpu/cpudb/libcpudb.a] Error 2

[Combuster]

4. Dozens of devices and CPU emulation bugfixes and enhancements

VGA's doublescan bit is ignored. VGA's address difference per pixel is chosen by the chain-4 bit instead of the byte/word and byte/dword mode bits (toggling chain-4 should never change what's already on the screen).

[stlw]

VGA's doublescan bit is ignored. VGA's address difference per pixel is chosen by the chain-4 bit instead of the byte/word and byte/dword mode bits (toggling chain-4 should never change what's already on the screen).

Nu, come on, you know how it works !
Please open the bug report on the bug tracker or write into Bochs-Developers mailing list, explain the same and if possible supply the test case image that will demonstrate the problem and could be used for debugging.

Stanislav

[stlw]

So, should i post the bugs here?

Yes, you can.

SVN pullout from an hour ago ( svn co https://bochs.svn.sourceforge.net/svnro ... runk/bochs bochs ), compiled with .conf.linux.
DLX Linux image downloaded from Bochs site.

Start up, fail down just before O in LILO is printed: " >>PANIC<< fetchdecode: Unknown opcode group 160"
Full log here: http://orbides.1gb.ru/bochsout_110830_dlx.txt

Yes, my bad. It was stupid bug. The PANIC should not appear anymore.
it is not related to our host, I accidentialy removed some part of the code that should stay during one of my last commits.

Just fixed it. Could you retry ?

Stanislav

[stlw]

First thing tested: out-of-tree builds are broken. Seems to trip over the new code as libiodev.a and libcpu.a completed without a hitch:

Code: Select all

mkdir bochs-build && cd bochs-build
../bochs-svn/configure
make

(...)

cd cpu/cpudb && \
make  libcpudb.a
make[1]: Entering directory `/home/marcel/dev/bochs-build/cpu/cpudb'
g++ -c -I.. -I../.. -I../../../bochs-svn/cpu/cpudb/../.. -I../../instrument/stubs -I../../../bochs-svn/cpu/cpudb/../../instrument/stubs -g -O2 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES   ../../../bochs-svn/cpu/cpudb/pentium_mmx.cc -o pentium_mmx.o
../../../bochs-svn/cpu/cpudb/pentium_mmx.cc:25:17: error: cpu.h: No such file or directory
make[1]: *** [pentium_mmx.o] Error 1
make[1]: Leaving directory `/home/marcel/dev/bochs-build/cpu/cpudb'
make: *** [cpu/cpudb/libcpudb.a] Error 2

I can say something is wrong in your source code setup.
Let's look together.
The error is that cpu.h cannot be found. Teh cpu.h file located in the cpu folder.
The complation supposed to go from cpu/cpudb folder.
The compilation command is:

Code: Select all

g++ -c -I.. -I../.. -I../../../bochs-svn/cpu/cpudb/../.. -I../../instrument/stubs -I../../../bochs-svn/cpu/cpudb/../../instrument/stubs -g -O2 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES   ../../../bochs-svn/cpu/cpudb/pentium_mmx.cc -o pentium_mmx.o

It includes the -I.. as well so it must find teh cpu.h as well. Are you sure you not removed it by chance ?

Stanislav

[Combuster]

Nu, come on, you know how it works !

You tell me what my unsolved tickets are doing there?

Will try again for luck.

[Combuster]

The error is that cpu.h cannot be found. Teh cpu.h file located in the cpu folder.
The complation supposed to go from cpu/cpudb folder.
The compilation command is:

Code: Select all

g++ -c -I.. -I../.. -I../../../bochs-svn/cpu/cpudb/../.. -I../../instrument/stubs -I../../../bochs-svn/cpu/cpudb/../../instrument/stubs -g -O2 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES   ../../../bochs-svn/cpu/cpudb/pentium_mmx.cc -o pentium_mmx.o

It includes the -I.. as well so it must find teh cpu.h as well. Are you sure you not removed it by chance ?

Well, no for two reasons: the file exists and in-tree builds work as expected. Second, your observation is off: cpu.h is located in ../../../bochs-svn/cpu, which suggests that

Code: Select all

-I../../../bochs-svn/cpu/cpudb/../..

should be

Code: Select all

-I../../../bochs-svn/cpu/cpudb/..

when compiling in-tree, the include dependency gets solved by the -I.. argument instead of the -I./.. expected making the compilation work, seemingly by accident:

Code: Select all

g++ -c -I.. -I../.. -I./../.. -I../../instrument/stubs -I./../../instrument/stubs -g -O2 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES   pentium_mmx.cc -o pentium_mmx.o

which should probably be

Code: Select all

g++ -c -I.. -I../.. -I./.. -I../../instrument/stubs -I./../../instrument/stubs -g -O2 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES   pentium_mmx.cc -o pentium_mmx.o

[stlw]

Nu, come on, you know how it works !

You tell me what my unsolved tickets are doing there?

Will try again for luck.

Not sure I remember some of yours ... Can you remind me ?

Stanislav

[Artlav]

Just fixed it. Could you retry ?

Yes, that particular problem is now fixed.
On to installing the Windows which is what failed on this host before, so more bug reports are probably on their way.

A practical question from lack of documentation - what does the (relatively) new host/guest memory specifications mean?
If i set both to 512 (1 Gb on host), then Bochs segfaults shortly after boot, but with something like 384 it works fine.
What do they represent and how do they add up?

[Artlav]

As before, WinXP install segfaults Bochs when formatting the disk starts.
Nothing noticeable in the log.
It seems to be related to memory amount settings - the more, the earlier it crashes.