HEN issue

[PS3-4K-Pro]

I'm using the v2.6 just fine on CFW, but i switched to HFW with HEN and now when the plugin is enabled if i launch a game. sometimes it gives me a black screen and the system freezes

[TheRouletteBoi]

I believe this is due to PS3 memory limit. Do you load the plugin via boot_plugins or via webman combos?

[PS3-4K-Pro]

I believe this is due to PS3 memory limit. Do you load the plugin via boot_plugins or via webman combos?

I think the same, via boot_plugins

[TheRouletteBoi]

do you remember if this happened with version 2.2?

[PS3-4K-Pro]

do you remember if this happened with version 2.2?

Yeap, it does

[TheRouletteBoi]

So after some investigating this issue only happens when boot_plugins.txt is used with webman mod and HEN.

If I remove webman path from boot plugins the VshFpsCounter.sprx is able to load perfectly without issues. But once both plugins paths are added to boot_plugins.txt I get infinite load when enabling hen. So it looks like webman is using alots of memory on start up or something. I also noticed that HENplugin.sprx is still loaded into memory even after HEN has been enabled so that is something worth looking into.

I will try to fix the unloading code in HENplugin.sprx to see any that does anything.

[TheRouletteBoi]

Alright so fixing the unload code in HENplugin.sprx seems to fix the issue allowing more than 2 boot_plugins to be used. The changes I did was this snippet and if you are on 4.89 CEX HEN you can test this PS3HEN.BIN or you can compile it yourself using the code below in PS3HEN henplugin source code. If you can test and confirm that it is also working on your system I can make a Pull Request to the HEN github so the changes can be applied @LuanTeles .

static void stop_prx_module(void)
{
    sys_prx_id_t prx = prx_get_module_id_by_address(stop_prx_module);
    int *result=NULL;

    uint64_t meminfo[5];
    meminfo[0] = 0x28;
    meminfo[1] = 2;
    meminfo[3] = 0;

    {system_call_6(SC_STOP_PRX_MODULE, (uint64_t)prx, 0, (uint64_t)(uint32_t)meminfo, (uint64_t)(uint32_t)result, 0, NULL);}

}

int henplugin_stop()
{
    sys_ppu_thread_t t_id;
    int ret = sys_ppu_thread_create(&t_id, henplugin_stop_thread, 0, 3000, 0x2000, SYS_PPU_THREAD_CREATE_JOINABLE, STOP_THREAD_NAME);

    uint64_t exit_code;
    if (ret == 0) sys_ppu_thread_join(t_id, &exit_code);

    sys_timer_usleep(7000);
    stop_prx_module();

    _sys_ppu_thread_exit(0);

    return SYS_PRX_STOP_OK;
}

But the plugins still needs to be loaded in memory even after the fix. My guess it is never suppoes to be unloaded? I really don't know. Maybe @aldostools can help us know why the HENplugin.sprx is always persistent

[aldostools]

@TheRoullleteBoi I compared your code with the code used by vsh_menu (which seems to unload fine). The main difference are the priority that you use in sys_ppu_thread_create() and the sleep for 7ms. You have a thread priority of 3000, vsh_menu has 0.

I'm not sure if it affects, but the syscall 482 (SC_STOP_PRX_MODULE) in vsh_menu has 3 parameters instead of 6.

static void finalize_module(void)
{
    uint64_t meminfo[5];

    sys_prx_id_t prx = prx_get_module_id_by_address(finalize_module);

    meminfo[0] = 0x28;
    meminfo[1] = 2;
    meminfo[3] = 0;

    system_call_3(482, prx, 0, (uint64_t)(uint32_t)meminfo);
}

int vsh_menu_stop(void)
{
    sys_ppu_thread_t t;
    uint64_t exit_code;

    int ret = sys_ppu_thread_create(&t, vsh_menu_stop_thread, 0, 0, 0x2000, 1, STOP_THREAD_NAME);
    if (ret == 0) sys_ppu_thread_join(t, &exit_code);

    finalize_module();

    _sys_ppu_thread_exit(0);
    return SYS_PRX_STOP_OK;
}

AFAIK HEN Plugin should unload completely. If it stays resident, it's a bug.

[TheRouletteBoi]

@TheRoullleteBoi I compared your code with the code used by vsh_menu (which seems to unload fine). The main difference are the priority that you use in sys_ppu_thread_create() and the sleep for 7ms. You have a thread priority of 3000, vsh_menu has 0.

I'm not sure if it affects, but the syscall 482 (SC_STOP_PRX_MODULE) in vsh_menu has 3 parameters instead of 6.

static void finalize_module(void)
{
  uint64_t meminfo[5];

  sys_prx_id_t prx = prx_get_module_id_by_address(finalize_module);

  meminfo[0] = 0x28;
  meminfo[1] = 2;
  meminfo[3] = 0;

  system_call_3(482, prx, 0, (uint64_t)(uint32_t)meminfo);
}

int vsh_menu_stop(void)
{
  sys_ppu_thread_t t;
  uint64_t exit_code;

  int ret = sys_ppu_thread_create(&t, vsh_menu_stop_thread, 0, 0, 0x2000, 1, STOP_THREAD_NAME);
  if (ret == 0) sys_ppu_thread_join(t, &exit_code);

  finalize_module();

  _sys_ppu_thread_exit(0);
  return SYS_PRX_STOP_OK;
}

AFAIK HEN Plugin should unload completely. If it stays resident, it's a bug.

unloading VshFpsCounter.sprx is fine but unloading HENplugin.sprx is not working and there is another bug in HENplugin.sprx where it doesn't unloading after being finished updating or whatever HENplugin.sprx does on start-up

[aldostools]

Could you try changing 3000 to -0x1d8 in sys_ppu_thread_create?

Or maybe change SYS_PRX_RESIDENT in henplugin_start to SYS_PRX_NO_RESIDENT

define SYS_PRX_NO_RESIDENT 1

[TheRouletteBoi]

Could you try changing 3000 to -0x1d8 in sys_ppu_thread_create?

Or maybe change SYS_PRX_RESIDENT in henplugin_start to SYS_PRX_NO_RESIDENT #define SYS_PRX_NO_RESIDENT 1

I tried with both changes and still no self unload.

I've also tried adding 'stop_prx_module()' before sys_ppu_thread_exit(0) in henplugin_thread. No luck there

        DPRINTF("Exiting main thread!\n");  
    done=1;

        stop_prx_module();

    sys_ppu_thread_exit(0);

[aldostools]

If you store the prx process id of HEN plugin in a temporary file, you can kill the process from VshFpsCounter using:

define SC_UNLOAD_PRX_MODULE (483)

system_call_3(SC_UNLOAD_PRX_MODULE, prx, 0, NULL);

I'm doing that when the user switch from Lite to Full and viceversa. I had a similar issue and that was the workaround that I found.

If the prx tries to kill itself calling syscall 483, the kernel crashes.

[TheRouletteBoi]

that can be done but that is not a good solution to fixing the HEN plugin bug. I was hoping to fixing this and making a pull request to HEN GitHub

[aldostools]

I agree that it is not a good solution, but if it works then it's THE solution LOL.

[TheRouletteBoi]

@PS3-4K-Pro this issue has been resolved in the open beta of HEN as of 8/22/2022