Gundam Battle Universe Crash

[Tktw]

crash after this screen

ppsspp-v0.9.9.1-1061-gea63719

I'm sorry
I can't explain well

[daniel229]

This unknownbrackets@337b34e broke it.

[hrydgard]

Urgh, timing issues then...

[Tktw]

I tried the old version.
v0.9.9.1-166-gabe08c9 OK
v0.9.9.1-185-gc02f1ca Crash

[unknownbrackets]

It must be that something else is executing too quickly and trying to enqueue before the block transfer is done.

I wonder if it should only say stack address already used if the list is stalled or something. Don't think we have tests on that...

-[Unknown]

[daniel229]

If the debuglog would help
(rename jpg to rar)

[unknownbrackets]

Hmm. Something here doesn't make sense.

19:49:261 drawloading  D[SCEGE]: HLE\sceGe.cpp:439 sceGeListEnQueue(addr=48af2f80, stall=48af2f80, cbid=00000000, param=08aa0648)
19:49:261 drawloading  D[G3D]: GPUCommon.cpp:690 Okay, starting DL execution at 08af2f80 - stall = 08af2f80
// Okay, at this point it's not drawn anything, started stalled.
19:49:262 drawloading  D[SCEGE]: HLE\sceGe.cpp:485 sceGeListUpdateStallAddr(dlid=889192474, stalladdr=48af2f94)
19:49:262 drawloading  D[G3D]: GPUCommon.cpp:690 Okay, starting DL execution at 08af2f80 - stall = 08af2f94
// Now it's executed some and hit the next stall.  Just 0x14 bytes.
19:49:262 drawloading  D[G3D]: GPUCommon.cpp:834 Signal without wait. signal/end: 0000 0000
// GE interrupt.  But, I don't see it trigger right away.
19:49:262 drawloading  D[SCEGE]: HLE\sceGe.cpp:485 sceGeListUpdateStallAddr(dlid=889192474, stalladdr=48af2f9c)
19:49:262 drawloading  D[G3D]: GPUCommon.cpp:690 Okay, starting DL execution at 08af4050 - stall = 08af2f9c
// Okay, how did it get all the way to 0x08af4050?  Did it jump there?  Is this related to the signal?
19:49:262 idle0        D[CPU]: HLE\sceGe.cpp:185 Entering GE interrupt handler 089c7918
// Finally we have the GE interrupt hit.
19:49:262 drawloading  D[SCEGE]: HLE\sceGe.cpp:498 sceGeDrawSync(mode=0)  (0=wait for completion, 1=peek)
// Okay, now it should sync until the list is done (or hang if it's never done.)
19:49:263 drawloading  D[KERNEL]: HLE\sceKernelThread.cpp:3260 Context switch: idle0 -> drawloading thread (272->323, pc: 08000000->0880633c, entered vblank) +214us
// Woke up, that means drawsync completed.
19:49:263 drawloading  D[SCEGE]: HLE\sceGe.cpp:439 sceGeListEnQueue(addr=48af2f80, stall=48af2f80, cbid=00000000, param=08aa0648)
19:49:263 drawloading  E[G3D]: GPUCommon.cpp:226 sceGeListEnqueue: can't enqueue, stack address 09F22288 already used
// How come?  Didn't we just finish all drawing?  It seems likely this is the same list / stack address from before.

-[Unknown]

[daniel229]

Fixed in #7217

[unknownbrackets]

Really? So it wasn't timing related at all? I thought this one was even with vfpusimd off.

-[Unknown]

[daniel229]

No,just get lucky last time.

[unknownbrackets]

Well, that's cool. Closing then.

-[Unknown]

[daniel229]

I mean no,It's not fixed.

[unknownbrackets]

Oh, ok, misunderstood. Yeah, timing issues can be tricky when they sometimes work.

In the GE debugger, when it says sceGeListEnqueue: can't enqueue, stack address 09F22288 already used, what does the display lists tab show?

-[Unknown]

[daniel229]

I step frame to when it sayssceGeListEnqueue: can't enqueue, stack address 09F22288 already used,display list show these.

[unknownbrackets]

Err, sorry, I meant the "Lists" tab. I want to know which lists are active.

But, that's useful, so it's a finish right after a call... interesting.

-[Unknown]

[daniel229]

Lists tab nothing

[unknownbrackets]

Hmm. What if you change:

                } else if (stackAddr != 0 && dls[i].stackAddr == stackAddr && !dls[i].pendingInterrupt) {
                    ERROR_LOG(G3D, "sceGeListEnqueue: can't enqueue, stack address %08X already used", stackAddr);
                    return 0x80000021;
                }

In GPUCommon.cpp, to:

                } else if (stackAddr != 0 && dls[i].stackAddr == stackAddr && !dls[i].pendingInterrupt) {
                    ERROR_LOG(G3D, "sceGeListEnqueue: can't enqueue, stack address %08X already used", stackAddr);

                    for (int j = 0; j < DisplayListMaxCount; ++j) {
                        WARN_LOG(G3D, " * List #%d state: %d, pc: %08x (from %08x), pending int: %d, started: %d, stackAddr: %08x", dls[j].id, dls[j].state, dls[j].pc, dls[j].startpc, dls[j].pendingInterrupt, dls[j].started, dls[j].stackAddr);
                    }

                    return 0x80000021;
                }

What lists does it spit out? I'm just wondering what is blocking it.

-[Unknown]

[daniel229]

Get these log
https://gist.github.com/daniel229/17670e040f5c578988f4

[unknownbrackets]

Hmm. And this is without multithreaded right? That status means "running".

It's also not "pending interrupt." State would be set to 3 if there was no interrupt, and otherwise pending interrupt would be true. If there was an interrupt, when it ran it should've triggered the state to change to 3. Before that, pending interrupt would be true.

So, that combination (RUNNING/state 2 + after a FINISH cmd + pending interrupt = false) should not be possible. Whatever is causing that is most likely the bug.

I can try to recommend some logging changes, but a bit busy this week so might have to come back to it. Ideally I want to know when pendingInterrupt changes on that list, and when and to what values state changes.

-[Unknown]

[daniel229]

Right,without multithreaded.

[unknownbrackets]

Hmm, I'm not sure where to log without burying it in so much log data that it'll be super slow.

unknownbrackets@722c33f

This'll probably be pretty slow, I'm really just interested in the last lines of the log.

-[Unknown]

[daniel229]

The log
https://gist.github.com/daniel229/7d4cb23c380b9a57e5cc

[unknownbrackets]

Interesting. There seems to be a SIGNAL, and then it jumps back into running. After that it hits the FINISH and seemingly the original SIGNAL causes it to clear the flag.

So, the problem seems to be that it's running a list that has a pending interrupt. What happens if you go back to master, and change GPU/GPUCommon.cpp:

    if (list.state == PSP_GE_DL_STATE_PAUSED)
        return false;

To:

    if (list.state == PSP_GE_DL_STATE_PAUSED || list.pendingInterrupt)
        return false;

If that doesn't work, can you apply that change on top of 722c33f, and give me the new log?

If it does work... I'm unsure if it's correct or not. Testing things related to what happens in interrupts is always a wonderful trip down wearing out my poor psp's power switch even more...

-[Unknown]

[daniel229]

Great,it works,I rerun it for over 10 times,not hang anymore.

[issuer]

Excuse me but is this fixed? Since the issue is still open i thought isn't fixed yet.
If it helps, i fixed the freezing/hanging issue in the Gundam Battle games (which use the same engine) in old builds by enabling Sound Speed Hack in Audio.

[unknownbrackets]

Still haven't tested this on real hardware. It's hard to test. I'm thinking this change may be safe.

I don't know much about that hack but as long as a hack is needed it's a bug.

-[Unknown]

[issuer]

Seems fixed on 1.0. Played this game for 1 hour straight and i'm already on 20 hours in Gundam Assault Survive which had this same issue (all the Gundam Battle games use the same engine, including the Macross games).

I won't close this issue but +1 to fixed.

[daniel229]

Other gundam battle games seem different.Gundam Assault Survive random hangs in battle fixed long time ago.

[issuer]

I've just noticed that. Seems completely random, just crashed on the second try. Same settings as the first try. This issue is not fixed yet.

[daniel229]

Changing cpu clock to 85 or 1000 helps it

[DarkD]

There's a lot of issues opened for this game and only one opened. Yet it still freezes(at least on default settings, though tweaking 'em doesn't helps). Screens are taken from after confirming first mission's start.


With debug log it spams those two lines:
17:12:883 user_main D[KERNEL]: HLE\sceKernelThread.cpp:2343 1=sceKernelSuspendDispatchThread()
17:12:883 user_main D[KERNEL]: HLE\sceKernelThread.cpp:2358 sceKernelResumeDispatchThread(1) - from 0

Hopefully that'll help to get rid of this nasty freeze for good.

[FonSpaak]

Is there a way to implement the game fix on ppsspp 1.1.1 version for android? if there is, i would like to know how to implement the fix on the game.

[Halcon0Negro]

stil freeze in v1.2.1-31-g9bde45d...

[Kryse-777]

well, I got to the settings and went YOLO in all clicking the settings, thankfully, in 1 instance, I managed to run it smoothly, sadly, the moment reopened it, it never ran again, a sad life it is

[FonSpaak]

It's been confirmed that the newest of the Gundam battle series, Gundam Assault Survive™ is working well on the latest build on PPSSPP, although it lags, there is no issues on crashing, something seems to be a bit off on the two titles,
Well, Tweaking the settings might be worth it, or we could wait for the next PPSSPP Build, see if it solve the crash on Gundam Battle Universe™

[FonSpaak]

Report For ULJS-00145
Phone Model: 7040N
CPU: ARM7 Processor rev 3 (7l)
Cores: 4
3D API: OpenGl ES
Vendor: Qualcomm

PSP Ver. 1.2.2.0
Game title: Gundam Battle Universe™
Game ID: ULJS00145
Region: Japan
Status Report: Same As Before (Freeze before Commencing Mission)
Personal Comments: As of the latest versions of the PPSSPP, ULJS-00145 has been rendered from Playable to Menus Only, As there is no way that i could fix the problem present on ULJS-00145, Tried Switching the settings from Skip Buffered Rendering to Buffered Rendering, switching to Buffered Rendering will show you a black screen. ( Reverting to a save state might solve this. )Main problem begins when starting the script for a mission, in which it will make the PPSSPP seize functions and from there, it will force close. ENDING REPORT/ASSISTANCE NEEDED

[DarkD]

As I promised to Daniel229 in Chronicle issue discussion I found what tweak makes game playable and not freeze on mission load - it's PSP's CPU clock being set at 1000, need to check if that'll work for Chronicle's issue too...

[finansar222]

อยากลองเล่นเกม..แต่ทำไมเล่นไม่ได้

[DarkD]

And this one works without any issues.

[unknownbrackets]

I think the correct fix for this issue is now in #12160.

-[Unknown]

[LunaMoo]

Still crashes without the hack.