Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

sys-clk overlay crashes Atmosphere 0.18.0 under two conditions #34

Closed
jacoghi opened this issue Feb 7, 2021 · 4 comments
Closed

sys-clk overlay crashes Atmosphere 0.18.0 under two conditions #34

jacoghi opened this issue Feb 7, 2021 · 4 comments

Comments

@jacoghi
Copy link

jacoghi commented Feb 7, 2021

(This is regarding the overlay that comes bundled in this official package)
On the new Atmosphere 0.18.0, first boot:
By default, modules are turned off.

  • Open Tesla menu on Atmosphere's first run, toggling sys-clk overlay ON and then trying to access the overlay results in a panic event from Atmosphere. This behavior did not happen on Atmosphere 0.17.1. The nro manager, however, can be used as expected without resulting in a crash.

  • Every time the module is turned off under sysmodules, followed by the overlay trying to be accessed (resulting in a "fatal error, not running" as expected), going back to sysmodules and trying to turn it back ON results in a panic event from Atmosphere.

  • The workaround is to have it marked for Auto-Start and never turn it back OFF. That being the case, a safer behavior would be to mark sys-clk overlay as a STATIC module instead of dynamic since as of now, its dynamic nature cannot be used without resulting in a crash. Both scenarios end up being basically the same, going from a cold, not auto started boot, to turning it on, and then crashing, however, happening when the user selects different options.

@p-sam
Copy link
Member

p-sam commented Feb 8, 2021

You should never try to kill the sys-clk sysmodule, doing so will skip cleaning up ressources and will prevent it from being turned back on. Right now, I'm using the overlay just fine on ams 0.18 and I could not reproduce your first scenario, so be sure to include the actual crash report, if you're not doing what I just mentioned.

As for your third point, it sounds like your using it from some other packaged AIO bundle, because it's "marked for auto-start", with the boot2.flag file present in the release archive. The "static/dynamic" thing you're talking about is not related to stock Atmosphere or sys-clk, but rather your on/off sysmodule app and/or overlay.

@jacoghi
Copy link
Author

jacoghi commented Feb 9, 2021

I'm using https://github.com/WerWolv/ovl-sysmodules which should be the official Tesla sys-modules toggler.
By first run I meant the first time you start Atmosphere, since all modules are turned off by default, toggling sys-clk using the abovementioned overlay results in a crash. I tested it with two SD card installations (although the same Switch) and it yielded a crash on both instances. BTW, when I describe first run to get the crash is by deleting all the files from my SD card except for the emuMMC folder and dropping the whole installation from scratch, therefore having no previously built config file.

The static / dynamic thing comes from the ovl-sysmodules overlay and I assume there's a flag on every module that lets Tesla know if the module can be toggled dynamically (w/out a restart) or statically. And no, I'm not using a pre-packaged bundle nor anything like that, this is for a manually put together package.

@p-sam
Copy link
Member

p-sam commented Feb 9, 2021

I know which overlay you're referring to, and the flag you're referring to is the toolbox.json config file. Since there's none in the official release, sys-clk should not even be listed in the overlay you use to spawn/kill sysmodules, which tells me you've created it yourself or got it from elsewhere. ( see https://github.com/WerWolv/ovl-sysmodules/blob/master/source/gui_main.cpp#L42 )

Closing the issue due to the lack of a crash report file when run at boot

@p-sam p-sam closed this as completed Feb 9, 2021
@jacoghi
Copy link
Author

jacoghi commented Feb 9, 2021

Logs were posted here when I figured this was an atmosphere issue.

Atmosphere-NX/Atmosphere#1358

https://drive.google.com/file/d/1s5O3eskrIg7dvG9ZbPZoVGcHPutuYiGn/view?usp=sharing

So the simple fact you drop a ovl file into the overlays folder is not enough for the sysmodules overlay to list it after reading it at boot time? Is this flag mandatory for the module to be listed? One log was due to emuiibo crashing which turned out to be due to this sm extension as pointed out by SciresM. If these are not the logs you're talking about, let me know and I'll get them for you.

Edit: BTW, I just performed a test over here for the sake of completeness. I can enable / disable the service as many times as I want using the nro manager without crashing the system. After disabling it through the nro manager, if I try to access sys-clk overlay (without messing with toggles, which still shows as ON on ovl sys modules) the overlay shows the same screen as if it were enabled, however, service shows as OFF matching the manager state. Therefore, couldn't the issue be related to how the overlay changes from the FATAL ERROR NOT RUNNING (which shows if toggled off through the sys modules overlay and applies to both crash scenarios) message to the message normally seen when the module is running?

Edit2: Just checked here, one of the files I drop on top of my installation files for overrides ended up being this toolbox.json file that matches the sys-clk overlay. Deleting it will remove the ability to toggle the module and therefore solves the issue, agreed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants