Emulator

anyone got any answers? c'mon, this is the final step to having this emu fully
playable for me on 64-bit linux.

This is due to locking issues with X11. I'm guessing you are running it in dual-core
mode? Try in single core

The issue is still there when in single core mode.

I can't reproduce this bug on my system (8.10 x86_64) with the only game I have
available. It just never behaves like that.
Maybe it's due to the AMD DC timing bug?
I have a Core2 Duo.

Updated bios, no change to issue. Board is an ECS Geforce 7050M-M V2.0 (AM2+).
Also the kernel would probably warn me of an APIC timers bug on boot, which it does
not do in this case, and it is extremely fast/reliable in every other program on the
system.

Is there anything I can do to help debug this? I've tried switching all the emulation
options off one by one to see which makes a difference, they all seem to have no
effect on the original issue.

i have come across this same thing. in both of the gc pikmins and wind-waker. Running
linux 64bit with dual core. i also tried all the settings but it continues to hangs.
It seems to only happen at certain parts of the games...

The 'certain parts' of games seem to be (in my case) parts where the user isn't
pressing any buttons, for example intros and cut scenes, because the user needs to
input a keystroke or move / click the mouse in the window to get a response, as
stated in the original issue.

Upon further testing it seem to happen about 15 seconds of not pressing anything
during a when fps > 25. but if the game is lagging it will "stop" after as little as
3 sec. it's quite annoying with cutscence of the deku tree in WW...

I was having this same issue about 2k revision ago in ubuntu 8.10 I never figured it
out either.

I think glen fixed that one a few revisions ago.
Can anyone confirm?

Nakeee: I am not sure if I fixed this. I have never seen the occurrence of this issue.

I'm also experiencing this problem. My machine has an Athlon 4850e Dual Core
Processor running Debian Stable with a 32 bit kernel.
It really seems that without any input the game is paused (I tried this with NSMB and
Pikmin). If I keep holding a key down the emulation seems quite smooth, but if not it
doesn't take long (say 2 to 3 seconds) until the emulation seems to pause.

If I can help in any way to debug this (I also have programming experience) I'd be
glad help.

fixed: http://code.google.com/p/dolphin-emu/issues/detail?id=2792

Issue 2792 has been merged into this issue.

Well, I still have the same problem in r5777. I'm using Arch 64.

I confirm too that this bug has returned. This was slightly noticeable (every minutes or so) in r5760, but in the latest ones it's unbearable (every seconds).

Forgot to mention that I too am using Arch 64.
Geez, what's up with this distribution an dolphin :(

see r5758 and issue 2792 comment 5

What version of Xlib is on Arch?

Arch's current version of xlib (libx11 package) is 1.3.4

Yeah, that is what I thought. Ubuntu 10.04 has version 1.3.2, and it seems that those that are having this problem have 1.3.4. Someone tested 1.3.3 and that version seems to not have the problem either. There is probably a bug introduced in version 1.3.4 of libx11 that is causing this problem. I believe it is with the calls to XQueryPointer. That is not supposed to be a blocking call, but it seems to be blocking in 1.3.4. Hence the freezes.

I'm using arch64 and the only way around that bug is to decrementing by one the number of calls to XNextEvent(). The man pages on arch says that XNextEvent() will block once it has reached the end of it's event list and wait for any other event. Hence why it only starts again when you move the mouse. It also blocks because the XLib driver running in a seperate thread is trying to query xlib for the mouse/keyboard status at the same time.

Karloathian: You are misunderstanding the code. You are missing that we first call XPending to see how many events there are before we start calling XNextEvent to obtain those events. XNextEvent will only block if the event queue is empty, as stated in the man page. If you decrement the number of calls to XNextEvent by one, then an event will not be acted on until the next event occurs. Now stop suggesting this way to "fix" the problem. It will never be in the dolphin code because it is wrong.

The problem is that on the newer version of XLib on Arch Linux there is a bug that makes XQueryPointer block.

As far as I can tell, I am not getting freezes the require the mouse to move anymore, but am instead getting full dolphin lockups in most games that were fine in 5643. Points in game vary, but usually during one of the first times user has character control. Hope the lock-up is a temp regression but the mouse problem is fixed.

eyecreate: What revision are you using? 5643 is a rather old revision.

Sorry, I forgot to tell which, I was using 6081 from last night. Funny thing is, I tried putting the -1 on the event list in old revision 5643 and it didn't fix the mouse issue for me, but actually made the effect worse.

eyecreate: Can you do a gdb backtrace, and see where the problem is? The -1 on the event list never really worked. As I pointed out earlier in this thread, that was a hack that causes other problems.

Well, it would probably help if it was actually crashing(like a segfault). Instead, the game just loops the past 3 seconds of sound and becomes unresponsive. Main Dolphin window still works(as if ingame) and only thing that won't work is hitting stop. Which then causes the whole program to stop responding.(though stops the sound) Output of console listed here:
http://pastebin.com/9L7HzrVX

What distribution of linux are you using? Also, how are you building dolphin? What scons command line? Also, which of the libraries GLEW, lzo, SDL, SFML, SOIL, and zlib are you building static or shared?

Hopefully, this is the answer to all those questions. This is the build script I've been using.
http://aur.archlinux.org/packages.php?ID=21990

I did make symbolic link for SOIL as in comment by amentajo.

I really just want to make sure that you are not building GLEW, SDL, and zlib from the externals (although it shouldn't matter). lzo, SFML, and SOIL shouldn't matter much anymore.

It might help if you can find out exactly which revision caused the problem.

After lots of comping different revisions and testing, it seems the changing point is revision 6067.

Can you try reverting the changes in that revision to the OpenGL plugin and see if you can find what is causing it? Neither I nor anyone else seems to be having your problem so I can't diagnose it.

using rev6092 and taking out all modifications to the ogl plugin, I get a dolphin that doesn't freeze, but still has the mouse click issue. While making htese changes, I was thinking, maybe the mouse click issue wasn't gone, but just hidden because of the freezing before.(unless there was a part of what I reverted that fixed mouse but doesn't cause freeze.)

There were not that many changes made to the OpenGL plugin in revision 6067. Can you do a little testing to see exactly which change is causing your freeze issue? In particular check to see that if line 118 of /trunk/Source/Plugins/Plugin_VideoOGL/Src/GLUtil.cpp is put back to the way it was, then does that fix the issue? Independently check to see if you add the XkbSetDetectableAutoRepeat function back in where it was and add the inclusion back into GLUtil.h, then does that fix the issue?

As to the mouse click issue, that is most likely still going to happen. As I have said before in this issue, that is not a bug in dolphin, but a bug in the version of the X server that is installed on arch-linux.

eyecreate, I'm using that same package in Arch64 and it works fine for me (I enable openCL and add the -1 to XPending(GLWin.dpy)).

Make sure you have all libraries in your system up to date (mine are).

changing line 118 back stopped the freezing.

That is odd. All putting that line back does is add several event masks for events that we are not even using. Something is really messed up with the version of the x server that is on Arch Linux. I wonder if the Arch Linux packagers made some changes to the source for their distributed packages that is causing this, or if this is an upstream issue.

I think it is an upstream issue. Looking at the PKGBUILD (which you can find here: http://repos.archlinux.org/wsvn/packages/libx11/trunk/PKGBUILD ) all arch does is configure the build with the --prefix=/usr --with-xcb --disable-static options. Seems fairly standard to me. However it looks like version 1.3.5 of libx11 has been released and Arch just needs to build a package for it. You can read the announcement here: http://www.spinics.net/lists/xorg/msg50480.html

As for the actual xorg-server, it looks like a patch from redhat gets applied and then the build is configured with some standard options. Nothing out of the ordinary. You can see the PKGBUILD for yourself here: http://repos.archlinux.org/wsvn/packages/xorg-server/trunk/PKGBUILD

Can someone who is having this "input freeze" issue test the following:
Change line 353 from
"for (num_events = XPending(GLWin.dpy);num_events > 0;num_events--) {"
to
"for (num_events = XEventsQueued(GLWin.dpy, QueuedAlready); num_events > 0; num_events--) {"
and see if this fixes the issue?

Sorry. That should have been change line 151 of Source/Plugins/Plugin_VideoOGL/Src/GLUtil.cpp in the aforementioned way. I was looking at the file GLUtil.cpp for the software plugin so I gave the wrong line number, and I forgot to mention the filename.

Nevermind, that probably will fix your input freeze because it really doesn't get any input. So it is not a solution that works.

Okay, lets try this again. Try changing line 151 of Source/Plugins/Plugin_VideoOGL/Src/GLUtil.cpp from
"for (int num_events = XPending(GLWin.dpy); num_events > 0; num_events--) {"
to
"XFlush(GLWin.dpy);
for (int num_events = XEventsQueued(GLWin.dpy, QueuedAlready); num_events > 0; num_events--) {"
Let me know if that helps the input freeze issue.

glenn your last fix is doing it for me, tested with Tatsunoko Vs. Capcom.
Thanks

siliconjoe: Earlier in this issue you said you couldn't reproduce this bug. Have you seen this bug occur? I never have. That is why I am asking those that have seen it to test the code I mentioned in my last comment. It seems to only affect those on Arch Linux with the newer version of libX11.

glennricster: No, it doesn't fix the freeze for me. I say we wait until libX11 is updated in archlinux repos.

glenn: I am seeing it on my recent ubuntu 10.04 (with xorg-edgers ppa). Without the patch it gets so annoying it's impossible to play any game.
On my last report I was using an older ubuntu release with an older xorg version that apparently did not have this bug...
Also switched graphic card/drivers from ATI to NVidia since then, but that shouldn't make any difference

siliconjoe: I see. If it occurs with the xorg-edgers ppa on Ubuntu then I can install that and maybe see if I can find a temporary workaround until (and if) this is fixed upstream.

The fix also didn't fix it for me, though it seemed to do it less.

The update for libx11 seems to not fully remove issue, but it seems to come up less.

This one has been completely resolved, at least for me, in r6218 :)