Nothing except a driver error should be able to stop a Linux system like that.

I suspect that you have different graphics driver versions in 2.6.16-2111 and 2.6.16-2111.

MiniMax wrote:

Nothing except a driver error should be able to stop a Linux system like that.

I suspect that you have different graphics driver versions in 2.6.16-2111 and 2.6.16-2111.

Unfortunatly I don't. My main system is using the latest Nvidia driver while the other is using vesa driver the FC installer chose when it was installed. Both computers have Nvidia graphics cards (one is a Geforce 4 and the other is a 6800 Ultra). I didn't notice YUM update any packages in regards to the video driver when I did the update on the 2111 system. It could be a different package in the update set causing the crash, but given the nature of the crash I'm fairly sure it is the Kernel. I might try to roll the kernel back to 2111 again and leave the rest of the packages intact and see what happens. Is there any command line switch I could use to try and get more information from Dosbox on what may be causing this? When I run dosbox from a console there are no messages execpt for the "no config file, using defaults" one before the system crashes.

well you could try compiling dosbox with debug information and stepping through it.

The important parts are reached quite early in the code. (the initialisation of the video card for example)

Qbix wrote:

well you could try compiling dosbox with debug information and stepping through it.

The important parts are reached quite early in the code. (the initialisation of the video card for example)

I compiled Dosbox as requested with --enable-debug. After installing a few missing devel packages it compiled successfully. I ran the version I compiled and the debug screen came up in the terminal. It looked like it was all set up, but there was no information where there should have been. The top looked like this:

EAX = ECX =
EBX = EDX =

showing the registers but no values. And as before the dosbox window opened with a black screen in it and the computer locked up. I left the computer for a minute or so in that state and when I returned the following text was in the terminal I had just run Dosbox in:

Message from syslogd@iphost-64-56-146-225 at Thu Jun 15 16:38:15 2006 ...
iphost-64-56-146-225 kernel: ------------[ cut here ]------------

Message from syslogd@iphost-64-56-146-225 at Thu Jun 15 16:38:15 2006 ...
iphost-64-56-146-225 kernel: kernel BUG at include/linux/list.h:58!

Message from syslogd@iphost-64-56-146-225 at Thu Jun 15 16:38:15 2006 ...
iphost-64-56-146-225 kernel: invalid opcode: 0000 [#1]

Message from syslogd@iphost-64-56-146-225 at Thu Jun 15 16:38:15 2006 ...
iphost-64-56-146-225 kernel: CPU: 0

Message from syslogd@iphost-64-56-146-225 at Thu Jun 15 16:38:15 2006 ...
iphost-64-56-146-225 kernel: EIP is at snd_seq_delete_all_ports+0x74/0x17d [snd_seq]

Message from syslogd@iphost-64-56-146-225 at Thu Jun 15 16:38:15 2006 ...
iphost-64-56-146-225 kernel: eax: 00000044 ebx: f0f93e48 ecx: f0d32f48 edx: f895c433

Message from syslogd@iphost-64-56-146-225 at Thu Jun 15 16:38:15 2006 ...
iphost-64-56-146-225 kernel: esi: f0f93e48 edi: f217c480 ebp: f217c508 esp: f0d32f44

Message from syslogd@iphost-64-56-146-225 at Thu Jun 15 16:38:16 2006 ...
iphost-64-56-146-225 kernel: ds: 007b es: 007b ss: 0068

Message from syslogd@iphost-64-56-146-225 at Thu Jun 15 16:38:16 2006 ...
iphost-64-56-146-225 kernel: Process dosbox (pid: 3519, threadinfo=f0d32000 task=f0971550)

Message from syslogd@iphost-64-56-146-225 at Thu Jun 15 16:38:16 2006 ...
iphost-64-56-146-225 kernel: Stack: <0>f895c433 f0f93e48 f217c508 f217c510 00000246 f217c51c f217c480 f24cfa58

Message from syslogd@iphost-64-56-146-225 at Thu Jun 15 16:38:16 2006 ...
iphost-64-56-146-225 kernel: f217c480 00000000 f04dd180 f261f594 f89561bc f217c480 f895627d f217c480

Message from syslogd@iphost-64-56-146-225 at Thu Jun 15 16:38:16 2006 ...
iphost-64-56-146-225 kernel: f89562c4 00000008 c01561cf f24cfa58 f7ff2d40 f04dd180 00000000 c2176580

Message from syslogd@iphost-64-56-146-225 at Thu Jun 15 16:38:16 2006 ...
iphost-64-56-146-225 kernel: Call Trace:

Message from syslogd@iphost-64-56-146-225 at Thu Jun 15 16:38:16 2006 ...
iphost-64-56-146-225 kernel: [<f89561bc>] seq_free_client1+0x8/0x7e [snd_seq] [<f895627d>] seq_free_client+0x4b/0x80 [snd_seq]

Message from syslogd@iphost-64-56-146-225 at Thu Jun 15 16:38:16 2006 ...
iphost-64-56-146-225 kernel: [<f89562c4>] snd_seq_release+0x12/0x31 [snd_seq] [<c01561cf>] __fput+0xae/0x151

Message from syslogd@iphost-64-56-146-225 at Thu Jun 15 16:38:16 2006 ...
iphost-64-56-146-225 kernel: [<c0153cf7>] filp_close+0x4e/0x54 [<c0102be9>] syscall_call+0x7/0xb

Message from syslogd@iphost-64-56-146-225 at Thu Jun 15 16:38:16 2006 ...
iphost-64-56-146-225 kernel: Code: 88 00 00 00 39 af 88 00 00 00 74 63 8b 9f 88 00 00 00 8b b7 8c 00 00 00 8b 43 04 39 f0 74 17 50 56 68 33 c4 95 f8 e8 43 0c 7c c7 <0f> 0b 3a 00 1e c4 95 f8 83 c4 0c 8b 06 39 d8 74 17 50 53 68 e8

I don't think there is much doubt from that the issue is with the kernel. I guess the question is what now?

Debugging DOSBox is completely outside my knowledge, but I think Qbix wanted you to run the debug-enabled binary under control of gdb (or is it gdbg, or gdbx ???) and single-step through the first parts of DOSBox's initialisation code.

The following is the result of single stepping the debug enabled dosbox using gdb on my system. The whole thing is rather large so I will cut out the middle and just leave the beginning and end in. If you want the whole thing let me know.

GNU gdb Red Hat Linux (6.3.0.0-1.122rh)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1".

(gdb) start
Breakpoint 1 at 0x80f87f0: file sdlmain.cpp, line 1229.
Starting program: /home/harpax/dosbox-0.65/src/dosbox
Reading symbols from shared object read from target memory...done.
Loaded system supplied DSO at 0xb82000
[Thread debugging using libthread_db enabled]
[New Thread -1208609040 (LWP 3214)]
[Switching to Thread -1208609040 (LWP 3214)]
main (argc=Cannot access memory at address 0xeacf4580
) at sdlmain.cpp:1229
1229 int main(int argc, char* argv[]) {
(gdb) next
1231 CommandLine com_line(argc,argv);
(gdb) next
347 this->_M_impl._M_node._M_next = &this->_M_impl._M_node;
(gdb) next
348 this->_M_impl._M_node._M_prev = &this->_M_impl._M_node;
(gdb) next
1233 control=&myconf;
(gdb) next
200 Config(CommandLine * cmd){ cmdline=cmd;}
(gdb) next
1233 control=&myconf;
(gdb) next
1234 if (control->cmdline->FindExist("-version") ||
(gdb) next
1264 DEBUG_SetupConsole();

------------------------Snip--------------------------------------------------------------------

1332 if (control->ParseConfigFile(config_file.c_str()) == false) {
(gdb) next
1333 LOG_MSG("CONFIG: Using default settings. Create a configfile to change them");
(gdb) next
CONFIG: Using default settings. Create a configfile to change them
1339 control->ParseEnv(environ);
(gdb) next
1342 control->Init();
(gdb)

Typing "next" at this point results in the black-filled dosbox window appearing and the system locking up.

well that is positive (or not). As it's in the DOSBox init code that is locking up and not in the init code of SDL (has happened as well).

controll->Init()
will call a list of functions which all init a subsection of DOSBox.
I'll think a while on where to put a suitable debug point to figure out in which subsection the lockup occurs.

I would start creating a dosbox.conf with nosound=true, mpu401=none, sbtype=none, gus=false, pcspeaker=false, and joystick=none.

Maybe it is the initialization/use of some of these that causes the hang.

I agree with Minimax.
Also try changing the output=surface to output=overlay

I created the config file with all the settings you suggested. Dosbox does confirm that it loads its settings from the dosbox.conf I created. Unfortunatly it had no effect on the crashing

I appreciate the effort you are putting in to helping me solve this though

I am seeing a similar problem with dosbox on an x86_64 FC5 system. Instead of a system freeze, I get an all black dosbox window and a kernel error on 'invalid opcode'. I have attached the kernel messages. I have verified that the problem exists in kernel 2.6.16-2133 but not in kernel 2.6.16-2122. Below is the relevant output of rpm -q --changelog.

Cheers, Wayne

[2.6.16-1.2133_FC5]
- Add a PPC64 kdump kernel.
[2.6.16-1.2132_FC5]
- 2.6.16.20
- Reenable Xen builds.
- 2.6.16.19
- Fix unresolved symbol. (#193333)
- Improve list corruption debugging patch.
- Remove xenU initrd's when kernel is removed.
- Remove ARCH=xen reminiscences on spec file
[2.6.16-1.2123_FC5]
- 2.6.16.18
[2.6.16-1.2122_FC5]

I also can't launch DOSBox on Fedora Core 5 x86_64. Doesn't hang my system though, I just need to kill DOSBox from the task manager (KDE System Guard).

No solution so far...

Guess what, I just got DOSBox to run under Fedora Core 5 x86_64 using Wine.
Only works well with output=ddraw, and scaling doesn't work well either, so no fixed fullscreen size.

Here's my configuration if anybody cares 😜

Well if anybody has a clue about this =) I'd be happy to fix the FE rpm. See #195266 in redhat bugzilla (https://bugzilla.redhat.com) for further details.

http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=195266 ...direct link

http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=194597

It seems to be an alsa problem.
It should be fixed with that update to the alsa kernel things