Tom Clancy's Ghost Recon® Predator: Various dialog problems

[ghost]

When I arrive at this point and I want to create a new game, it is impossible to write because the FPS go down a lot. I want to choose a letter and it quickly goes to another letter.

I had to put a name at random. Lol!!

Samsung Galaxy Note 8 Oreo 8.0.0 Exynos. ppsspp-v1.8.0-219-g33c53eebe-android.apk To play I use a Dual Shock 4.

[unknownbrackets]

When I arrive at this point and I want to create a new game, it is impossible to write because the FPS go down a lot. I want to choose a letter and it quickly goes to another letter.

I had to put a name at random. Lol!!

Samsung Galaxy Note 8 Oreo 8.0.0 Exynos. ppsspp-v1.8.0-219-g33c53eebe-android.apk To play I use a Dual Shock 4.

It would help to know if this happens on other devices (such as a PC.) It could be that it triggers some performance issue, or it could just be some timing thing.

-[Unknown]

[ghost]

Also the game is too bright even if I enable the "Lower Resolution For Effects" in hack setting 🤔 •GE Dump TC Ghost Recon GE Dump.zip

[ppmeis]

Tested in latest Windows Build. Same keyboard error:

Also I have the same brightness error:

Software render looks fine:

[unknownbrackets]

I assume this must mean the game is calling sceUtilityOskUpdate in a tight loop. It might help to add an HLE delay, or maybe it should actually be doing a frame delay.

It'd be very interesting to know if a real PSP is faster here than most other games...

-[Unknown]

[Panderner]

@Drasikk Please do not close the issues when it's not fixed.

[Panderner]

Same happens on latest build

[Panderner]

Here's a log when I trigger the osk during starting the game

user_main    E[SCEKERNEL]: Util/BlockAllocator.cpp:62 Clearly bogus size: 00000000 - failing allocation

[Panderner]

@Drasikk please reopen

[Panderner]

@hrydgard why is this issue keep closed? It's not yet fixed.

[hrydgard]

I didn't close it, it's not supposed to be closed.

[ghost]

@Drasikk please reopen

Why @Drasikk turn to @ghost 😶

[hrydgard]

He presumably deleted his account.

[Panderner]

@Drasikk please reopen

Why @Drasikk turn to @ghost

The reason, someone in GitHub turn into the @ghost when the accounts are deleted, banned from GitHub or some repositories.

[ghost]

I think the keyboard issue has been solve by using native keyboard in android? see #12696

The remaining issue is the brightness error?

[unknownbrackets]

Even if the native keyboard is an option, I don't think that makes it solved. It's not the default option (and I don't think it should be, since password entry etc. would be broken by that in many games.)

If brightness only happens when slow effects are disabled then it's just a side effect of that hack, not a bug.

-[Unknown]

[ghost]

@unknownbrackets atleast we can enter our username using native keyboard thanks for that 😉

About the brightness error disable slower effect has no effects in this game enable/disable using my phone.

Brightness error still present in the latest git using default settings of ppsspp But when hack settings set to lower resolution for effects (aggressive) brightness error is fixed.

phone specs

Android 6.0.1 Mali-450 GPU OpenGL 2.0

[ghost]

Brightness error disappear if you exit ppsspp and then return 🤔 Watch my video here 👉 https://drive.google.com/file/d/1-16iFIS0-34oYmocae2bawWUSCpQSlmp/view?usp=drivesdk

[ghost]

Brightness error disappear if you exit ppsspp and then return Watch my video here https://drive.google.com/file/d/1-16iFIS0-34oYmocae2bawWUSCpQSlmp/view?usp=drivesdk

@unknownbrackets why brightness error disappear if I exit and return to ppsspp?

If it's true that the brightness error related to disable slower effects? so it's better to remove that option 🤔

[unknownbrackets]

Well, doing that will delete and recreate all framebuffers. It likely means that we have a framebuffer that is old, but we don't realize it's old, and we haven't detected that the game tried to modify it directly through RAM.

-[Unknown]

[ghost]

This is now crashing on the latest build. https://github.com/hrydgard/ppsspp/issues/14864

[ghost]

Tested in latest Windows Build. Same keyboard error:

Also I have the same brightness error:

Software render looks fine:

PPSSPP Latest Build Results.

OPENGL

VULKAN

[ghost]

Entering name issue. tom_clancy.ppdmp.zip

[ppmeis]

Tested in latest build. Same issues.

[ridwan47]

Exact same issue on my Android TV Box

PPSSPP v1.14.4 (armv7) Android 9 CPU: Amlogic S912 GPU: Mali T820MP3

[hrydgard]

Alright, got this game now, and indeed, while at a dialog, it seems to execute 20 frames within the temporal space of one. The sequence of HLE calls is quite simple, stepping through code using Next HLE and copying the calls here yields this sequence:

jal zz_sceUtilityOskUpdate
jal zz_sceDisplayWaitVblankCB
jal zz_sceDisplaySetFrameBuf   (a0 = 0 a1 = 200 a2 = 3 a3 = 0)
jal zz_sceKernelCheckCallback
jal zz_sceGeListEnQueue
jal zz_sceGeListUpdateStallAddr
jal zz_sceGeDrawSync
jal zz_sceKernelLockMutex
jal zz_sceKernelStdout
jal zz_sceIoWrite
jal zz_sceKernelUnlockMutex
jal zz_sceKernelStdout
jal zz_sceIoWrite
jal zz_sceGeDrawSync
jal zz_sceUtilityOskGetStatus
jal zz_sceUtilityOskUpdate

etc.

Breakpointing PPSSPP inside sceDisplayWaitVblankCB, it seems to end up in the second case a lot, with "vblank wait skipped". This seems a little surprising - seems it doesn't wait if we're already inside the vblank period when it gets called, and this causes a quickly repeating sequence of dialog calls until we get out of the vblank time again.

This doesn't seem to be right - I would have expected sceDisplayWaitVblankCB to wait until the next one if we're already inside a vblank period! So I suspect we're emulating it wrong? It doesn't use the sync parameter of sceDisplaySetFramebuf either.

[hrydgard]

Hm, an interesting thing about the game is that it spams the following throughout, at least in the menus:

53:34:991 idle0        I[SCEIO]: HLE\sceIo.cpp:1182 stdout: Error when Lock Mutex. ret = 0x80020064
53:34:991 idle0        I[SCEIO]: HLE\sceIo.cpp:1182 stdout: Error when UnLock Mutex. ret = 0x800201c5

The two error codes are SCE_KERNEL_ERROR_ILLEGAL_CONTEXT and SCE_KERNEL_ERROR_MUTEX_UNLOCKED (latter one is not so mysterious given the first one, but the first one is maybe a bit more unexpected). SCE_KERNEL_ERROR_ILLEGAL_CONTEXT is usually returned when you do something in an interrupt context that you're not supposed to do from there. In this particular case, it's just our generic handler that catches it:

From HLE.cpp:

    } else if ((flags & HLE_NOT_IN_INTERRUPT) && __IsInInterrupt()) {
        RETURN(hleLogDebug(HLE, SCE_KERNEL_ERROR_ILLEGAL_CONTEXT, "in interrupt"));

The logging of that error is what all the stdout/iowrite stuff is for, in the above syscall log. May or may not be relevant, it's hard to say.

The dialog management seems a bit busted in general, maybe related to this failed lock - if you go into a dialog a second time, it'll usually fail (like when cancelling the save dialog after the keyboard dialog):

59:24:004 user_main    E[SCEUTIL]: Dialog\PSPMsgDialog.cpp:47 sceUtilityMsgDialogInitStart: invalid status
59:24:004 user_main    I[SCEUTIL]: HLE\sceUtility.cpp:574 80110001=sceUtilityMsgDialogInitStart(08d0a8a0)
59:24:004 user_main    I[SCEIO]: HLE\sceIo.cpp:1182 stdout: StartYesNoDialog Error: 0x80110001
59:24:005 user_main    E[SCEUTIL]: Dialog\PSPMsgDialog.cpp:47 sceUtilityMsgDialogInitStart: invalid status
59:24:005 user_main    I[SCEUTIL]: HLE\sceUtility.cpp:574 80110001=sceUtilityMsgDialogInitStart(08d0a8a0)
59:24:005 user_main    I[SCEIO]: HLE\sceIo.cpp:1182 stdout: StartYesNoDialog Error: 0x80110001

[unknownbrackets]

This doesn't seem to be right - I would have expected sceDisplayWaitVblankCB to wait until the next one if we're already inside a vblank period! So I suspect we're emulating it wrong? It doesn't use the sync parameter of sceDisplaySetFramebuf either.

There's sceDisplayWaitVblankStartCB specifically to handle the scenario you're expecting. sceDisplayWaitVblankCB does not always wait. Pretty sure there's tests for this, and sceDisplayWaitVblankStartCB would have no reason to exist if sceDisplayWaitVblankCB always waited.

The two error codes are SCE_KERNEL_ERROR_ILLEGAL_CONTEXT and SCE_KERNEL_ERROR_MUTEX_UNLOCKED

Well, you can't lock a mutex inside an interrupt, that makes sense since it can't reschedule. There are tests for this. It'd be nice to JpcspTrace this on a PSP to see what should be happening, though, I guess.

I wonder if something just isn't taking long enough causing some timing issue.

-[Unknown]

[hrydgard]

Tried running the actual physical UMD with the following jpcsptrace config:

sceUtilitySavedataInitStart 0x50C4CD57 1 v
sceUtilityOskInitStart 0xF6269B82 1 v
sceUtilityOskUpdate 0x4B85C861 1 x
sceUtilityOskGetStatus 0x8874DBE0 1 x
sceDisplayWaitVblankCB 0x8EB9EC49 0
sceKernelCheckCallback 0x349d6d6c 0
sceGeListEnQueue 0xAB49E76A 4 xxxx
sceGeListUpdateStallAddr 0xE0D68148 2 xx
sceGeDrawSync 0xB287BD61 1 x
sceKernelLockMutex 0xB011B11F 3 xxx
sceKernelUnlockMutex 0x6B30100F 2 xx

It just hung and there was nothing in the log.

Copying over the iso now.

With the ISO it starts up but impractically slow. Turns out this is a bit too much to catch - the file is full of LockMutex/UnlockMutex, those that I'm interested in. They're not failing though.

Alright, same as above but without lock/unlock and updatestalladdr: log.zip

A bit from the end where the keyboard is visible:

11:29:15.393948 user_main - <- sceGeListEnQueue 0x48C87200, 0x48C87200, 0x0, 0x8BBAC24 = 0x359B3D50
11:29:15.393995 user_main - -> sceGeDrawSync 0x0 = 0x0
11:29:15.394640 user_main - <- sceGeDrawSync 0x0 = 0x0
11:29:15.394688 user_main - -> sceUtilityOskUpdate 0x1 = 0x0
11:29:15.395169 SceDialogmainGraphics - -> sceGeListEnQueue 0x485A2100, 0x485A2100, 0xFFFFFFFF, 0x0 = 0x0
11:29:15.395225 SceDialogmainGraphics - <- sceGeListEnQueue 0x485A2100, 0x485A2100, 0xFFFFFFFF, 0x0 = 0x359B3D10
11:29:15.400114 SceDialogmainGraphics - -> sceGeDrawSync 0x0 = 0x0
11:29:15.400191 SceDialogmainGraphics - <- sceGeDrawSync 0x0 = 0x0
11:29:15.400308 SceDialogmainGraphics - -> sceKernelCheckCallback = 0x0
11:29:15.400338 SceDialogmainGraphics - <- sceKernelCheckCallback = 0x0
11:29:15.400453 user_main - <- sceUtilityOskUpdate 0x1 = 0x0
11:29:15.400488 user_main - -> sceDisplayWaitVblankCB = 0x0
11:29:15.410497 user_main - <- sceDisplayWaitVblankCB = 0x0
11:29:15.410725 user_main - -> sceKernelCheckCallback = 0x0
11:29:15.410935 user_main - <- sceKernelCheckCallback = 0x0
11:29:15.411411 user_main - -> sceGeListEnQueue 0x48C87200, 0x48C87200, 0x0, 0x8BBAC24 = 0x0
11:29:15.411693 user_main - <- sceGeListEnQueue 0x48C87200, 0x48C87200, 0x0, 0x8BBAC24 = 0x359B3ED0
11:29:15.416396 user_main - -> sceGeDrawSync 0x0 = 0x0
11:29:15.417024 user_main - <- sceGeDrawSync 0x0 = 0x0
11:29:15.417082 user_main - -> sceUtilityOskUpdate 0x1 = 0x0
11:29:15.417733 SceDialogmainGraphics - -> sceGeListEnQueue 0x485A2100, 0x485A2100, 0xFFFFFFFF, 0x0 = 0x0
11:29:15.417808 SceDialogmainGraphics - <- sceGeListEnQueue 0x485A2100, 0x485A2100, 0xFFFFFFFF, 0x0 = 0x359B3E90
11:29:15.421969 SceDialogmainGraphics - -> sceGeDrawSync 0x0 = 0x0
11:29:15.422126 SceDialogmainGraphics - <- sceGeDrawSync 0x0 = 0x0
11:29:15.422249 SceDialogmainGraphics - -> sceKernelCheckCallback = 0x0
11:29:15.422279 SceDialogmainGraphics - <- sceKernelCheckCallback = 0x0
11:29:15.422476 user_main - <- sceUtilityOskUpdate 0x1 = 0x0
11:29:15.422513 user_main - -> sceDisplayWaitVblankCB = 0x0
11:29:15.427085 user_main - <- sceDisplayWaitVblankCB = 0x0
11:29:15.427158 user_main - -> sceKernelCheckCallback = 0x0
11:29:15.427185 user_main - <- sceKernelCheckCallback = 0x0
11:29:15.427249 user_main - -> sceGeListEnQueue 0x48C87200, 0x48C87200, 0x0, 0x8BBAC24 = 0x0
11:29:15.427291 user_main - <- sceGeListEnQueue 0x48C87200, 0x48C87200, 0x0, 0x8BBAC24 = 0x359B3E50
11:29:15.427336 user_main - -> sceGeDrawSync 0x0 = 0x0
11:29:15.427980 user_main - <- sceGeDrawSync 0x0 = 0x0
11:29:15.428030 user_main - -> sceUtilityOskUpdate 0x1 = 0x0
11:29:15.428513 SceDialogmainGraphics - -> sceGeListEnQueue 0x485A2100, 0x485A2100, 0xFFFFFFFF, 0x0 = 0x0
11:29:15.428569 SceDialogmainGraphics - <- sceGeListEnQueue 0x485A2100, 0x485A2100, 0xFFFFFFFF, 0x0 = 0x359B3E10
11:29:15.433072 SceDialogmainGraphics - -> sceGeDrawSync 0x0 = 0x0
11:29:15.433315 SceDialogmainGraphics - <- sceGeDrawSync 0x0 = 0x0
11:29:15.433441 SceDialogmainGraphics - -> sceKernelCheckCallback = 0x0
11:29:15.433489 SceDialogmainGraphics - <- sceKernelCheckCallback = 0x0
11:29:15.433586 user_main - <- sceUtilityOskUpdate 0x1 = 0x0
11:29:15.433620 user_main - -> sceDisplayWaitVblankCB = 0x0
11:29:15.443775 user_main - <- sceDisplayWaitVblankCB = 0x0

It seems to be going at 60hz (roughly 17ms between the cycles), so it doesn't seem to be spamming frames like it does in the emulator...

And it looks like WaitVblank is actually waiting each time... Though it might be that the graphics rendering takes long enough to get us out of the vblank zone, while not in PPSSPP. Could eat cycles in the dialog rendering to match ...

[hrydgard]

    // This is the vblank period, plus a little slack. Needed to fix timing bug in Ghost Recon: Predator.
    // See issue #12044.
    hleEatCycles(msToCycles(0.7315 + 0.1));

in sceUtilityOskUpdate fixes the problem.

Still spamming errors from lock/unlock though, throughout, which doesn't happen on the PSP.

[hrydgard]

Actually scratch that ... the lock/unlock errors seem to have disappeared when I reduced the delay (had it at 5ms originally)...

Wait, now they reappeared... Hm.

~However, I got a crash trying to create a save state.~ fixed.

Hm. Plus the game is still too bright. That can curiously be cured by saving and loading state - at which point the brightness will fade away over multiple frames. Very strange.

[ghost]

There's a remaining issue. If you accidentally press start while creating name the screen goes black and cannot recover.

https://user-images.githubusercontent.com/37603562/218991128-114f87ba-53cb-4979-bd09-08f60e195714.mp4

[hrydgard]

Hm. Might be a similar issue with MsgDialogs ("Please input your name")...

[hrydgard]

Nope, not a simple delay issue.

In general, the game seems to have a host of issues with threads and timing.

Now the lock/unlock errors don't seem to happen, or it's random, but here's some assorted logging from startup into the menu:

58:57:076 user_main    I[ME]: HW\MediaEngine.cpp:87 FF: No accelerated colorspace conversion found from yuv420p to rgba.
58:58:312 user_main    E[ME]: HLE\sceMpeg.cpp:1409 UNIMPL sceMpegAvcDecodeFlush(09fff45c)
58:58:312 user_main    W[SCEKERNEL]: HLE\sceKernel.h:462 Kernel: Bad Thread handle -1 (ffffffff)
58:58:312 user_main    E[SCEKERNEL]: HLE\sceKernelThread.cpp:2670 sceKernelWaitThreadEnd - bad thread -1
58:58:312 user_main    E[SCEKERNEL]: HLE\sceKernelThread.cpp:2289 sceKernelDeleteThread(364): thread not dormant
58:58:312 user_main    W[ME]: HLE\sceMpeg.cpp:1945 UNIMPL sceMpegFlushAllStream(09fff45c)
58:58:312 video sound  W[SCEKERNEL]: HLE\sceKernel.h:462 Kernel: Bad Semaphore handle 160168920 (098bfbd8)
58:58:313 video sound  W[SCEKERNEL]: HLE\sceKernel.h:462 Kernel: Bad Semaphore handle 160168920 (098bfbd8)
58:58:313 video sound  W[SCEKERNEL]: HLE\sceKernel.h:462 Kernel: Bad EventFlag handle 363 (0000016b)
58:58:320 user_main    I[ME]: HLE\sceMpeg.cpp:1718 sceMpegFinish(...)
58:58:320 user_main    I[SCEMODULE]: HLE\sceKernelModule.cpp:2209 sceKernelStopModule(00000166, 00000000, 00000000, 00000000, 00000000) - faking
58:58:320 user_main    I[SCEMODULE]: HLE\sceKernelModule.cpp:2271 sceKernelUnloadModule(358)
58:58:326 user_main    I[SCEMODULE]: HLE\sceKernelModule.cpp:2209 sceKernelStopModule(00000165, 00000000, 00000000, 00000000, 00000000) - faking
58:58:326 user_main    I[SCEMODULE]: HLE\sceKernelModule.cpp:2271 sceKernelUnloadModule(357)
58:58:331 user_main    I[SCEMODULE]: HLE\sceKernelModule.cpp:2209 sceKernelStopModule(00000164, 00000000, 00000000, 00000000, 00000000) - faking
58:58:331 user_main    I[SCEMODULE]: HLE\sceKernelModule.cpp:2271 sceKernelUnloadModule(356)
58:58:348 video sound  I[SCEKERNEL]: HLE\sceKernelThread.cpp:2156 sceKernelExitThread(0)
58:58:355 user_main    W[SCEKERNEL]: HLE\sceKernel.h:462 Kernel: Bad Mutex handle 167770768 (09fffa90)
58:58:367 user_main    I[SCEKERNEL]: HLE\sceKernelThread.cpp:2004 369=sceKernelCreateThread(, 08805804, 00000014, 16384, 00000000, 00000000)
58:58:367 user_main    I[SCEKERNEL]: HLE\sceKernelThread.cpp:2101 0=sceKernelStartThread(369, 8, 09fff458)
58:58:376 user_main    W[SCEKERNEL]: HLE\sceKernel.h:462 Kernel: Bad Mutex handle 2037337183 (796f4c5f)
58:58:377 user_main    W[SCEKERNEL]: HLE\sceKernel.h:462 Kernel: Bad Mutex handle 250559744 (0eef3d00)
58:58:557 idle0        W[G3D]: Common\FramebufferManagerCommon.cpp:601 Framebuffer at 04000000/512 has switched associated depth buffer from 00000000 to 04198000, updating.
58:58:576 idle0        I[FRAMEBUF]: Common\FramebufferManagerCommon.cpp:1 Decimating FBO for 04088000 (480x272 8888), age 1011
58:58:576 idle0        I[FRAMEBUF]: Common\FramebufferManagerCommon.cpp:1 Decimating FBO for 04110000 (480x272 8888), age 1010
58:58:638 user_main    W[SCEKERNEL]: HLE\sceKernel.h:462 Kernel: Bad Mutex handle 147436496 (08c9b3d0)
58:58:695 user_main    W[SCEKERNEL]: HLE\sceKernel.h:462 Kernel: Bad Mutex handle 3 (00000003)
58:58:730 user_main    W[SCEKERNEL]: HLE\sceKernel.h:462 Kernel: Bad Mutex handle 1065361613 (3f8020cd)
58:59:000 user_main    W[SCEKERNEL]: HLE\sceKernel.h:462 Kernel: Bad Mutex handle 150916736 (08fece80)
58:59:024 user_main    W[SCEKERNEL]: HLE\sceKernel.h:462 Kernel: Bad Mutex handle 1818650994 (6c666972)
58:59:025 user_main    W[SCEKERNEL]: HLE\sceKernel.h:462 Kernel: Bad Mutex handle 1818650994 (6c666972)
58:59:026 user_main    W[SCEKERNEL]: HLE\sceKernel.h:462 Kernel: Bad Mutex handle 1886284147 (706e6973)
58:59:027 user_main    W[SCEKERNEL]: HLE\sceKernel.h:462 Kernel: Bad Mutex handle 1869903201 (6f747561)
58:59:028 user_main    W[SCEKERNEL]: HLE\sceKernel.h:462 Kernel: Bad Mutex handle 811823459 (30637163)
58:59:029 user_main    W[SCEKERNEL]: HLE\sceKernel.h:462 Kernel: Bad Mutex handle 1886284147 (706e6973)
58:59:030 user_main    W[SCEKERNEL]: HLE\sceKernel.h:462 Kernel: Bad Mutex handle 1869903201 (6f747561)
58:59:031 user_main    W[SCEKERNEL]: HLE\sceKernel.h:462 Kernel: Bad Mutex handle 811823459 (30637163)
58:59:380 user_main    W[SCEKERNEL]: HLE\sceKernel.h:462 Kernel: Bad Mutex handle 538976266 (2020200a)
58:59:435 music thread I[ME]: HLE\sceAtrac.cpp:1970 0=sceAtracSetDataAndGetID(08d0ac00, 00020000): atrac3+ stereo audio

When not inputting a name and thus allowing the msgdialog to start, after the msgdialog closes, you get the following:

01:05:813 user_main    I[SCEUTIL]: HLE\sceUtility.cpp:631 00000000=sceUtilityOskInitStart(08d0ab70)
01:05:957 idle0        I[FRAMEBUF]: Common\FramebufferManagerCommon.cpp:1 Decimating FBO for 04088000 (480x272 8888), age 6
01:06:169 user_main    I[G3D]: Vulkan\VulkanRenderManager.cpp:132 Pipeline (x/1) time on PoolWorker 0: 2.05 ms, 2.09 ms since scheduling  rpType: 0009 sampleBits: 4 (00180000:00000000  VS 00000000:0000000a THR C )
01:07:929 user_main    E[SCEUTIL]: HLE\sceUtility.cpp:159 Utility access thread still running, state: shutting down, dialog=2/1
01:07:929 user_main    I[SCEUTIL]: HLE\sceUtility.cpp:574 00000000=sceUtilityMsgDialogInitStart(08d0a8a0)
01:07:930 idle0        W[SCEKERNEL]: HLE\sceKernel.h:462 Kernel: Bad Thread handle 372 (00000174)
01:07:930 idle0        E[SCEKERNEL]: HLE\sceKernelThread.cpp:1247 __KernelGetWaitID ERROR: thread 372
01:07:930 idle0        W[SCEKERNEL]: HLE\sceKernel.h:462 Kernel: Bad Thread handle 372 (00000174)
01:07:930 idle0        E[SCEKERNEL]: HLE\sceKernelThread.cpp:1227 __KernelGetWaitValue ERROR: thread 372
01:07:930 idle0        W[HLE]: HLE\HLE.cpp:115 Someone else woke up HLE-blocked thread 372?
01:10:535 user_main    E[SCEUTIL]: Dialog\PSPOskDialog.cpp:301 sceUtilityOskInitStart: invalid status
01:10:535 user_main    I[SCEUTIL]: HLE\sceUtility.cpp:631 80110001=sceUtilityOskInitStart(08d0ab70)
01:10:535 user_main    E[SCEUTIL]: Dialog\PSPOskDialog.cpp:301 sceUtilityOskInitStart: invalid status
01:10:535 user_main    I[SCEUTIL]: HLE\sceUtility.cpp:631 80110001=sceUtilityOskInitStart(08d0ab70)
01:10:536 user_main    E[SCEUTIL]: Dialog\PSPOskDialog.cpp:301 sceUtilityOskInitStart: invalid status
01:10:536 user_main    I[SCEUTIL]: HLE\sceUtility.cpp:631 80110001=sceUtilityOskInitStart(08d0ab70)
01:10:536 user_main    E[SCEUTIL]: Dialog\PSPOskDialog.cpp:301 sceUtilityOskInitStart: invalid status
01:10:536 user_main    I[SCEUTIL]: HLE\sceUtility.cpp:631 80110001=sceUtilityOskInitStart(08d0ab70)
01:10:552 user_main    E[SCEUTIL]: Dialog\PSPOskDialog.cpp:301 sceUtilityOskInitStart: invalid status

and then it loops forever.

Like the msgdialog wasn't properly shut down, preventing the oskdialog from working.