#Observations on Spring/Bar Corruption

1 messages · Page 1 of 1 (latest)

half abyss
#

BAR / Spring corruption on Intel hybrid CPUs (Linux)

Summary:
On an Intel i9-14900K system running Linux (Arch/Garuda, Zen kernel), BAR/Spring repeatedly corrupted downloaded content (maps, rapid pool) and crashed during map load. Storage, filesystem, and RAM tested clean. Root cause was CPU topology changes on hybrid CPUs.

System:

i9-14900K (P+E cores)

DDR5 @ 7000 MT/s (rated 7600)

Linux (Garuda / Arch), Zen kernel

btrfs (zstd)

Symptoms:

CRC / gzip errors on BAR content

Spring crash at “Loading Map Tiles”

Corrupted .sd7 maps

Initramfs boot error when unstable:
ZSTD-compressed data is corrupt

Findings:

Disk SMART, btrfs scrub: clean

memtester passed

Corruption occurred when:

all E-cores OFF

or partially enabled (e.g. 6 E-cores)

All E-cores enabled = fully stable

Explanation:
BAR/Spring stress highly parallel workloads (download + gzip/zstd + I/O + Lua + render init). On Intel hybrid CPUs under Linux, disabling or partially enabling E-cores increases scheduler jitter, cache pressure, and fabric instability, causing silent data corruption even when RAM tests pass.

Resolution:

Re-enable all E-cores

Leave RAM unchanged

BAR repairs once and remains stable

Takeaway:
On Intel 12th–14th gen CPUs under Linux, E-cores should remain enabled. BAR/Spring act as real-world integrity canaries; corruption here is topology-related, not disk or filesystem failure.

serene marsh
#

@opaque nest This may be to your interest

#

It's worth noting that garuda uses a non-vanilla linux kernel, but I myself use it with no issues.

serene marsh
#

-uplog

unkempt treeBOT
opaque nest
#

Very strange behaviour. Porkyleaf, have you informed Intel?

half abyss
#

Have not no

#

Was wondering if anyone else had experienced this though. For many games you can disable e cores to improve performance. Here it seemed to actually be what was corrupting Spring/Bar for me

#

I can repeat this easily enough

#

It did it on Ubuntu as well

sleek nimbus
#

I was always a big enemy from Intels E-Core decision, Intel gained also really bad reputation since the faulty hardware release after (alder lake's refresh) Intels 13-14th gen release. But that you face data corruption when you disable E-Core's, holy shit. This is next level!

#

@half abyss I'm actually wondering, if this is maybe more related to BTRFS and E-Core's... maybe put BAR on a simple EXT4 partition and see if this would change anything.

serene marsh
#

I use BTRFS with no issues FWIW, I'm on an older AMD Ryzen CPU though.

sleek nimbus
# serene marsh I use BTRFS with no issues FWIW, I'm on an older AMD Ryzen CPU though.

Since i was a active supporter in a Linux forum and i saw many many user error's around BTRFS it can also related to maintaining the filesystem, that stuff is really advanced. Everyone who switching to Linux i try to warn not to use the BTR Filesystem if the user is not willing to learn and to deal with the advanced rules that comes with it. EXT4 is mostly the best solution for the most user's. Keep in mind, that i only say this to reduce the error pool, the chance's that E-Core's + BTRFS + BAR is maybe not this high, but i still think there is maybe a good chance. Anyways this is for sure not an easy topic.

opaque nest
half abyss
#

Will produce some fresh logs for this

#

and post them soon

#

hmmm its not corrupting now with all my e cores off

#

might take a few games but i know turning them back on stopped it at that time

#

did you want the whole zip?

sleek nimbus
half abyss
#

oh right there was actually one other neat thing
Additional finding: BAR data location on Linux (btrfs issue)

On Linux, BAR stores critical, high-churn game data in:

$XDG_STATE_HOME/Beyond All Reason
(default: ~/.local/state/Beyond All Reason)

This directory contains:

engine/

rapid/

packages/

maps/

On Arch/Garuda systems, ~/.local/state is commonly on btrfs with CoW + compression + snapshots enabled. BAR’s rapid downloader performs many parallel small writes and rewrites, which can lead to silent corruption on btrfs CoW.

Confirmed workaround:
Moving the BAR state directory to NoCoW storage and symlinking it back fully resolves this class of corruption.

Example:

chattr +C ~/games/BAR
mv ~/.local/state/"Beyond All Reason" ~/games/BAR/state
ln -s ~/games/BAR/state ~/.local/state/"Beyond All Reason"

Suggestion:

Avoid placing large mutable binary assets in $XDG_STATE_HOME

Or allow configuring the BAR data directory

Or document NoCoW recommendation for btrfs users

#

ive been able to get over 600 fps with the e cores turned off currently

#

since i started this thread

#

i am definitely noticing a performance difference with the e cores turned off even if the game engine is supposed to ignore them. Maybe some corruption happens in the data somewhere inbetween this and where some data gets stored

#

yea when i actually have the e cores turned off in muh bios my frames can more than double but yea i think there may be more to look into here

opaque nest
# half abyss

This log is fine; though, both of the supplied logs show the exact same topology. I'd also need to see the output of lscpu -e in both setups to confirm the engine is behaving correctly.

opaque nest
half abyss
#

kk i'll try to provide that later on