"Bad page state in process" i restart X

[tsiru]

Witam, niedawno zainstalowałem świeżego gentoo - poprzedni system zaśmiecił się podczas pierwszych kroków z linuksem, restartował się, Ciął, kernel panic i inne rzeczy, po których poprawieniu wychodziły następne.
Po reinstalacji co jakiś czas X się restartują, a dmesg zwraca takie coś:

Kod: [Zaznacz]

Bad page state in process 'X'
page:c1b5d480 flags:0x80000008 mapping:00000000 mapcount:16 count:0
Trying to fix it up, but a reboot is needed
Backtrace:
Pid: 19574, comm: X Tainted: P         2.6.25-gentoo-r7 #1
  bad_page+0x52/0x7a
  free_hot_cold_page+0x5b/0x156
  unmap_vmas+0x278/0x4a6
  unmap_region+0x86/0xec
  do_munmap+0x148/0x19b
  sys_munmap+0x27/0x35
  sysenter_past_esp+0x5f/0x85
 =======================
Bad page state in process 'X'
page:c1745480 flags:0x80000008 mapping:00000000 mapcount:16 count:0
Trying to fix it up, but a reboot is needed
Backtrace:
Pid: 19574, comm: X Tainted: P    B    2.6.25-gentoo-r7 #1
  bad_page+0x52/0x7a
  free_hot_cold_page+0x5b/0x156
  unmap_vmas+0x278/0x4a6
  unmap_region+0x86/0xec
  do_munmap+0x148/0x19b
  sys_munmap+0x27/0x35
  sysenter_past_esp+0x5f/0x85
 =======================

i nie mam bladego pojęcia jak to ugryźć, czy to wina złej konfiguracji systemu czy samego sprzętu.
Będę bardzo wdzięczny za jakieś konkretne wskazówki.

[WizardNumberNext]

Całkiem możliwe, że masz uszkodzoną pamięć - przeleć

Kod: [Zaznacz]

memtest86

lub

Kod: [Zaznacz]

memtest86+

najlepiej z 10 razy.
Jest to najbardziej prawdopodobna przyczyna.
Pamięci nie naprawisz - jest tylko jedno wyjście, jeżeli jest padnięta to trzeba wymienić.
Tak czy inaczej zrób test - będziesz pewny.
Jeżeli się okaże, że to pamięć to tylko szkoda twojego czasu, który poświęciłeś na postawienie nowego gentoo.

Jest jeszcze jedna możliwa przyczyna - jajko - 2.6.25 i 2.6.26 mają skopane VDSO - ja bym tego nie instalował - spróbuj z 2.6.24 lub (najlepiej) 2.6.23. JA używam 2.6.23.17 na stacji roboczej (nowszego nie mogę), a na server'że 2.6.24.7 (też nowszego nie mogę). Bardzo sobie chwalę 2.6.23.17 i je polecam.

P.S. Jeżeli to pamięć to stawianie od nowa gentoo wybij sobie z głowy - każde gentoo, będzie siadnięte, ponieważ kompilacja też przebiega w pamięci - też powstają błędy.

UWAGA!!! Kompilować można tylko na sprawnej pamięci - kompilacja na padniętej pamięci wygeneruje niepoprawny kod, który może co najmniej padać sam, a co najwyżej razem z kompem!

[arctgx]

Kod: [Zaznacz]

memtest[b]9[/b]6+

Już chwyciłem za wyszukiwarkę zobaczyć, czym się 96+ różni od 86 czy 86+ A że ta za bardzo nie chciała niczego sensownego wskazać, rozumiem że to literówka...

Bliżej tematu: uszkodzony procesor też potrafi czynić cuda. Sam miałem kilka lat temu podobne problemy za jego sprawą (pamięć uszkodzona była swoją drogą). Wymiana procka przy zachowaniu starej kości pamięci pozwoliła używać trochę więcej programów do czasu kupienia nowej.

Większym cudotwórcą okazała się dawno temu osoba składająca moją pierwszą maszynę i zajmująca się zresztą sprzedażą nowego sprzętu. Wtedy przez półtora roku mój tamtejszy Duron 1300 grzał w normalnych warunkach 58 stopni C, a przy wydajniejszych operacjach chłodziłem go stołowym wiatrakiem

Kiedy już zaczął sypać coraz więcej awarii, zdjąłem go i okazało się że radiator obrócony był o 180 stopni i jakaś piąta część powierzchni rdzenia była odkryta...

Od tamtej pory montowałem sprzęt sam, a pamięci brałem tylko z długą gwarancją.

[WizardNumberNext]

Bardzo przepraszam za literówkę. Chodziło o 'memtest86+, po prostu palec powędrował trochę za daleko. Poprzedni post już poprawiłem.

[tsiru]

Sprawdziłem ram, jest ok
Potem zacząłem przekładać części z 2 podobnego komputera metodą prób i błędów, na pierwszy ogień poszedł właśnie procesor i był to strzał w dziesiątkę
Po wymianie athlona 2500 na semprona 2200 działa stabilnie.
A co do jajka to wrócę chyba do 2.24, bo vmware nie chce ruszyć na nim.
Dzięki za naprowadzenie

[arctgx]

Czysty przypadek - gdyby mnie ta "nowa odmiana" memtestu nie zainteresowała i WizardNumberNext nie wspomniałby o pamięci, pewnie nie przypomniałbym sobie historii z procesorem

[WizardNumberNext]

arctgx: Miałem identyczną historię - u mnie padł mmx w 'amd k6-2'. Padł przez ukruszenie procka. Aby procek działał w miarę normalnie musiałem go nieźle grzać (3.2V zamiast 2.2) i przez to kruszył się dalej, aż doszedłem do rejestrów albo cache - wtedy miałem identyczne objawy.

tsiru: Do VMWare są potrzebne moduły jądra - na nowszym jąderku najnowsze 5.5.x nie działa jak należy, ale jest specjalna łatka wsteczna do starszych jąder i ona działa na 2.6.23.17 oraz 2.6.24.7 - sprawdzałem.

P.S. Co do pamięci: ja nigdy nie miałem uszkodzonej pamięci - tylko właśnie procesor.

tsiru: koniecznie postaw gentoo od nowa na tym sempron'ie - podejrzewam, że masz poważnie uszkodzone binarki.
flagi które warto włączyć do gcc i całej reszty:

Kod: [Zaznacz]

-mmmx -m3dnow -msse -mfpmath=sse,387 -march=athlon-xp -mcpu=athlon-xp -mtune=athlon-xp 
-Os -finline-functions -funswitch-loops -fgcse-after-reload -fomit-frame-pointer -pipe -s 
-DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_3DNOW_PREFETCH

Podzieliłem powyższą linie (to jest jedna linijka) na trzy:
flagi optymalizacji docelowych (do mmx 3dnow sse procesor)
flagi optymalizacji kodu - niezależne od architektury procesora
flagi optymalizacji przy użyciu asemblera
Całkiem mozliwe że można jeszcze użyć

Kod: [Zaznacz]

-DUSE_SSE_ASM

lecz tego nie sprawdzałem
Jak użyjesz tych flag to szybciej się już nie da nie zmieniając kodu źródłowego. Ja użyłem prawie identycznych flag do kompilacji glibc6 oraz linux kernel - działa.

[arctgx]

mnie padł mmx w 'amd k6-2'.

Czy jest jakieś ogólnodostępne polecenie pozwalające ocenić czy instrukcje z MMX (lub spod innej flagi) działają poprawnie? Czy też trzeba napisać sobie i odpowiednio skompilować specjalny kod lub może wystarczy zerknąć do /proc/cpuinfo i stwierdzić że nie widać ? Mając takiego procka stwierdziłbym po prostu że cały jest do bani, a może dałoby się go wykorzystać, omijając źle wykonywane instrukcje.

[WizardNumberNext]

Jak stwierdziłem, że padł mi mmx?
To proste - straciłem regulację kolorów oraz przetwarzanie kolorów (w ogóle miałem dziwne kolory nawet mam gdzieś screen'a).
A mmx jest też wykorzystywany w kopiowaniu dużych bloków pamięci - tutaj od razu miałem złe strony pamięci.
W cpuinfo czy w wyniku z x86info i tak by był mmx - takie rzeczy śa zakodowane w cpuid, nie jest to wykrywane dynamicznie (ba nawet nie ma takiej możliwości).
Nawet jak mi padły rejestry z FPU (a więc również straciłem całkiem mmx - jakiekolwiek odwołanie do mmx kończyło się bardzo dziwnym zachowaniem - i byłem szczęśliwy jak to był tylko reset) to system jak i procesor nadal próbowały używać FPU i MMX.

[micu]

Mógł paść cache w procesorze.
Zobaczcie jaki kawał procesora zajmuje pamięc podręczna drugiego/trzeciego poziomu:  
http://twojepc.pl/news5989.html (z artykułu o Athlonie) i http://pclab.pl/art14028.html (Pentium 4 dla odmiany).
Uszkodzony cache daje objawy praktycznie identyczne z uszkodzoną pamięcią RAM.

[WizardNumberNext]

Uszkodzony cache daje objawy praktycznie identyczne z uszkodzoną pamięcią RAM.

Objawy są identyczne! Dlaczego? Cache przechowuje fragmenty pamięci i to z niego procesor czyta - efekt procesorowi się wydaje, że to pamięć dostarczyła uszkodzoną stronę.

[arctgx]

Skoro o L2, to w opisywanej sytuacji wyłączenie w BIOSie na uszkodzonym Duronie dawało (jeśli dobrze pamiętam, to 4 lata temu) pracę stabilniejszą (więcej programów dało się odpalić, niestety nie pamiętam wyników memtestu), ale tak powolną, że nie było sensu normalnie pracować.

Na nowym procku ze starą pamięcią dało się pracować na IceWM i Blenderze, ale GNOME czy KDE dawały regularnie szybką wiechę.

[tsiru]

@WizardNumberNext:
komputer pochodzi na tym sempronie parę dni, już załatwiłem sobie athlona 3000+ (oczywiście też barton), więc sensu rekompilować system pod semprona nie widze, ale podłubie przy flagach, bo to calkiem niezły pomysł
Uszkodzony procesor tymczasowo wcisnąłem do 2 kompa, i o dziwo tam działa już kilka dni, ale na wszelki wypadek nic nowego nie instalowałem tam, głównie ogląda się na nim filmy (też gentoo).
Za to zanim zrozumiałem co tym z kompem jest nie tak, zainstalowałem pare rzeczy, np nasm i yasm się wykrzaczyły, ale po reinstalacji działają

[WizardNumberNext]

arctgx: wyłączanie L2 cache w 'AMD K6-2' - nie ma sensu - nie da się wyłączyć L2 cache w 'AMD K6-2', ponieważ L2C jest poza prockiem.
tsiru: gratulacje wyboru - mam też barton'a 2500/166 (w następnym tygodniu zakładam).
Tak czy inaczej cokolwiek skompilowałeś na tym uszkodzonym procku, może cierpieć na syndrom 'złych stron' - i nie bagatelizuj tego ostrzeżenia - skutki działania na w ten sposób zabugowanym systemie mogą katastrofalne - łącznie ze spaleniem najważniejszych podzespołów komputera.
Piszę to z doświadczenia - na uszkodzonym procku skompilowałem jądro - efekt zabiłem 3 podobne procki, 9x256MiB RAM i trzy płyty główne. To nie jest przypadek - to było zabugowane jądro - nic więcej.