Hvordan svarteliste en riktig dårlig RAM-sektor i henhold til MemTest86 + feilindikasjon?

MemTest86 + (versjonen som følger med Ubuntu 13.04) sier

Failing address: 002f796c48 - 759.5 MB 

Hva skal jeg spesifisere i memmap kjerneparameteren for å omgå dette området?

Jeg har prøvd å kjøre memtester 770MB og det sier alt er ok, så det ser ikke ut til at MemTest-indikasjonene betyr en feil i 759,5. MB fra starten.

Slik tolker du denne MemTest-indikasjonen for å konfigurere memmap?

Jeg har ingen penger til å kjøpe nytt RAM nå, og feilen ser ut til å være singel, så jeg håper jeg bare kan overstyre den.

Kommentarer

  • FWIW, kjernen vil merke visse sider som " reservert " hvis den oppdager et dårlig segment men er i stand til å komme seg. Viser utdataene fra " free -m " krefter på to for totalene? Jeg nevner dette som en måte å forklare hvorfor memtester kan t se dårlig RAM, men memtest86 + kan.
  • Ser ikke ' t ut som krefter av to faktisk: i.stack.imgur.com/l86L1.png
  • Når en feil oppdages (hvis du til og med har ecc-ram), er det generelt for sent. Også gratis -m rapporterer aldri en jevn styrke på to da bios og kjerne begge reserverer noen ram.
  • Jeg drømmer om å kjøpe en ECC-bærbar PC, men kunne aldri finne noen tilbud tilgjengelig, ser ut som de ikke ' t eksisterer.
  • Ser ut som kjernen også printk ' s når den finner en dårlig side (linje 264-265).

Svar

memmap

Det er denne veiledningen med tittelen: Dårlig minne HowTo som diskuterer deaktivering av minne via kjernen ved hjelp av memmap argument til kjernen. I henhold til hvordan du har to alternativer når det gjelder memmap:

  • Slå av alt etter dårlig minne – (mem=###M option)
  • Slå bare av minnet rundt det dårlige minnet – (memmap=#M$###M option)

Med det første alternativet, hvis memtest rapporterer at det er dårlig minne på 600M, kan du deaktivere RAM fra dette punktet til slutten av RAM med dette:

 mem=595M 

Hvis det » Hvis dårlig RAM ved 802M og 807M, kan du deaktivere en 10M del av RAM som starter ved 800M slik:

memmap=10M$800M 

MERK: Dette vil svarteliste 10M etter 800M base-adressen. Du bør kjøre memtest86+ etterpå for å bekrefte at dette argumentet er riktig.

BadRAM

Det er et program tilgjengelig for Ubuntu som heter BadRam. Det dekkes veldig godt her i dette innlegget med tittelen: BadRAM på Ubuntu-fellesskapet nettsted.

Etter at du har brukt oppdateringen på kjernen ved hjelp av detaljene fra den siden, gjør du endringer i Grub2-oppsettet:

utdrag fra nettstedet for Grub2

GRUB2-konfigurasjonsfilen i Natty har en linje for å konfigurere eksklusjoner for kjerne-dårlige ram. Så jeg vil anta at det er den foretrukne måten å kartlegge en del av minnet som viser feil. Linjen jeg satte var

GRUB_BADRAM = «0x7DDF0000,0xffffc000»

Den foreslåtte måten på hvert nettsted jeg kunne finne var å sette dette var å kjøre memtest86 og la det vise deg BadRAM-innstillinger. memtest86 ga meg en side med ting jeg måtte ha lagt inn. Jeg kunne se at alle adressene var i en 16K-blokk, så jeg ville bare kartlegge den 16K-blokkeringen ute av handling. Slik genererte jeg riktig oppføring.

Den første parameteren er enkel. Det er grunnadressen til dårlig minne. I mitt tilfelle kunne jeg se at alle dårlige adresser var større enn 0x7DDF0000 og mindre enn 0x7DDF4000. Så jeg tok begynnelsen på 16K-blokken som startadresse.

Den andre parameteren er en maske. Du legger 1s der adresseområdet du vil dele de samme verdiene og 0s der det vil variere. Dette betyr at du må velge adresseområdet ditt slik at bare biter av lav ordre varierer. Ser jeg på adressen min, er den første delen av masken enkel. Du vil starte med 0xffff. For neste nibble vil jeg forklare med bitkart. Jeg vil variere fra 0000 til 0011. Så, masken for badram ville være 1100 eller en hex c. De siste 3 knepene må være alle 0-ene i masken, siden vi vil at hele serien skal kartlegges. Så vi får et totalresultat på 0xffffc000.

Etter å ha satt denne linjen i / etc / default / grub, kjørte jeg sudo update-grub og startet på nytt, og mitt dårlige minne ble ikke lenger brukt. Ingen kjerneoppdateringer er nødvendig for å kartlegge dårlig minne ved hjelp av denne metoden.

Oppfølging nr. 1

Ser gjennom wikipedia-siden for memtest86 + står det som følger:

utdrag fra Memtest86 wikipedia-side

Fra Memtest86 2.3 og Memtest86 + 1.60 kan programmet sende en liste over dårlige RAM-regioner i formatet som forventes av BadRAM-oppdateringen for Linux-kjernen; ved hjelp av denne informasjonen kan et Linux-system pålitelig bruke en RAM-modul selv om det har noen dårlige biter. Grub2 er i stand til å levere den samme informasjonen til en ukjent kjerne, og nekter behovet for BadRAM-oppdateringen.

Også jeg kom over denne Gentoo-side som spesifiserte memmap=... ved å bruke en hex-adresse, slik at du kunne spesifisere den slik:

memmap=5M$0x2f796c48 

5M er bare en gjetning, selvfølgelig kan du justere den lavere eller høyere, avhengig av hvor mye RAM rundt den regionen du vil / trenger å utelate.

Endelig kan du også angi størrelsen i heksen:

memmap=0x10000$0x2f796c48 

Ville ignorere 64 KB start fra adresse 0x2f796c48.

Referanser

Kommentarer

  • " 800M til 804M " skal være " 800M til 810M " I antar …
  • Det kan være, men det jeg skrev er OK også, selv om det ' s kaster bort mer minne enn 4M mellom 800M og 810M.
  • 1. Jeg vet om alternativet memmap, men spørsmålet handler mer om hvordan man skal tolke memtest86 + -utgangen. Jeg har gitt et spesifikt eksempel på memtest86 + -utgang og spør for å få hjelp til å konfigurere memmap tilsvarende i dette spesielle tilfellet. 2. Du bør kjøre memtest86 + etterpå for å bekrefte at dette argumentet er riktig. " – memtest86 + kjører før en OS-kjerne, så jeg tviler alvorlig memmap Linux-kjernealternativet kan påvirke det.
  • @Ivan, 1. Jeg trodde det var åpenbart gitt eksemplene jeg inkluderte, men du ' d trenger å si noe sånt som: memmap=5M$759M for ditt spesielle tilfelle, gitt memtest86 + mislykkes ved 759,5 MB. 2. Jeg mente at du skulle sende alternativet memmap=... til memtest86 + også. Det var uprøvd / ubekreftet av meg, men noe du kanskje kan gjøre med memtest86 +.
  • Ok, takk. Jeg var ikke sikker på hva " 002f796c48 – 759,5 MB " betyr (kanskje det kan være 759,5 megs etter 002f796c48-adressen eller noe sånt ) og jeg har aldri mistenkt at jeg kan overføre Linux-kjerneparametere til MemTest86 + (jeg trodde det ikke var noe med Linux å gjøre).

Svar

Memtest86 + (jeg brukte 4.20) kan sende et badram-format direkte.

  1. Trykk på «c» for å komme til konfigurasjonsdialogen dialogbok for memtestkonfigurasjon

  2. Deretter «4» for «Feilrapportmodus»

    memtest feilrapportmodus dialog

  3. Deretter «3» for «BadRAM-mønstre»

Utdataene vil endres fra en liste over individuelle testfeil til en serie badram = linjer, som hver inneholder en ny dårlig sektor. Fordi linjene føyes sammen og samles tilstøtende segmenter, kan du bare kjøre testen hodeløs over natten og bruke den endelige trykte linjen (men hvis du har en veldig dårlig dimning, vil det mindre nøyaktige formatet «5 megs rundt dette punktet» sannsynligvis være ganske kortere

Sluttresultat:

Memtest86 + viser badram-utdata

Kommentarer

  • Nå hvis jeg ikke ' ikke måtte kopiere det for hånd og i stedet levere det til GRUB uten å skrive feil på nytt, ville det være fantastisk.
  • Det jeg gjorde er å ta et bilde av det (kameratelefon), laste det opp i GIMP, = > gråtoner = > invert = > contrast / gamma og gi den deretter til tesseract ${IMG} stdout .. bekreft deretter og korriger linjen før du setter inn i / etc / default / grub … Sannsynligvis tok det like lang tid som å angi det manuelt med en gang ^^
  • Definitivt morsommere enn å gjøre det manuelt ugh

Svar

Veldig skittent og veldig hyggelig arbeid: kjør en brukerplassmemester, vent til den finner en feil. La det for eksempel være på 0xfce2ea31.

Kjør deretter memtester igjen, men på den fysiske adressen, så:

memtester -p 0xfce20000 64k 128 

Å være sikkert, det er bedre hvis du ofrer mer enn siden til den problematiske adressen.Her ofret vi 64kByte rundt den defekte adressen.

Hvis alt gikk bra, vil det finne den defekte minneplasseringen, mye raskere, igjen.

Avbryt deretter memtesterprosessen med en ctrl / z.

Konsekvens: inntil memtesterprosessen er suspendert, vil den ikke ta bort mer ressurs, men ingen annen prosess vil kunne få tilgang til feil på minnet . Fordi det vil bli tildelt av memtesteren.

Spesielt nyttig på store eksterne servere. Den suspenderte prosessen kan bli til den nye RAM-en ikke blir sendt. Eller kanskje til neste jul, når nedetid ikke vil være så stort problem.

Kommentarer

  • I stedet for dette trikset kan du også bruke chmem verktøyet i util-linux for å be kjernen om å ta et bestemt minneområde offline (flytte dataene andre steder og deretter aldri bruke sidene på nytt) .
  • @TooTea Jeg prøvde dette verktøyet på flere maskiner, og det kunne ikke d deaktiver en enkelt minneblokk.

Legg igjen en kommentar

Din e-postadresse vil ikke bli publisert. Obligatoriske felt er merket med *