Emulator Issues #5583
closed
Freeze when saving/loading Baten Kaitos
Added by kurisui over 12 years ago.
Relates to performance:
No
Relates to maintainability:
No
Description
- Game Name and ID (as it appears in right click > properties:
Baten Kaitos
"GKBEAF"
2) What is the expected output? What do you see instead?
Save progress bar filling up and then being replaced with "Save Complete". Instead the progress bar doesn't update.
3) Did the game ever work correctly (i.e. not have this problem) on an
earlier version of dolphin? Please specify the exact revision when the
problem began.
It works in 3.0-692 and earlier.
4) What steps will reproduce the problem?
- Go to save point.
- Attempt to save.
3.
5) What version of dolphin are you using (32bit/64bit along with the
version as it appears in the title bar, etc)? Do not say 'latest version'
this changes multiple times a day.
On what operating system, drivers, and hardware? Be sure to list OS,
graphics driver information, and video card model if you are having
graphics problems, for example.
3.0-700-751
Windows 7 x64
- Status changed from New to Accepted
Confirmed, most likely another regression from aram-dma-fixes.
As expected, git bisect confirms the issue comes from rda4141aa9f25.
Also broken by that commit: intro movie sound with DSPHLE. DSPLLE fixes that issue but does not fix the save problem.
Some OSREPORT output from the game when the freeze happens:
55:17:828 ../Source/Core/Core/Src/HW/EXI_DeviceIPL.cpp:297 N[OSREPORT]: CMNSlot : PHASE_READY2SLEEP END
55:20:646 ../Source/Core/Core/Src/HW/EXI_DeviceIPL.cpp:297 N[OSREPORT]: CMCGetXferredBytes = 0
55:20:662 ../Source/Core/Core/Src/HW/EXI_DeviceIPL.cpp:297 N[OSREPORT]: SaveData Serialize : FAT[0] Addr=80248d10, Size=93d0
55:20:662 ../Source/Core/Core/Src/HW/EXI_DeviceIPL.cpp:297 N[OSREPORT]: SaveData Serialize : FAT[1] Addr=8049f5e0, Size=2300
55:20:662 ../Source/Core/Core/Src/HW/EXI_DeviceIPL.cpp:297 N[OSREPORT]: SaveData Serialize : FAT[4] Addr=8025ec98, Size=500
55:20:662 ../Source/Core/Core/Src/HW/EXI_DeviceIPL.cpp:297 N[OSREPORT]: SaveData Serialize : FAT[5] Addr=80261838, Size=10
55:20:663 ../Source/Core/Core/Src/HW/EXI_DeviceIPL.cpp:297 N[OSREPORT]: SaveData Serialize : FAT[6] Addr=80258c78, Size=100
55:20:663 ../Source/Core/Core/Src/HW/EXI_DeviceIPL.cpp:297 N[OSREPORT]: CMCU CRCWrite = 1e64
55:20:679 ../Source/Core/Core/Src/HW/EXI_DeviceIPL.cpp:297 N[OSREPORT]: CMCU CRCWrite = d125
55:20:680 ../Source/Core/Core/Src/HW/EXI_DeviceIPL.cpp:297 N[OSREPORT]: CMCU CheckSum = 2410165,65532
55:20:680 ../Source/Core/Core/Src/HW/EXI_DeviceIPL.cpp:297 N[OSREPORT]: Temporary File Name : BKData8h4eI
55:20:694 ../Source/Core/Core/Src/HW/EXI_DeviceIPL.cpp:297 N[OSREPORT]:
55:20:698 ../Source/Core/Core/Src/HW/EXI_DeviceIPL.cpp:297 N[OSREPORT]: CMCGetXferredBytes = 122880
55:20:703 ../Source/Core/Core/Src/HW/EXI_DeviceIPL.cpp:297 N[OSREPORT]: CMCGetXferredBytes = 122880
55:20:715 ../Source/Core/Core/Src/HW/EXI_DeviceIPL.cpp:297 N[OSREPORT]: CMCGetXferredBytes = 122880
55:20:730 ../Source/Core/Core/Src/HW/EXI_DeviceIPL.cpp:297 N[OSREPORT]: CMCGetXferredBytes = 122880
55:20:747 ../Source/Core/Core/Src/HW/EXI_DeviceIPL.cpp:297 N[OSREPORT]: CMCGetXferredBytes = 122880
55:20:764 ../Source/Core/Core/Src/HW/EXI_DeviceIPL.cpp:297 N[OSREPORT]: CMCGetXferredBytes = 122880
55:20:785 ../Source/Core/Core/Src/HW/EXI_DeviceIPL.cpp:297 N[OSREPORT]: CMCGetXferredBytes = 122880
55:20:798 ../Source/Core/Core/Src/HW/EXI_DeviceIPL.cpp:297 N[OSREPORT]: CMCGetXferredBytes = 122880
55:20:814 ../Source/Core/Core/Src/HW/EXI_DeviceIPL.cpp:297 N[OSREPORT]: CMCGetXferredBytes = 122880
55:20:831 ../Source/Core/Core/Src/HW/EXI_DeviceIPL.cpp:297 N[OSREPORT]: CMCGetXferredBytes = 122880
55:20:847 ../Source/Core/Core/Src/HW/EXI_DeviceIPL.cpp:297 N[OSREPORT]: CMCGetXferredBytes = 122880
55:20:864 ../Source/Core/Core/Src/HW/EXI_DeviceIPL.cpp:297 N[OSREPORT]: CMCGetXferredBytes = 122880
55:20:880 ../Source/Core/Core/Src/HW/EXI_DeviceIPL.cpp:297 N[OSREPORT]: CMCGetXferredBytes = 122880
There does not seem to be any ARAM DMA done during the save, which indicates it's most likely an external exception being inhibited or something along those lines.
Reverting the DSP.cpp changes from rda4141aa9f25 do not fix it, so this is definitely an external exception timing issue. The behavior introduced by rda4141aa9f25 in that regard should be more more precise though, this may be an issue in the EXI code handling memcards.
After giving that issue a bit more thought, it's most likely because memcards operations delays are not emulated. Now that the exceptions are checked more often this might have been enough to break the games assumptions.
- Status changed from Accepted to Fixed
This issue was closed by revision 0b00c95b79dd.
Your amazing! That is some efficient debugging!
This issue was closed by revision 760f777f5a08.
Also available in: Atom
PDF