OSDev.org

Artlav wrote: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.

# 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.

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

stlw wrote: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.

#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 wrote: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.

XenOS wrote:
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.

Cognition wrote: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.

Artlav wrote: 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

stlw wrote: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.

 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.

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

Combuster wrote: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.