Lars, Paul, everyone...
It is worth giving it a try but keep in the back of your head that a Trap E can occur for a lot of reasons. If you use the OS4 kernel, the memory layout will look different. This is also the case if you load additional drivers etc.
Indeed. There is more to this than just the ACPI driver difference. Going back to 3.23.14 did NOT improve the situation, still the same failure.
For some happy news though: uniaud32-linux-5.10.5-20210108.zip works just fine with OS4.
NOTE: below is very much non-uniaudio specific, but I figured it was worthwhile sharing my experience in case others may benefit from it.
...By the way: what I have observed with ACPI 3.23.15 is that cores > 0 can take a long time to be reenabled and if they are, they run at 100 % for some time until everything drops back to normal. Can you check with 3.23.14 if that was different or the same ?
Interesting, this is very close to what I was seeing actually. More specifically though, in a certain sequence of events (shutting off all but a single core and re-enabling) caused all the cores to go to 100%. That was my brief experience while attempting (re-visiting actually) the ACPI Power Manager use. I normally do NOT run the ACPI power management on my desktop machine. I simply have found that throttling logic and/or execution to be literaly too lagging. Namely, it took too long for the immediate power-needed NOW to translate to additional cores actually throttling up.
Yes I know that the throtting is supposed to happen fast, but alas here that just did not pan out. This is not for lack of trying. I spent a good amount of time working with acpid.cfg and the various settings never really arriving at what felt like a seamless execution. I suppose (I hope) that on a laptop the momentary inconvenience of a lag may be tollerable given the hopefully longer battery life (due to core throttling and therefore power use), but on my desktop machine that just wasn't a tradeoff I wanted to pursue.
...The reason behind my question: I had modified an app for 2 of its threads to NOT execute on core 0 (for specific reasons). But with 3.23.15, the system would not reenable cores > 0 even when these 2 threads signaled that they were ready to execute (but would not be scheduled). I had to change the app back to using all cores for these 2 threads.
I can not speak to core-affinity requirements such as these, but I will tell you that previously 3.23.13 was trully the last good version of ACPI I had. When 3.23.14 came out I immediately hit a wall in terms of being able to enabled and disable cores, keep in mind this is all with the ACPI PM shut OFF. I had logged this issue for AOS given that my reporting was being done as part of the Testers List and was very specific to the ACPI driver itself as opposed to the whole AOS package (
https://mantis.arcanoae.com/view.php?id=3002). Did not make much progress with that, things went nowhere beyond some technical info exchange and the case was ultimately closed due to being of "unsupported configuration" (I am not running AOS, still Warp 4.5 CP2 with piece-wise upgrades).
My point is, through multiple tests of my own it felt like 3.23.15 finally brought back the 3.23.13 behaviour (core disable & enable now works), however, I did see this weirdness you talked about.