Call for testing - Bochs is coming to new release

[stlw]

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.

So might be the new option is exacty what you need.

But first I would try to determine the segfault reason. if this is some bug in harddrive emuation code - it is completely different story.
If your segfault happens because of 'out-of-memory' problem you have a solution.

The option of 'host' and 'guest' is pretty well documented in .bochsrc:

Code: Select all

# GUEST:
# Set amount of guest physical memory to emulate. The default is 32MB,
# the maximum amount limited only by physical address space limitations.
#
# HOST:
# Set amount of host memory you want to allocate for guest RAM emulation.
# It is possible to allocate less memory than you want to emulate in guest
# system. This will fake guest to see the non-existing memory. Once guest
# system touches new memory block it will be dynamically taken from the
# memory pool. You will be warned (by FATAL PANIC) in case guest already
# used all allocated host memory and wants more.

So for example if you put guest =1024 and host = 128 it wil allocate and use ony 128MB of host RAM but guest OS will think it has the whole 1024.
It probably won't help you alone and you shortly wil hit a PANIC but if you add new option --enable-large-ramfile it will run fine.
The option implements swapping to the file so you can emulate more RAM than you actualy could allocate.

Stanislav

[Artlav]

The option of 'host' and 'guest' is pretty well documented in .bochsrc:

Sorry, for some reason i didn't think of checking that one.

But first I would try to determine the segfault reason. if this is some bug in harddrive emuation code - it is completely different story.
If your segfault happens because of 'out-of-memory' problem you have a solution.

No, the memory turns out to be unrelated.
The crash apparently happens in sparse image handling.
Tried the same with growing image type, and so far Windows setup is still running.

For some reason gdb won't show exact line numbers for some functions, despite me doing a clean rebuild with -g and -O0 ( "no symbol table info available" ).
Anything else i can obtain to help solve that?

Code: Select all

#0  0x100a9d3c in sparse_image_t::write(void const*, unsigned int) ()
#1  0x100a184c in bx_hard_drive_c::ide_write_sector(unsigned char, unsigned char*, unsigned int) ()
#2  0x100a2a78 in bx_hard_drive_c::write_handler(void*, unsigned int, unsigned int, unsigned int) ()
#3  0x1018411c in bx_cpu_c::OUTSD16_DXXd(bxInstruction_c*) ()
#4  0x10110c34 in bx_cpu_c::repeat(bxInstruction_c*, void (*)(bxInstruction_c*)) ()
#5  0x10186008 in bx_cpu_c::REP_OUTSD_DXXd(bxInstruction_c*) ()
#6  0x10111988 in bx_cpu_c::cpu_loop(unsigned int) ()
#7  0x10051834 in bx_begin_simulation (argc=1, argv=0x7fff3a34) at main.cc:942
#8  0x101b7d60 in bx_real_sim_c::begin_simulation (this=0x110412e0, argc=1, argv=0x7fff3a34) at siminterface.cc:800
#9  0x101c3cd4 in bx_config_interface(int) ()
#10 0x101c45ac in bx_config_interface(int) ()
#11 0x101c4f08 in ci_callback(void*, ci_command_t) ()
#12 0x101b7cd8 in bx_real_sim_c::configuration_interface (this=0x110412e0, ignore=0x102022a0 "textconfig", command=CI_START) at siminterface.cc:793
#13 0x1004fed8 in bxmain () at main.cc:295
#14 0x1004ffc4 in main (argc=1, argv=0x7fff3a34) at main.cc:483

[Cognition]

I get the same error Combuster did for out of source builds.

Additionally configure lists an a new option as '--enable-handlers-chaining' but actually scans for '--enable-handlers-chaining-speedups'.

I had the same bug with bx_debug/lex.c being empty that XenOS did as well. Turns out I didn't have flex installed and the error got buried, might want to double check that configure is correctly checking for flex if it is required, or not overwriting bx_debug/lex.c if it doesn't need to (copy in SVN seems fine).

AVX support doesn't seem to work outside of the single predefined sandy bridge cpu. It seems like there's supposed to be an option under the 'cpu:' field for it, but it isn't documented and bochs will complain it cannot locate the avx field and promptly segfault.

I've been having a lot of weird sync issues and X basically refusing to update most of the screen if bochs is running when 'clock: sync=none' is running with multiple processors. 'clock: sync=realtime' seems to work properly albeit at reduced speed. Desync seems to related to either the APIC Timer or perhaps the actual mp wakeup by the OS (seems to hang around this point on my OS and gentoo's live cd).

System: Core i7-920, 6gb RAM, Running SVN build on Ubuntu 11.04.

[xenos]

AVX support doesn't seem to work outside of the single predefined sandy bridge cpu. It seems like there's supposed to be an option under the 'cpu:' field for it, but it isn't documented and bochs will complain it cannot locate the avx field and promptly segfault.

I think, in addition to the --enable-avx configure switch, you need to enable AVX support in the .bochsrc file using the "cpuid" directive. With this directive you can enable / disable CPU features by setting / resetting the feature flags, which are reported by the CPUID instruction. Setting the CPU model to "sandy bridge" enables certain features, and AVX seems to be one of them.

[stlw]

I think, in addition to the --enable-avx configure switch, you need to enable AVX support in the .bochsrc file using the "cpuid" directive. With this directive you can enable / disable CPU features by setting / resetting the feature flags, which are reported by the CPUID instruction. Setting the CPU model to "sandy bridge" enables certain features, and AVX seems to be one of them.

No, the AVX param indeed was misplaced (just a copy-paste problem in the code). I am going to fix it today evening.
The change is in config.cc:

- new bx_param_num_c(cpu_param,
+ new bx_param_num_c(cpuid_param,

Stanislav

[stlw]

I get the same error Combuster did for out of source builds.

Additionally configure lists an a new option as '--enable-handlers-chaining' but actually scans for '--enable-handlers-chaining-speedups'.

I had the same bug with bx_debug/lex.c being empty that XenOS did as well. Turns out I didn't have flex installed and the error got buried, might want to double check that configure is correctly checking for flex if it is required, or not overwriting bx_debug/lex.c if it doesn't need to (copy in SVN seems fine).

AVX support doesn't seem to work outside of the single predefined sandy bridge cpu. It seems like there's supposed to be an option under the 'cpu:' field for it, but it isn't documented and bochs will complain it cannot locate the avx field and promptly segfault.

I've been having a lot of weird sync issues and X basically refusing to update most of the screen if bochs is running when 'clock: sync=none' is running with multiple processors. 'clock: sync=realtime' seems to work properly albeit at reduced speed. Desync seems to related to either the APIC Timer or perhaps the actual mp wakeup by the OS (seems to hang around this point on my OS and gentoo's live cd).

System: Core i7-920, 6gb RAM, Running SVN build on Ubuntu 11.04.

Fixed the configure script and AVX configuration.
About bx_debug/lexer.cc - it sounds very weird to me. Configure script doesn't try to overwrite that file, it doesn't touch it at all.
About graphics update - Volker is trying to disconnect the graphics updated from the CPU clock (and therefore also from clock:sync option) so it will be updated according to the new vga:update_freq option only.
I hope this issue will disappear till the release.

Stanislav

[stlw]

For some reason gdb won't show exact line numbers for some functions, despite me doing a clean rebuild with -g and -O0 ( "no symbol table info available" ).
Anything else i can obtain to help solve that?

Code: Select all

#0  0x100a9d3c in sparse_image_t::write(void const*, unsigned int) ()
#1  0x100a184c in bx_hard_drive_c::ide_write_sector(unsigned char, unsigned char*, unsigned int) ()
#2  0x100a2a78 in bx_hard_drive_c::write_handler(void*, unsigned int, unsigned int, unsigned int) ()
#3  0x1018411c in bx_cpu_c::OUTSD16_DXXd(bxInstruction_c*) ()
#4  0x10110c34 in bx_cpu_c::repeat(bxInstruction_c*, void (*)(bxInstruction_c*)) ()
#5  0x10186008 in bx_cpu_c::REP_OUTSD_DXXd(bxInstruction_c*) ()
#6  0x10111988 in bx_cpu_c::cpu_loop(unsigned int) ()
#7  0x10051834 in bx_begin_simulation (argc=1, argv=0x7fff3a34) at main.cc:942
#8  0x101b7d60 in bx_real_sim_c::begin_simulation (this=0x110412e0, argc=1, argv=0x7fff3a34) at siminterface.cc:800
#9  0x101c3cd4 in bx_config_interface(int) ()
#10 0x101c45ac in bx_config_interface(int) ()
#11 0x101c4f08 in ci_callback(void*, ci_command_t) ()
#12 0x101b7cd8 in bx_real_sim_c::configuration_interface (this=0x110412e0, ignore=0x102022a0 "textconfig", command=CI_START) at siminterface.cc:793
#13 0x1004fed8 in bxmain () at main.cc:295
#14 0x1004ffc4 in main (argc=1, argv=0x7fff3a34) at main.cc:483

I have no idea what it can be and I didn't see this such kind of failures before. But this might be because I never used sparsed disk images
Does it work for you with plan 'flat' disk image ?
The only think I would like to check is if that prblem exists on normal host, like UNIX.
And if this is the case - we can try to reproduce and debug it on out env. it is also much more serious issue if Bochs crashes on such error on any host and nt only in your case.

Stanislav

[Artlav]

I have no idea what it can be and I didn't see this such kind of failures before. But this might be because I never used sparsed disk images
Does it work for you with plan 'flat' disk image ?
The only think I would like to check is if that prblem exists on normal host, like UNIX.
And if this is the case - we can try to reproduce and debug it on out env. it is also much more serious issue if Bochs crashes on such error on any host and nt only in your case.

One thing is certain - it does not seem to be limited to Linux or MIPS, a quick test on Windows host with a sparse image produced a crash at cdrom boot in the newest SVN build.

At the same time, growing image format works fine on any host.

What is wrong with using sparse images?
I was under impression it was the default bigger-on-the-inside-than-outside format, no?
If not, are their problems worth fixing?


Setting: Windows 7 64bit, .conf.win32-vcpp, Cygwin configure, VS2005 build, 4Gb sparse disk image, doing windows xp installation.

First problem, crash at cdrom boot start.
The error says "Unhandled exception at 0x004fe3af in bochs.exe: 0xC0000005: Access violation reading location 0xcdcdcf25"
Happens in hdimage.cc ( ssize_t sparse_image_t::write (const void* buf, size_t count) )
At hdimage.cc:774, parent_image is used without being initialized.
Adding parent_image=NULL; to sparse_image_t::sparse_image_t() constructor seems to have solved that problem (no idea if that is a correct way to fix this).

This also solves that problem on MIPS Linux.

However, then there is a second problem:
Winxp setup proceeded, but after formatting the disk there is an error:

Code: Select all

 Windows XP Professional Setup
================================

   Setup was unable to format the partition. The disk may be damaged.

   Make sure the drive is switched on and properly connected
   to your computer. If the disk is a SCSI disk, make sure your SCSI
   devices are properly terminated. Consult your computer manual or
   SCSI adapter documentation for more information.

   You must select a different partition for Windows XP.
   To continue, press ENTER.

No idea where is the problem with that one.

Summarily, sparse images look generally broken or out of date.

[stlw]

Summarily, sparse images look generally broken or out of date.

I created Bochs bug report on the Sourceforge a copied our discussion inside.
Hooefully Volker wil have some idea how to fix it.

Stanislav

[Combuster]

I just came across a usability issue which you might want to consider: if you are in long mode, the bochs exit dump says "16 bits" when the least confusing output would be that code decoding is set to 64 bits mode instead.

[stlw]

I just came across a usability issue which you might want to consider: if you are in long mode, the bochs exit dump says "16 bits" when the least confusing output would be that code decoding is set to 64 bits mode instead.

Try SVN now

Stanislav

[rdos]

Doesn't even recognize the RDOS floppy image as bootable (link: http://www.rdos.net/rdos/floppy.img).

Procedure:
1. Download version 2.4.6 binary
2. Start Bochs.
3. Select "disc boot", 1.44MB floppy, and load local floppy.img file, press OK
4. Press start

PANIC:
[BIOS]
No bootable device

The image works with Virtual PC 2007.