The above video goes away if you are a member and logged in, so log in now!
Shadow Hearts Hanging and Debugging Tools?
Shadow Hearts Hanging and Debugging Tools? –
I tried out Open Ps2 Loader (v6) on Shadow Hearts: Covenant over SMB the other day (problematic on HDloader). I was happy to find that it passed parts that HDloader would not. However, it did eventually crash. By crashing I mean the audio would continue to play and pause buttons would still function normally, but it would seem to be waiting for more data. I decided to take a wireshark dump since I had some suspicions about file transfers. So I found out that it was hanging consistently after having sent a TCP window resize packet to my pc. Afterward my pc would occasionally send ARP requests for where my ps2 had gone. Besides that the traffic looked pretty normal.
Now I have no idea where else to look to debug this. I'm thinking that the problem is with conflicts between the loader living in a part of memory that the game wants to use. However, I know nearly nothing about what types of problems the location and size of the irx drivers has presented.
So the real question is what are you guys using to see what's going on inside the ps2 when it crashes? Do I need to edit the source to send debugging messages over the network? Sorry for the longish post.
As an aside, I noticed a bit of input lag on the order of 1-2 seconds every time major file transfers occurred. IE: passing from one area to the next, or when a battle loads. Is this because the IOP is busy with the loader code? Sorry if this has come up, I already looked through the issues on the source tracker and the forums here but didn't find anything about input taking time to respond.
Just as info,that game have the same problem while played from hdd and used ops2l
Actually you may already have pinpointed a problem. OPNPS2LD uses networking modules developed for a media player, which may have caused some simplifications of the code that are appropriate for such a program, but not for its current use in OPNPS2LD.
Originally Posted by halfStep
Perhaps the SMS routines rely on TCP window sizes to remain constant from the time a media file connection has been fully established (including initial TCP window size). This would probably be true for most media files played like that, and the exceptions could well match those cases where a modern SMS version sometimes inexplicably hangs (like they unfortunately do sometimes)...
If that is the case then the TCP window handling of those drivers needs to be fixed, or a switch made to alternate drivers.
Best regards: dlanor
I looked at the packets some more, and there doesn't seem to be a significant difference between successful resizes and the one that occurs as the last packet to be sent. This makes it seem like the next read just isn't happening which makes sense since the game seems to run fine but is waiting for data. Wonder what would be hanging up in the core...
I looked at the source some more and found the xprintf stuff in the netlog module. I suppose this is what I was looking for more or less. But since it looks like there's no way to put breakpoints or get a stack trace, what else can I do besides dump the regs? This thing sure looks hard to debug .
Looks like I have too many questions. Too bad I can't find any documentation besides the code. Guess I'll hold my tongue until I read all of it. Never tried learning a project from source before, bout time I started.
I experienced the same hangs using OPNPS2LD IDE HD support: usually a black screen but background music still playing, so I suppose it's not SMB related.
I've tested all the different MDMA/UDMA modes, when trying MDMA0, MDMA1, MDMA2 I experienced an instant hang immediately after loading the game save, with UDMA3 seems to hang randomly between 5 and 10 minutes not only after battles usually on screen changes, subjectively I would say a little better than the default UDMA4 (I should have taken notes).
If I recall correctly, SH2: Covenant started to work only with the last Toxic OS version (I think dlanor can confirm this), I should check some old posts on the forum to be sure.
Similar crashes happen with PCSX2 too, according to this bug report http://code.google.com/p/pcsx2/issues/detail?id=367
and as jimmikaelkael suggested to me in another thread, they point to timing issues in the emulator.
Regarding debug, I think ffgriever does all his debugs decompiling the binaries... ^_^
I've never used more than one ToxicOS version, this being v0.41, so I can't say how earlier ones may have differed from it.
Originally Posted by und0
Best regards: dlanor
My bad dlanor, I don't know why I wrongly recalled you reporting a test for this game with different ToxicOS versions.