Pablo Curiel

If you have a Discord handle, we can continue these tests over there - real time communication isn't very optimal here.

@drizzt Someone else was able to reproduce this very same crash using a drive that supports Mode Sense commands. I took a closer look at the problem, and turns out...

This has been a tough nut to crack so far. I have spent hours trying to find the source of the problem (which is definitely related to fsp-srv) to no...

According to some tests, it seems that the source of the problem are the calls to GetGameCardHandle (IDeviceOperator cmd 202). If it isn't called at least once, the game card...

Upon further inspection, it seems the source of the problem is *not* the GetGameCardHandle IPC call, but rather the OpenGameCardStorage call (IFileSystemProxy cmd 30). It doesn't matter if at least...

@DanielC-08 It's out of the question. In the end, it's faster to just take out the gamecard and reinsert it. A proper fix would be preferred.

After asking SciresM about the potential source of this problem, he said: ``` Pretty sure this is because opening a gc handle reinitializes lotus comms and so normal gamecard usage...

@Thealexbarney let us know about the internal `nn::gcsrv` interface available within `fs`, as well as the [implementation](https://github.com/Thealexbarney/LibHac/tree/c5ff61bd89192bd502721cbcf9f7f1b8d9f3dfc2/src/LibHac/GcSrv) he came up with in LibHac a few months ago. This means we...

There's a problem with this. The application currently uses IPC calls to filesystem services in order to retrieve raw data sectors from the gamecard storage. However, a separate gamecard controller...

For the time being, I'm gonna leave this issue open. If new information related to this topic comes to light, I'll make sure to update this issue status.