„Błąd szyny” – opis problemu
Od pewnego czasu miałem ciągłe problemy z moim komputerem stacjonarnym. Zawieszał się, restartował, wywalały się X’y, rozłączały karty sieciowe czy też nagle tracił całą tablicę routingu dla sieci domowej. Winę za to zwalałem na Debiana Sid z kilkoma paczkami z Experimental. Czasem pomagała reinstalacja pakietu, czasem zmiana wersji, czasem zaś restart komputera. Do dziś...
Włączając rano komputer zaniepokoił mnie komunikat apt’a:
(...) ldconfig: /usr/lib/libdb-4.6.so - plik jest skrócony (...)
... i tak kilkukrotnie. Googlowanie niezbyt mi pomogło, musiałem wychodzić do pracy. Zostawiłem włączony sprzęt.
W pracy zauważyłem ciekawą rzecz – padł mi serwer poczty. Szybkie logowanie do domku po ssh, postfix i:
# postconf -e Błąd szyny
Eeee? Mało tego:
# postfix Błąd szyny
że co?!
$ iceweasel -no-remote Błąd szyny
Nie no, to za wiele….
# apt-get install --reinstall iceweasel segmentation fault Błąd szyny
Opis błędu
„Błąd szyny” to tak naprawdę SIGBUS wysłany do procesu. Świadczy on o złym przydzieleniu miejsca w pamięci operacyjnej dla procesu, przez co nie może on zostać wykonany. Najczęściej przyczyną „błędu szyny” jest uszkodzenie pamięci RAM.
Analiza błędu
Wykonałem (zdążyłem wykonać) 2 czynności:
# memtester 500MB
Które szło sobie w tle dość szybko, oraz:
# strace postfix
Które pokazało bardzo ciekawą rzecz:
(...)
open("/usr/lib/libdb-4.6.so", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\260a\1"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=1336100, ...}) = 0
mmap2(NULL, 1340944, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7e79000
mmap2(0xb7fbb000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x142) = 0xb7fbb000
mmap2(0xb7fbe000, 9744, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7fbe000
****** SIGBUS *******
#
Odwołanie do pliku /usr/lib/libdb-4.6.so siedzącego w 0xb7fbe000 powodowało SIGBUS. Podejrzenie padło na tą właśnie komórkę pamięci. Przyjrzałem się dokładnie /usr/lib/libdb-4.6.so i co się okazało to już chyba łatwo przewidzieć. Biblioteka ta siedziała sobie na tym adresie pamięci a każde odwołanie do tej komórki kończyło się SIGBUS. Przełączenie konsoli na lecącego w tle memtestera pokazało prawdę – memtester wyrzucił SIGBUS a po kilkunastu sekundach miałem piękny kernel panic… Co oczywiście poskutkowało utraceniem połączenia SSH.
Morał
Jeśli kiedykolwiek napotkacie na SIGBUS w swoim komputerze, na dziwne błędy w stylu „Błąd szyny” bądź też na niestabilną pracę wielu niezależnych programów – przetestujcie swoje komponenty, w szczególności pamięć RAM i nie bagatelizujcie problemu… A teraz modlę się aby sprzęt w domu dało się odratować.
Tu nie modlitwa potrzebna tylko nowy ram, ew. backup :-)
Morał jest inny - serwer stawia się na sprawdzonym sprzęcie. :)
Po pierwsze, wystartuj memtesta samodzielnie, nie z poziomu OS. Przy okazji możesz włączyć pokazywanie błędów jako wzorów badram. Po drugie, przygotuj sobie kernel z patchem badram i wywołaj go z odpowiednimi parametrami. Masz sporą szansę na rozwiązanie problemu software'owo, tracąc kilka kB RAM, bez grzebania w bebechach i tracenia kasy.
@ÆrionÆteb - backupy oczywiście są robione, nowy RAM trzeba będzie kupić...
@Przemek - ha! W tym rzecz że on był sprawdzony. Jako mały router + serwer domowy tylko dla mnie i 2-3 kolegów był idealny. Nikt nie mógł nawet przypuszczać że to się rozwali...
@rozie - memtest poszedł z samego rana jak tylko wróciłem do domu. Nie mogłem zapuścić go zdalnie :). Wykrył troszkę błędów. Nad badram zacząłem się zastanawiać już wczoraj, zobaczę co z tego będzie. Na razie sprawdzam różne ustawienia kości - może to uszkodzenie slotu w płycie a nie samej kości. Kiedyś kolega tak miał - przełożył duale w inne sloty i zaczęło banglać.
Idę grzebać :]
Heh, to ciekawe... miałem kiedyś sigbusa na solarisie w 127a/D2... i u siebie, ale okazało się (po dłuższym badaniu), że mój kompilat jądra był do kitu. Od tej pory zwykle korzystam z dystrybucyjnych jąder; nie chce mi się tracić czasu na takie rzeczy.
Na razie przeinstalowałem libdb4.6 i przełożyłem kostki RAM do innych slotów. Memtest przechodzi bez bólu (13 przejść, więcej mi się nie chciało czekać. 5 godzin). Spróbuję nowego planistę z 2.6.23 z badramem jeszcze - ciekawe jak to działa.
Od razu uprzedzam, że z niektórymi kernelami i patchem do badram miałem problem. 2.6.19 na pewno działa (na nowsze nie miałem czasu). Zresztą są wpisy gdzieś u mnie. ;)
Tak niskiego kernela nie mogę zapodać - poniżej 2.6.20 mam problemy z obsługą kontrolera dysku :-/ Ale z tego co wiem nowy planista w 2.6.23 ma jako EXPERIMENTAL bardzo podobną opcję co badram. Przynajmniej takie wieści w barze ostatnio zasłyszałem :)
@Liorithiel: na sparcu? jeśli tak to możliwe wystarczy zła operacja na wskaźnikach. ew w samym Solarisie na x86 chyba też jest w niektórych przypadkach możliwe.
na x86 nie ma czegoś takiego jak błąd szyny, jeśli występuje to oznacza właśnie problemy z pamięcią