fix: kernel panic during rest mode (impl. pause/resume system)

hadobedo commented

2026-04-30 16:06:22 -05:00

(Migrated from github.com)

Attempts to fix rest/wake causing KP's (on lower FWs*)
*Unsure if rest mode KP issue affects just low FWs or ALL FW's
Mentioned in issue #23

Changes:

monitors SceSystemStateMgrInfo for shellcore states 200, 300 & 500 in sm_shellcore_flags.c
triggers a library re-sync/re-scan on wake via request_power_resume in main.c to rescan on wake (just in case)
intentionally skips unmounting virtual drives + clearing /user/app links during rest mode transition states; forcefully unmounting them while Shellcore prepares for sleep consistently led to black screens/'no signal' on wake for me. seems that letting the kernel manage the mounts 'natively' (ie do nothing) during rest mode is stable* (on FW 4.51 at least)
implements wait loop in main.c (a la etaHEN) for rest mode which freezes background app polling, thread activity

**UPDATE: Attempted to further harden rest/wake transitions, the initial implementation naively only halted new scans/mounts but not in-progress ones. now we attempt to catch and abort in-progress operations too)

**new changes (2026-05-03):

added should_pause_work() which checks for both application shutdown and sleep/wake states.
replaced should_stop_requested() checks with should_pause_work() throughout sm_install.c, sm_scan.c, and sm_scanner.c to prevent the scanner/installer from attempting to continue processing of queues during rest mode
updated sm_scanner_run_loop so that if a scan aborts halfway through due to rest mode toggle, it triggers 'deferral' and safely sleeps rather than just breaking the loop
added abort checks inside the sm_image.c mount pipeline to detach and abort if rest mode is triggered mid-mount

Tested only on phat PS5 on FW 4.51 [.exfat/.ffpkg apps, internal m.2, backpork games] and seems to work

Needs to be tested & verified on higher FW's & different setups (ie. external SSD, folder-style app backups, different mount backends etc) to ensure that this new logic doesn't break anything (I don't think it would 🤞)

You can download the latest test build from my fork's GitHub Actions here

Attempts to fix rest/wake causing KP's (on lower FWs*) _*Unsure if rest mode KP issue affects just low FWs or ALL FW's_ Mentioned in [issue #23](https://github.com/drakmor/ShadowMountPlus/issues/23) Changes: - monitors `SceSystemStateMgrInfo` for shellcore states `200`, `300` & `500` in `sm_shellcore_flags.c` - triggers a library re-sync/re-scan on wake via `request_power_resume` in `main.c` to rescan on wake (just in case) - intentionally skips unmounting virtual drives + clearing `/user/app` links during rest mode transition states; forcefully unmounting them while Shellcore prepares for sleep consistently led to black screens/'no signal' on wake for me. seems that letting the kernel manage the mounts 'natively' (ie do nothing) during rest mode is stable* (on FW 4.51 at least) - implements wait loop in `main.c` (a la etaHEN) for rest mode which freezes background app polling, thread activity \****UPDATE:** Attempted to further harden rest/wake transitions, the initial implementation naively only halted **new** scans/mounts but not _in-progress_ ones. now we attempt to catch and abort _in-progress operations_ too) \****new changes (2026-05-03)**: - added `should_pause_work()` which checks for both application shutdown and sleep/wake states. - replaced `should_stop_requested()` checks with `should_pause_work()` throughout `sm_install.c`, `sm_scan.c`, and `sm_scanner.c` to prevent the scanner/installer from attempting to continue processing of queues during rest mode - updated `sm_scanner_run_loop` so that if a scan aborts halfway through due to rest mode toggle, it triggers 'deferral' and safely sleeps rather than just breaking the loop - added abort checks inside the `sm_image.c` mount pipeline to detach and abort if rest mode is triggered mid-mount Tested only on phat PS5 on FW 4.51 [`.exfat`/`.ffpkg` apps, internal m.2, backpork games] and _seems to work_ Needs to be tested & verified on higher FW's & different setups (ie. external SSD, folder-style app backups, different mount backends etc) to ensure that this new logic doesn't break anything (I don't think it would 🤞) You can download the latest test build from my fork's GitHub Actions [here](https://github.com/hadobedo/ShadowMountPlus/actions/workflows/ps5.yml)

nhpt98 commented

2026-05-01 02:39:18 -05:00

(Migrated from github.com)

The issue still persists on my fat 5.50. Using with etahen 2.6b.

hadobedo commented

2026-05-01 02:47:58 -05:00

(Migrated from github.com)

The issue still persists on my fat 5.50. Using with etahen 2.6b.

oops, can u provide the debug logs from the shadowmount folder as well as ur shadowmount config (if it isn't just the default)? ty🙏

> The issue still persists on my fat 5.50. Using with etahen 2.6b. oops, can u provide the debug logs from the shadowmount folder as well as ur shadowmount config (if it isn't just the default)? ty🙏

nhpt982-beep commented

2026-05-01 02:54:54 -05:00

(Migrated from github.com)

The issue still persists on my fat 5.50. Using with etahen 2.6b.

oops, can u provide the debug logs from the shadowmount folder as well as ur shadowmount config (if it isn't just the default)? ty🙏

I use both the shadowmount on your #33 and #34 but still experience panic. My config is default. Pls find attached file for debug. Thank you very much for your time!
debug.log

> > The issue still persists on my fat 5.50. Using with etahen 2.6b. > > oops, can u provide the debug logs from the shadowmount folder as well as ur shadowmount config (if it isn't just the default)? ty🙏 I use both the shadowmount on your #33 and #34 but still experience panic. My config is default. Pls find attached file for debug. Thank you very much for your time! [debug.log](https://github.com/user-attachments/files/27271386/debug.log)

nhpt98 commented

2026-05-01 03:04:38 -05:00

(Migrated from github.com)

The issue still persists on my fat 5.50. Using with etahen 2.6b.

oops, can u provide the debug logs from the shadowmount folder as well as ur shadowmount config (if it isn't just the default)? ty🙏

I tried again by loading shadowmountplus through etaHEN rather than autoload. The device survive into rest mode but couldn't come up, using latest #34 artifact.

> > The issue still persists on my fat 5.50. Using with etahen 2.6b. > > oops, can u provide the debug logs from the shadowmount folder as well as ur shadowmount config (if it isn't just the default)? ty🙏 I tried again by loading shadowmountplus through etaHEN rather than autoload. The device survive into rest mode but couldn't come up, using latest #34 artifact.

drakmor commented

2026-05-03 04:45:16 -05:00

(Migrated from github.com)

Thank you. I'll check it out later this week.

hadobedo commented

2026-05-03 20:33:49 -05:00

(Migrated from github.com)

@nhpt98 @nhpt982-beep i pushed an updated build to my actions, lmk if it works any better for you 🙏 https://github.com/hadobedo/ShadowMountPlus/actions/runs/25293637750

@nhpt98 @nhpt982-beep i pushed an updated build to my actions, lmk if it works any better for you :pray: https://github.com/hadobedo/ShadowMountPlus/actions/runs/25293637750

nhpt982-beep commented

2026-05-04 00:56:47 -05:00

(Migrated from github.com)

@nhpt98 @nhpt982-beep i pushed an updated build to my actions, lmk if it works any better for you 🙏 https://github.com/hadobedo/ShadowMountPlus/actions/runs/25293637750

First of all, I sincerely thank you and @drakmor for your significant contributions to the scene. I have tested the updated build and can fully confirm that it works on 5.50 with etaHEN 2.6b and kstuff lite 1.1dr. However, I did notice that there were freezes and 'system error' upon consecutive rest mode tests, especially when paired with etaHEN toolbox. I believe that such instability might stem from the inherent incompatibility between etaHEN and shadowmountplus, not from your build. Please find attached klog file for your further reference.
Once again, thank you very much brother @hadobedo .
debug.log

> @nhpt98 @nhpt982-beep i pushed an updated build to my actions, lmk if it works any better for you 🙏 https://github.com/hadobedo/ShadowMountPlus/actions/runs/25293637750 First of all, I sincerely thank you and @drakmor for your significant contributions to the scene. I have tested the updated build and can fully confirm that it works on 5.50 with etaHEN 2.6b and kstuff lite 1.1dr. However, I did notice that there were freezes and 'system error' upon consecutive rest mode tests, especially when paired with etaHEN toolbox. I believe that such instability might stem from the inherent incompatibility between etaHEN and shadowmountplus, not from your build. Please find attached klog file for your further reference. Once again, thank you very much brother @hadobedo . [debug.log](https://github.com/user-attachments/files/27331132/debug.log)

hadobedo commented

2026-05-04 02:38:16 -05:00

(Migrated from github.com)

@nhpt98 @nhpt982-beep i pushed an updated build to my actions, lmk if it works any better for you 🙏 hadobedo/ShadowMountPlus/actions/runs/25293637750

First of all, I sincerely thank you and @drakmor for your significant contributions to the scene. I have tested the updated build and can fully confirm that it works on 5.50 with etaHEN 2.6b and kstuff lite 1.1dr. However, I did notice that there were freezes and 'system error' upon consecutive rest mode tests, especially when paired with etaHEN toolbox. I believe that such instability might stem from the inherent incompatibility between etaHEN and shadowmountplus, not from your build. Please find attached klog file for your further reference. Once again, thank you very much brother @hadobedo . debug.log

very good to hear :) i also see the 'system error' popup after injecting the fork alongside other payloads (about ~5-10% of the time) but it usually happens when shadowmountplus & etaHEN is injected in quick succession (in my experience)

but yes, anecdotally it really does seem that it does occur on my fork more often vs. original codebase, so i'll look over my changes again asap 👍

> > @nhpt98 @nhpt982-beep i pushed an updated build to my actions, lmk if it works any better for you 🙏 [hadobedo/ShadowMountPlus/actions/runs/25293637750](https://github.com/hadobedo/ShadowMountPlus/actions/runs/25293637750) > > First of all, I sincerely thank you and @drakmor for your significant contributions to the scene. I have tested the updated build and can fully confirm that it works on 5.50 with etaHEN 2.6b and kstuff lite 1.1dr. However, I did notice that there were freezes and 'system error' upon consecutive rest mode tests, especially when paired with etaHEN toolbox. I believe that such instability might stem from the inherent incompatibility between etaHEN and shadowmountplus, not from your build. Please find attached klog file for your further reference. Once again, thank you very much brother @hadobedo . [debug.log](https://github.com/user-attachments/files/27331132/debug.log) very good to hear :) i also see the 'system error' popup after injecting the fork alongside other payloads (about ~5-10% of the time) but it usually happens when shadowmountplus & etaHEN is injected in quick succession (in my experience) but yes, anecdotally it really does seem that it does occur on my fork more often vs. original codebase, so i'll look over my changes again asap :+1:

❤️ 1

hadobedo commented

2026-05-09 14:59:55 -05:00

(Migrated from github.com)

Since updating to Y2JB Autoloader v0.5 and loading payloads (incl. the shadowmountplus fork) using pldmgr-v0.1.1, I haven't experienced the 'system error' popup at all (tested on FW 4.51 & FW 8.00) 👍

I think the error was being caused and/or exacerbated by older Y2JB autoloader versions' 'instability' when launching etaHEN from inside the YouTube app

Since updating to [Y2JB Autoloader v0.5](https://github.com/itsPLK/ps5-y2jb-autoloader/releases/tag/v0.5) and loading payloads (incl. the shadowmountplus fork) using [pldmgr-v0.1.1](https://github.com/itsPLK/ps5-payload-manager), I haven't experienced the 'system error' popup at all (tested on FW 4.51 & FW 8.00) :+1: I think the error was being caused and/or exacerbated by [older Y2JB autoloader versions' 'instability' when launching etaHEN](https://github.com/itsPLK/ps5-y2jb-autoloader#additional-info) from inside the YouTube app

❤️ 1

nhpt98 commented

2026-05-09 21:36:42 -05:00

(Migrated from github.com)

Since updating to Y2JB Autoloader v0.5 and loading payloads (incl. the shadowmountplus fork) using pldmgr-v0.1.1, I haven't experienced the 'system error' popup at all (tested on FW 4.51 & FW 8.00) 👍

I think the error was being caused and/or exacerbated by older Y2JB autoloader versions' 'instability' when launching etaHEN from inside the YouTube app

Did you do shadowmount or etaHEN first brother?

> Since updating to [Y2JB Autoloader v0.5](https://github.com/itsPLK/ps5-y2jb-autoloader/releases/tag/v0.5) and loading payloads (incl. the shadowmountplus fork) using [pldmgr-v0.1.1](https://github.com/itsPLK/ps5-payload-manager), I haven't experienced the 'system error' popup at all (tested on FW 4.51 & FW 8.00) 👍 > > I think the error was being caused and/or exacerbated by [older Y2JB autoloader versions' 'instability' when launching etaHEN](https://github.com/itsPLK/ps5-y2jb-autoloader#additional-info) from inside the YouTube app Did you do shadowmount or etaHEN first brother?

drakmor commented

2026-05-10 10:26:12 -05:00

(Migrated from github.com)

Thx!
github.com/drakmor/ShadowMountPlus@9fa6ad94de

Thx! https://github.com/drakmor/ShadowMountPlus/commit/9fa6ad94dee2b288ef9b980e6fadba969dbc8fbc

Pull request closed

Please reopen this pull request to perform a merge.

Rows
Columns

fix: kernel panic during rest mode (impl. pause/resume system) #25

Pull request closed