'10 tot 15 procent van Firefox-crashes wordt door slechte hardware veroorzaakt'

Zo'n tien procent van alle Firefox-crashes komt door hardwareproblemen. Een ontwikkelaar van de browser zegt op basis van heuristische gegevens dat het dan gaat om bitflips of soortgelijke fouten in het geheugen, bijvoorbeeld wanneer gebruikers te weinig of te oud ram hebben.

Dat schrijft Gabriele Svelto, een ontwikkelaar bij Mozilla. Hij schrijft op Mastodon dat hij heuristische gegevens over crashrapportages heeft onderzocht. Gebruikers kunnen zo'n crashrapportage naar Mozilla sturen als Firefox crasht. Dat gebeurde 470.000 keer in een week, zegt Svelto, die extrapoleert dat er nog veel meer crashes moeten plaatsvinden, omdat de crashrapportages optioneel zijn.

"Bij 25.000 van die crashes detecteerden we een potentiële bitflip", zegt Svelto. "Dat is ongeveer een op de twintig crashes die worden veroorzaakt door slecht of gebrekkig geheugen, een enorm cijfer!" Svelto noemt dat bovendien een conservatieve schatting vanwege de manier van meten, waardoor het werkelijke percentage volgens hem op tien procent ligt.

Dat betekent volgens Svelto dat zo'n tien procent van alle Firefox-crashes wordt veroorzaakt door hardwareproblemen. "Als ik daar crashes via middelenuitputting meeneem, zoals out-of-memorycrashes, dan gaat dat cijfer omhoog naar vijftien procent."

Svelto erkent dat de cijfers licht vertekend worden omdat gebruikers met slechte hardware ook vaker crashes zullen ervaren, maar toch 'verbleken oude schattingen rondom dit probleem' met die nieuwe gegevens.

Reacties (86)

[Henkieschmenkie]

"Bij 25.000 van die crashes detecteerden we een potentiële bit-flip"

Dat woordje schoffelt toch de hele waarde van zijn uitspraak, en het artikel, omlaag? Is het een bit-flip, of niet?

[vlaaing peerd]

Los daarvan is een bitflip ook niet altijd te wijten aan 'slechte' hardware. Ook goed werkend (non-ECC) geheugen heeft dat afentoe, wat vaker te wijten is aan externe factoren zoals straling, ruis en interferentie.

[bewerkers]

Omdat ze het onderzocht hebben en geen softwarematige oorzaak hebben gevonden van die bit flips. In een enkel geval zou het misschien toch een softwarematige oorzaak kunnen hebben die ze hebben gemist. Daarom zeggen ze potentieel. Maar als telkens verschillende bits van verschillende variabelen op verschillende plekken flippen, dan kan dat niet allemaal een softwarematige oorzaak hebben.

[Sebazzz]

Mooi gerelateerd, in de categorie onmogelijke crashes: https://devblogs.microsof...hing/20050412-47/?p=35923

Het zou mij ook niet hier verbazen dat standaard overklokprofielen (XMP) hier ten grondslag liggen aan het probleem.

[downtime]

Dat lijkt me sterk. Het aantal mensen wat uberhaupt weet wat overklokken is, lijkt me niet zo groot.

[Oon]

Tegenwoordig met XMP/DOCP e.d. is overclocken ingebakken in de marketing, als je het niet aanzet dan draait je hardware op lagere snelheid. Alle standaard OEM PC's hebben het dan ook gewoon aan staan, dus juist de mensen die niks van PC's weten en een kant en klare PC kopen raakt dit ook.

[Vibonacci]

Omdat XMP gepromote wordt door zowel de processor fabrikant, de moederbord fabrikant EN de geheugen fabrikant, zie ik het dus niet meer als 'overklokken' maar het draaien volgens de specs zoals de fabrikanten deze marketen.

Overklokken betekent nu dat je verder gaat dan het XMP-profiel. XMP dient volledig stabiel te zijn.

[Tourmaline]

XMP zorgt ervoor dat het geheugen op de aanbevolen optimale stand werkt. Overclocking gaat juist over niet optimale standen, die buiten de specs liggen.

[peke]

Het ram kan dan wel de XMP specs aan, er is geen garantie dat moederbord en cpu (geheugencontroller) dit ook kunnen. Zie bvb Hardware Unboxed reviews op YouTube.

[Tourmaline]

Staat meestal wel in de specs van je mobo of het XMP ondersteunt. Het is een feature in je BIOS. Ook de specs van je CPU geven aan hoe snel het geheugen max. kan zijn.

Geheugen kopen wat aan alle specs voldoet.

[Reactie gewijzigd door Tourmaline op 9 maart 2026 10:08]

[peke]

Ik bedoel dat niet elk bord bvb ddr 8000 (of lager) aankam zelfs al zet je XMP of EXPO aan.
Zie deze deze bron:
https://www.youtube.com/watch?v=keJHego7neI&t=2060s

Het hangt daarbij ook niet alleen af van het bord, de memorycontroller van de cpu kan ook de begrenzende factor zijn. Wat betreft het moederbord kan je nog de testresultaten van bvb Hardware Unboxed consulteren om te zien of het werkt, wat betreft cpu moet je maar geluk hebben dat je exemplaar bvb ddr 8000 trekt.
Daarbij kan het ook zijn dat het op het eerste zicht werkt maar gewoon onstabiel is bij bepaalde workload belastingen.

[Tourmaline]

Je hebt bij mobo fabrikanten meestal een lijst met geteste en gegarandeerde geheugenreepjes die de mobo fabrikant aanbeveelt.

Bij de cpu info staat ook wat de max. snelheid is voor geheugenreepjes.

Is(was) het niet zo dat AMD mobo's hier wat gevoeliger voor waren dan de Intel mobo's?

[peke]

Getest maar niet met een XMP of EXPO profiel. Als je een minuut lang de video bekijkt en beluisterd moet het toch duidelijk zijn dat er limieten zijn opgelegd door het bord maar ook door de cpu. Bij de cpu specs vind je wel een gegarandeerde minimum snelheid, bvb ddr 5600.

[Tourmaline]

Als je goed geheugen koopt is er geen enkel probleem, ook niet met xmp. Heb daar nog nooit problemen mee gehad. Trouwens, je kunt het max XMP ook gewoon vinden bij je geheugen specs. Dus koop alles binnen spec = geen probleem.

[Reactie gewijzigd door Tourmaline op 9 maart 2026 18:01]

[Robbierut4]

Onder de gehele populatie niet. Onder Firefox gebruikers zal dat aantal een stuk hoger liggen.

[Sebazzz]

Vergis je niet, zoals ook in het artikel genoemd wordt, dat sommige computers en moederborden standaard met een soort overklokconfiguratie ingeschakeld komen.

[Bruin Poeper]

Het aantal Firefox crashes lijkt me ook niet zo groot. Dus misschien is er toch een relatie met "wij Tweakers"?

Ik heb nog nooit Firefox crash meegemaakt (of ik ben het vergeten).

[itcouldbeanyone]

Ik ook niet , maar dat komt omdat als tweakers gebruik je natuurlijk standaard ECC,

[atthias]

1 of 2 keer op de desktop in stable release op windows 11

stuk of 6 keer op mobiel android 13 maar das de beta variant dus dat hoort er ook een beetje bij

[metalmania_666]

Ik geloof in al die jaren (FF gebruiker sinds 1.5) een keer of 5 waarvan 1 x zeker door foute hardware

[Argantonis]

In het artikel dat Sebazzz linkte staat daar echter een uitleg voor. Ik laat het aan jou om het ook daadwerkelijk te openen.

[bewerkers]

The other half said, “What’s overclocking?” He called them and walked them through some configuration information and was able to conclude that they were indeed all overclocked. But these people were not overclocking on purpose. The computer was already overclocked when they bought it. These “stealth overclocked” computers came from small, independent “Bob’s Computer Store”-type shops, not from one of the major computer manufacturers or retailers.

[Reactie gewijzigd door bewerkers op 8 maart 2026 09:28]

[CriticalHit_NL]

Kan me anders ook wel herinneren dat Firefox ontiegelijk veel issues had in het verleden met hardware-acceleratie van de videokaarten, of dat hedendaags nog zo'n groot issue is betwijfel ik.

Nu is DDR5 wel in opkomst en die willen nog wel eens wat moeilijker doen i.v.m. de toegenomen complexiteit wat dus sneller voor instabiliteit kan zorgen met name op hogere snelheden en grotere capaciteiten.

Nu zal dat Intel debacle ook wel enig sinds meespelen, al hebben die vaak ironisch genoeg wel de betere interne geheugencontrollers, daar zit het hem weer in de CPU zelf.

Natuurlijk is bij menigeen hobbyist undervolten ook een hot-topic, maar dat kan soms ook net een tikkeltje te ver gaan met willekeurig crashende applicaties als gevolg.

Of je hebt games als WoW die bij bepaalde grafische instellingen gewoon doodleuk veel memory violations (advanced work submit) kan genereren ondanks dat het systeem verder hardware-matig prima is.

[R4gnax]

Kan me anders ook wel herinneren dat Firefox ontiegelijk veel issues had in het verleden met hardware-acceleratie van de videokaarten, of dat hedendaags nog zo'n groot issue is betwijfel ik.

Ze hebben inderdaad heel lang issues gehad met crashende video drivers waarbij de ingebouwde timeout detection & recovery (TDR) van Windows aansloeg om de driver gedeeltelijk te herstarten. Maar Firefox kon dat niet goed afhandelen waardoor op dat moment simpelweg de video output stopte.

Dat is in beperkte mate overigens nog steeds zo. Het afspelen van hardware accelerated video gaat in algemeenheid goed, maar als je scrollt terwijl de video afspeelt heb je een bepaalde willekeurige kans dat je een zelfde soort UI freeze krijgt als voorheen met de TDRs. Gebeurt met Nvidia, met AMD, met Intel graphics hardware- maakt eigenlijk niet uit welke vendor.

[Reactie gewijzigd door R4gnax op 6 maart 2026 19:09]

[84hannes]

Mooi gerelateerd, in de categorie onmogelijke crashes: https://devblogs.microsoft.com/oldnewthing/20050412-47/?p=35923

Goed verhaal

TL;DR

Omdat Microsoft de crashes niet konden verklaren vroegen ze de (volgende) 20 reporters contact op te nemen. De helft bleek bewust hun machine over te klokken. De andere helft bleek een overgeklokte machine te hebben gekocht. Je kunt hieruit voorzichtig concluderen dat overklokken niet goed is voor de stabiliteit van je machine.

Zowel Microsoft als Mozilla willen hier voorzichtig mee zeggen: als je denkt dat onze software buggy is (terwijl anderen dat niet zo ervaren) kijk dan eens naar je hardware. Maar ze durven het niet te hard te zeggen omdat iedereen dan denkt dat ze de schuld van hun eigen fouten aan anderen doorschuiven.

edit:
Quote met hyperlinks doet heel raar, handmatig aangepast

[Reactie gewijzigd door 84hannes op 6 maart 2026 20:33]

[Jack77]

Bij compilen merk je heel goed het verschil tussen stabiel geheugen en 99% stabiel geheugen. In het laatste geval werken games meestal wel, op en occasionele crash na. En mss heb je dan ook wel eens een Firefox crash. Maar bvb. een kernel compilen lukt niet, en MemTest86 vertelt wat anders.

Zeker bij DDR5 denk ik dat de compatibiliteit nagaan en dingen niet te ver pushen (ook bvb met XMP icm 4 dimms), geen overbodige luxe zijn als stabiliteit hoog op je verlanglijstje staat.

[Azbest]

Ik denk eerder dat we te maken hebben met mensen die niet eens kijken naar die instellingen waardoor geheugen niet het juiste voltage krijgt of timings. Met gevolgen vandien.

Tevens moet ik zeggen dat browsers een belachelijk beroep doen op werkgeheugen tegenwoordig om maar de concurrentie voor te blijven of bij te benen.

Ik heb een workstation met registred dimms en zelfs daar krijgt Firefox het voor elkaar om de boel bijna vast te laten lopen (zo traag als stroop door een trechter).

Ik denk dat het een boel zou helpen als Firefox een manier vind om JavaScript code te stoppen en unloaden wanneer een tablad niet wordt benut.

[oef!]

Dat is in mijn ervaring zeker mogelijk. Ik heb mijn ddr4 geheugen overgezet naar een nieuwer systeem dat instabiel bleek te zijn (crashende games). Na tests met memtest86 werd duidelijk dat het xmp profiel het issue was terwijl dat op het vorige moederbord geen issue was. Het geheugen op lagere snelheid laten draaien bleek de oplossing te zijn.

[latislos]

Wat is hun punt precies met dit nieuws?

Zouden Chromium browsers daar ook op crashen? of hebben ze het beter voor mekaar kwa regelen van geheugen en opvangen van die bitflip (Whatever it is ) ?

[sircampalot]

Het omvallen van bitjes: bitflip

Een klein probleem bij Firefox, een groot probleem in luchtvaart, maar daar komt het door externe factoren (dampkring dempt het effect)

[Reactie gewijzigd door sircampalot op 6 maart 2026 18:56]

[whiner]

Firefox crashed erg vaak wanneer er te weinig swap is. Sinds ik mijn swap groter heb gemaakt heb ik geen crash meer gehad.

Maar dat is dus gewoon een memory beheer probleem. Moeten ze gewoon oplossen.

[PCG2020]

Het is wel typisch dat ik de afgelopen twee maanden in de Windows-versie van FF regelmatig de melding 'Ach! Uw tabblad is zojuist gecrasht!' kreeg. Volgens mij is dat begonnen met versie 146; daarvoor had ik er nooit last van. In versie 148 is het wel weer verminderd ten opzichte van 146 en 147, maar komt het alsnog zo nu en dan voor.

In de Linux-versie van FF heb ik er tot nu toe nooit last van gehad en toch gebruik ik daarin precies dezelfde extensies en zo.

[jaspov]

Krijgt de gebruiker dat ook teruggekoppeld, als hint om geheugentest te doen?

[kabelmannetje]

Bit flips vinden natuurlijk niet plaats in "oud" of "te weinig" geheugen ..

Het zijn domweg fouten in het RAM. Dit heeft niks met leeftijd of hoeveelheid geheugen te maken.

[koelpasta]

Een ontwikkelaar van de browser zegt op basis van heuristische gegevens dat het dan gaat om bit-flips of soortgelijke fouten in het geheugen, bijvoorbeeld wanneer gebruikers te weinig of te oud ram hebben.

Dit slaat natuurlijk als een tang op een varken. Een bit-flip is totaal niet een 'soortgelijke' fout als een out of memory of 'oud ram'(??). Dit zijn verschillende oorzaken die je niet zomaar op 1 hoop mag gooien. Als het gaat om een verzameling van uiteenlopende oorzaken, wat is dan het werkelijk aandeel van bit-flips in de crashes?

Ik merk wel dat FF een enorme memory hog is geworden. Ik denk dat die bit flips helemaal niet zo veel voorkomen en dat 'een ontwikkelaar' probeert de crashes door FFs corpulente runtime of door bugs te verhullen.

[bewerkers]

Linus Torvalds heeft ook last gehad van bitflips. Daarom gebruikt hij nu alleen ECC RAM: YouTube: Building the PERFECT Linux PC with Linus Torvalds

Interessante video can veritasium over bitflips YouTube: The Universe is Hostile to Computers

[Reactie gewijzigd door bewerkers op 8 maart 2026 12:51]

[ramonfincken]

Ecc geheugen dan maar voor thuispc?

[JayPe]

Linus Torvalds zweert erbij.

[Pep7777]

Ik vind het niet zo zinnig "persoon XYZ vind dit/vind dat" erbij te halen. Wat vind je zelf?
ECC memory of dan maar niet overklokken? Er zijn zelfs situaties waar underklokken kan helpen met koeling, bijv laptops zijn dan ineens een heel stuk stiller, en dat is dan weer een stuk fijner als je de hele dat moet werken

[Reactie gewijzigd door Pep7777 op 7 maart 2026 08:23]

[JayPe]

Oh excuses. Het is niet 'de mening van XYZ persoon' die ik erbij wilde halen, maar ik ging er vanuit dat, aangezien Torvalds het met uitleg erbij verklaard een soort van 'bekend' is. YouTube: Building the PERFECT Linux PC with Linus Torvalds it will fail, the question is when (pun intended).

Niet dat ik recent ECC memory heb gebruikt, anders dan in servers op de werkplek. M'n huidige privé laptop (Ryzen 7 7840u) ondersteund het wel vanuit de CPU, maar er zit (gesoldeerd) non-ECC LPDDR5 geheugen op. Een soort on-die ECC, maar niet vergelijkbaar met écht ECC.

[Pep7777]

Excuses zijn ook weer niet nodig hoor. de "Wat vind jezelf" was een oprechte nieuwsgierige vraag geen verwijt (En online fora missen helaas intonatie)

[uiltje]

Dat werkt misschien, maar ik heb bijvoorbeeld het sterke vermoeden dat een bios update mijn PC minder betrouwbaar had gemaakt. Ik gebruikte destijds ook firefox. Nadeel van PC's misschien; je configuratie is vaker buggy, zelfs bij A-merken. Nou is in mijn geval Asus dan de boosdoener en die hebben nooit goede SW of firmware support gehad. En als iemand zegt van niet, paste hier dan de laatste changelog van de software die je net gedownload hebt.

Maar even terug naar waar we waren: ja ECC kan inderdaad een gedeelte hiervan afdekken, en DDR5 zal hier al een gedeelte van meenemen vanwege de beperkte ingebouwde ECC.

[Reactie gewijzigd door uiltje op 6 maart 2026 18:07]

[Dekar]

Kan, maar dan moet je wel een hele dure PC met EPYC, Threadripper of Xeon aanschaffen. Want Intel Core Ultra en AMD Ryzen ondersteunen het niet.

[dcm360]

AMD Ryzen ondersteunt wel degelijk ECC-geheugen. Bij de Pro-modellen is het gevalideerd, bij de overige modellen niet, maar in de praktijk werkt het.

[Dekar]

Alleen UDIMMs. Dat is praktisch geen ECC. Er bestaat ook geen AM5 moederbord met Registered ECC memory ondersteuning.

[dcm360]

UDIMM of RDIMM heeft weinig te maken met ECC, dat gaat alleen over of de geheugencontroller direct de geheugenchips aanspreekt of dat er nog een buffer tussen zit. AM5-moederborden met ondersteuning voor RDIMM's bestaan niet omdat de geheugencontroller op Ryzen CPU's geen RDIMM's kan aansturen, maar UDIMM's met ECC gaan dus prima.

[Dekar]

Het bufferen heeft alles te maken met ECC. Stel een bitflip gebeurt op de verbinding tussen CPU en RAM bijvoorbeeld door elektrische ruis of een defecte trace op het moederbord. Het RAM kan dat niet detecteren, want RAM voert zelf geen ECC-controle uit. De fout kan al in de data zitten voordat de ECC-controle plaatsvindt.

Daarom kan ECC UDIMM niet alle fouten detecteren. En zijn RDIMMs de enige versie van "echte" ECC.

[dcm360]

Zover ik weet zit de ECC-controle bij zowel UDIMM als RDIMM in de geheugencontroller (tegenwoordig dus op de CPU-package), en is er wat dat betreft geen verschil tussen de 2. Dit is althans hoe Wikipedia het uitlegt (en hoe het in mijn hoofd zit), maar ik ben altijd benieuwd naar een uitleg hoe het anders zit of kan.

[vladimirN]

ik dacht dat het mobo fabrikanten vrijstond om te bepalen of ze het wel of niet ondersteunden bij de niet pro modellen en dat het dus wisselt per mobo.

[postbus51]

Als je maar niet te WEINIG of bejaard ram hebt , lol wat een bokkestreek

wist niet dat oud ram aan dementie leed , ach al die oude apparaten van 10 jaar geleden

Mss wat minder vaak FF updaten want elke major heeft wel 3 tot 4x een patch

En de ESR versie leuk maar die neemt zelfs met de downgrade optie je passwords-logins niet mee , moet je alles eerst weer ppfffh naar csv exporten en dan weer ...

Was vroeger gewoon lekker simpleminds , beetje surfen in je zwembroek op een stoel

Teveel blabla van de ontwikkeldude , zoals getypert nooit een crash met wat dan ook maar laatste jaar FF
FastFlikker op de bek

[Reactie gewijzigd door postbus51 op 7 maart 2026 05:10]

[ramonfincken]

Tja... Te weinig dan maakt het type ook niet uit natuurlijk

[Dekar]

Natuurlijk wel. ECC staat voor Error Correcting Code.

Wikipedia: Registered memory

Wikipedia: ECC memory

[Reactie gewijzigd door Dekar op 6 maart 2026 18:13]

[PageFault]

Als je iets verdiept in error correcting codes, dan zul je zien dat een 9e bit absoluut geen ruimte biedt voor het corrigeren van errors, enkel voor detectie van een deel van de errors.

Wanneer de pariteit niet klopt, weet je echt niet welke van de 8 is "omgeklapt".

Als je naar wikipedia gaat, check dan vooral deze: Wikipedia: Error correction code
Dan zie je ook vanzelf dat er een heel groot verschil zit in detectable vs. correctable.

[svane]

check dan vooral deze: Wikipedia: Error correction code

Kan je iets selectiever quoten? Ik ben die pagina aan het lezen, en daar staat letterlijk:

Hamming ECC is commonly used to correct ECC memory and early SLC NAND flash memory errors.[7] This provides single-bit error correction and 2-bit error detection

Waar lees je precies dat ECC geheugen niet kan zien welke bit er omklapt?

[hcQd]

Daarom worden er ook 8 paritybits per 64 databits gebruikt, dan kun je alle eenbitsfouten corrigeren en tweebitsfouten detecteren.

[RobinJ1995]

Fout. Single bit flips kunnen wel degelijk automatisch worden gecorrigeerd door ECC-geheugen.

[vladimirN]

Ik kan je uit ervaring vertellen dat het ideaal is wanneer je systeem aangeeft dat je een corrupte module hebt zonder crash. Wel prettig als je net een sommetje aan t doen bent dat een paar uur duurt en 256GB geheugen nodig heeft. ECC geheugen zou de standaard moeten zijn, ook voor consumenten

[Mathijs Kok]

Dat lost het probleem niet echt op, er zit dan detectie op van een fout in het geheugen, maar niet de correctie. Gevolg is nog steeds een crash.

En dat op Tweakers. EEC geheugen kan fouten corrigeren, daarom gebruik je het.
Waarom niet eerst even uitzoeken voor je mening te geven?

[_Pussycat_]

Stel ik heb een pariteit over rijen en kolommen van 16x16 bit, en ik zie dat de pariteit in rij 3 fout is en dat de pariteit in kolom 8 fout is. Dan is bit(3,8) fout.

Als er in de rijen een parity error is, maar in de kolommen niet, dan was waarschijnlijk de parity zelf fout.

Nou nou, dat was heel moeilijk.

In de praktijk zijn er duidelijk slimmere codes dan wat ik boven schrijf. Maak maar een een paar bits bij een QR code kapot, dan doet die het ook nog.

Wikipedia weet er trouwens ook "geen zak van", want die schrijft ook Error correction code memory (ECC memory) is a type of computer data storage that uses an error correction code^[a] (ECC) to detect and correct n-bit data corruption which occurs in memory.

[...]

Standard server memory are designed for a single-error correction and double-error detection (SECDED) Hamming code, which allows a single-bit error to be corrected and double-bit errors to be detected per word (the unit of bus transfer).

[Reactie gewijzigd door _Pussycat_ op 7 maart 2026 10:59]

[svane]

Je geeft 1 extra bit,

Daar ga je de fout in, wie zegt dat je maar 1 extra bit geeft?

8 bits aan data kan je niet corrigeren met 1 parity bit, wel met 4 parity bits.

Bij DDR5 wordt er correctie gedaan op 128 bits aan data, met 8 bits aan parity erbovenop (136 bit totaal).

DDR5 SDRAM ECC is implemented as single error correction (SEC), pairing 128 data bits with 8 parity bits to form a 136-bit codeword that is stored in the DRAM during a WRITE command. During subsequent READ commands to that address, a syndrome will be calculated based on the 136 bits, correcting any single-bit errors that may occur.

Met 8 bits kan je prima aangeven bij welk van de 136 bits er een fout is opgetreden.

Kort samengevat is elke 2^x bit een parity bit. In dit geval bit 1,2,4,8,16,32,64 en 128. Elke parity bit slaat het XOR resultaat op van alle data-bits op bepaalde posities.

parity bit 1 doet een XOR op data-bits op posities xxxxxxx1 (3,5,7,8,11,13, etc.)

parity bit 2 doet een XOR op data-bits op posities xxxxxx1x (3,6,7,10,11,etc.)

parity bit 3 doet een XOR op data-bits op posities xxxxx1xx (5,6,7,12,13,14,15,etc.)

etc.

Om te controleren of je data klopt bereken je de parity bits opnieuw, en xor je die met de opgeslagen parity bits. Als het resultaat 00000000 is, weet je dat er geen single-bit flip is geweest. Is de data iets anders, dan weet je precies op welke positie de bit flip heeft plaatsgevonden.

Is de XOR van opgeslagen en herberekende parity bits `00000110`, dan zit je fout op positie 6, en kan je dat corrigeren.

offtopic:
Geeft dit getal een niet-bestaande positie op (zoals 156), dan weet je dat er meerder bits zijn geflipt, al weet je niet welke.

Genoeg informatie over te vinden, bijv. hier

Voor specifieke vragen of voorbeelden kan een LLM (Claude / ChatGPT) ook goed werken. Ondanks dat dat geen bronnen zijn voor informatie, kunnen ze heel goed zijn in het uitleggen van iets, zo lang je 't maar zelf dubbel checkt (wat dus perfect handmatig kan in 't geval van ECC ).