Hey, tl;dr: When trying to debug the online mode of a PS2 game the game hangs when starting the Kermit dbgcore Packet Pump when booted off the disk. When booted from a harddrive the game hangs when starting the online mode(which is a separate elf.) If the game is modded to boot into the online mode directly the game does not find the Network adapter. I imagine that this is a known issue but I've not found any solutions to this. Googling did point out that its possible a driver issue with some drivers being loaded a second time and that it is related to DNAS. I'd also like to point out this game server is no longer online and we do not actually need to use DNAS(we patch out the call with a cheat code) as we connect to our own (still in progress) server. end tl;dr. More Information: I am working(with some others) on rebuilding the server used with the online mode of Metal Gear Solid 3:Subsistence (2006). We have a server going but there are some responses we have not figured out and have been stuggling to firgure out just by reversing code from memory so we are trying to get some of the debugging features from Kermit dbgcore working. It seems however that we cannot boot into the online mode and have kermit running. Booting dbgcore and running the disk hangs when we try to start the 'Packet Pump.' We can get online but starting the packet pump at any time causes a crash. Booting dbgcore and running the game via ODEM lets us start the 'Packet Pump' however it hangs(regardless of the state of the packet pump) when trying to enter online mode which is a seperate elf. Booting dbgcore and running a modified game that launches the online mode elf first leads to the elf starting but not finding the Network Adapater. The problem with the first case seems to be related to a lack of memory on the retail PS2s so I don't think there is a solution. Yet I'd be more than happen if you know of one. ^_^ The problems of cases 2 and 3(booting from harddrive) seem to be independent of Kermit as the state of the connect has no impact. The issue is reproducable using HDLoader, but OpenPS2Loader will load the game and online mode fine.(Though of course no debugging) Some research indicates that this may be a driver conflict with DNAs. This game did use DNAS when it was online, our server does not require it and we use a cheat code to return immediately from the DNAS check and continue on without it. I would appreciate it if someone might have a solution or information that might help us discover a solution that would allow myself and those I'm working with to run the debugger against the online mode. Thanks, MrGame20 EDIT: Working solution was to have the game disk inserted into the disk drive but to boot from ODEM (ensuring that the option to Kill HDL after start was selected)
The problem is simple: You're running out of memory. Also, IOP debugging on Kermit is extremely limited (guess why ? memory again) and prone to crash. If you stick to the EE side of the game there's a high chance you can obtain useful information. Also, SilverBull will certainly chime in once he see this thread.
If the system hangs after starting the packet pump, it is usually because some DECI2 driver crashed. I assume you are using EE DECI2 only, and have disabled all IOP DECI2 modules? That would eliminate some potential crashes, but unfortunately not all of them. You can try sending EE IF DOWN and IF UP commands, manually, at certain points while the game is running. Or even not starting the packet pump, and doing single-stepping of the host FSM. You may want to enable logging to get an idea where and why it crashes, but I'm afraid I'm the only one who has at least a chance at make some sense of that trace data. Its... strange :very_drunk:. There is a subtle difference between DECI2 on a TOOL and the one provided by dbgcore: on a TOOL, the EE state is reset automatically on IOP reset (that is, the EE IF DOWN command is sent automatically). On retails, the two are completely unconnected, and that's what causing trouble :grief:. With Kermit, both can and must be reset individually from the PC. This was the easiest way for me to implement it, and I regret not implementing it correctly back then, when I still had the time :sorrow:. The problem is that EE IF DOWN resets everything DECI2-related on the EE. Debugger state (target-controlled breakpoints), DECI2 protocol driver registrations, and so on. Games expect that this happens automatically on IOP resets, so they re-register everything afterward. If the command is not sent, those registrations survive IOP reboots, so the immediately following re-registrations fail (the EE DECI2 manager still thinks there is a driver registered). If in this situation and another DECI2 implementation wants to take over, this can prove fatal: the previous game ELF thinks its registrations are gone (due to the IOP having been reset), the new one thinks its registrations failed (because it was told so) and the EE DECI2 manager thinks it still has the old registrations (because the IF DOWN never occured, same as a manual deregistration). Therefore, when the kernel attempts to invoke a DECI2 driver afterward, it will do so with old registration data; and invoke whatever code happens to reside at those locations in memory now :nightmare:. If they have been overwritten by another program, you get a hard-to-diagnose crash.
Thanks l_oliveira and SilverBull, I did try to enable logging and opened up the Debug console and EE Kernel TTY, debug console's output does not change on starting the Packet Pump, EE Kernel TTY simply states KERMIT: DECI2 packet processing has been started. In experimenting with the information you've both brought up I accidentally came across a fairly simple solution that works(when booting from ODEM atleast) Simply having a retail copy of the game in the disk drive when I attempt to access the Online Mode prevents the hang and the EE DECI2 stuff works I've not tested everything but it appears to be good. Thanks a ton.
That probably has to do with the DNAS checking program trying to obtain a disc-id from the drive hardware and you having no disc in it causing a error ... What you think ?
That is what I'm learning towards I figured this had something to do with DNAS...seems a lot of our problems trying to build this server deal with DNAS :dejection: though we are finally moving beyond that. Although I'm not sure its the Disc ID at this point so far as I understand what is going on with DNAS(my focus has mostly been at the network level though) the Disc ID is not read until later when code from the DNAS library is actually executed. The problem point how is in the loading of the elf itself. It could be DNAS is could be due to the routine used to decrypt the elf(its decrypted at run time.) Thinking about it, its possible the decryption routine tries to directly access the disk and that caused the failure. There is of course another question: why would OpenPS2Loader run the game from hdd fine but hdloader and kermit odem would both fail.That seems to indicate to me that the difference is in how the two load the game or redirect read requests.
