Cache hacks don't run from init_tasks if modules loaded

Issue #1903 resolved
One Percent created an issue

After pulling today's commits I've found that trying to use cache hacks run from init tasks... ie beep_init causes them to not execute. When module loading is disabled the same code runs and everything is fine.

Don't know how important/significant this is besides annoyance on my end but it could be indicative of some other issue during startup.

Comments (15)

  1. Georg Hofstetter

    module loading is clearing all caches. this affects also the cache hacked areas iirc.

    alex planned to write a patch manager somewhen that could handle that.

  2. One Percent reporter

    so if it undoes the audio stuff would it also undo patching of free memory done in boot hack?

  3. Giovanni Nanomad Condello

    If you are booting via cache hacks, yes.

    That's really a huge bug and will probably rule out cache hacked boots from ML until a fix is pushed.

    I'll check the code but hopefully is not being used anywhere.

    Raising priority to high as it's a show stopper for me.

  4. One Percent reporter

    so then I guess I have to find where it clears the cache and disable it if hijack cache hack is used. Why exactly is it important to clear the cache for modules. We went a good 6 months without doing it.

    also tested now and free memory doesn't seem to change.

  5. Giovanni Nanomad Condello

    TCC is writing code to RAM, so we need to flush data and code caches to make sure we don't jump in the middle of old, invalid, cached data

  6. One Percent reporter

    yes but the cache is flushed and locked not a few seconds before. old code being read back sounds like it would have presented as nasty bugs already.

  7. Giovanni Nanomad Condello

    EOSM: Use traditional boot method. This makes the installer work properly.

    Avoid a cache-hacked boot should also fix race conditions with modules (See issue: #1903)

    → <<cset 2fc65fcbc6ef>>

  8. Giovanni Nanomad Condello

    Loading modules clears cache hacks, which may potentially lead to canon allocating on top of us

  9. One Percent reporter

    Heh, I guess this solves EOSM but 6D has no task override so A it needs cache hacks, b there is no giant 700k malloc, C, copy & restart doesn't fix the size of the allocate pool

  10. Log in to comment