Nie jesteś zalogowany.
Jeśli nie posiadasz konta, zarejestruj je już teraz! Pozwoli Ci ono w pełni korzystać z naszego serwisu. Spamerom dziękujemy!
Prosimy o pomoc dla małej Julki — przekaż 1% podatku na Fundacji Dzieciom zdazyć z Pomocą.
Więcej informacji na dug.net.pl/pomagamy/.
Witam,
Pracuję w firmie w której używamy Debiana na 'mini komputerkach' do budowy czegoś w rodzaju hotspotów.
Mamy na nich zainstalowanego Debiana (Lenny) z kompilowanym ręcznie kernelem (z kernel.org).
Ostatnio nasze hotspoty zaczęły 'cierpieć' na nagłe 'pady'.
Objawia się to tym że hotspot po prostu przestaje działać (power led się świeci ale system 'nie działa') - monitor jest czarny, reakcja na klawiaturę zerowa.
W logach kompletnie nic co by wskazywało na przyczynę 'padu', po prostu dziura w logach od 'padu' do restartu. Przed padem 'normalne' logi (żadnych Ooops-ów, stacktrace-ów czy czegoś świadczącego o błędzie). Dmesg kończy się kilka minut po zbootowaniu i później brak w nim jakichkolwiek eventów.
Raz na minutę chodzi cron więc w syslogu widać kiedy wykonał się po raz ostatni - po tym widać dopiero pierwsze linie nowego 'bootowania' po restarcie.
Jan 27 00:09:01 user /USR/SBIN/CRON[30752]: (root) CMD (bash -c '/app/scripts/update_website >> /app/log/tasks.log 2<&1') Jan 27 00:09:01 user /USR/SBIN/CRON[30753]: (root) CMD (bash -c '/app/scripts/monitor_vpn >> /app/log/tasks.log 2<&1') ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@Jan 27 10:12:39 user kernel: imklog 3.18.6, log source = /proc/kmsg started. Jan 27 10:12:39 user rsyslogd: [origin software="rsyslogd" swVersion="3.18.6" x-pid="3153" x-info="http://www.rsyslog.com"] restart
Dokąd używaliśmy kernela 2.6.38 raczej nam się to nie zdarzało (przynajmniej nie zauważaliśmy niczego takiego). Potem zaczęliśmy używać 2.6.39-4 i się to zaczęło - teraz używamy 3.2.1 i dalej się to dzieje. Od 2.6.39-4 dodaliśmy moduł hso (do obsługi modemów GSM Option-a).
Nie za bardzo mogę go wyrzucić bo używamy tych modemów. Jedyne co mi przychodzi do głowy to blacklistowanie modułu na hotspotach które nie mają modemu i zobaczenie czy na tych hotspotach pady się nie przytrafią (ale kto wie jak długo trzeba będzie czekać na kolejny pad) .
Czy macie jakiś pomysł na debugowanie 'co spowodowało pad' w takich przypadkach?
Offline
Lenny może być niezbyt kompatybilny z kernelami 2.6.39 i wyżej, ponieważ w 2.6.39 zaszły spore zmiany w ACPI.
Radzilbym przeprowadzkę na Squeeze (6.0.3), który ma aktualne wsparcie (Lenny już chyba tylko security-updates), bo prawdopodobnie coś dotyczy ACPI.
Miedzy jajem 2.6.26 z Lennyego, a 3.2 jest trochę duża odległość.
Natomiast Squeeze co prawda bazuje na jaju 2.6.32, ale w backportach ma wersje 2.6.39, i na kernelach 3.x też powinien chodzić.
Edit:
W backportach Squeeze jest też jajo:
linux-image-3.2.0-0.bpo.1-686-pae
Pozdro
;-)
Ostatnio edytowany przez Jacekalex (2012-01-27 12:55:26)
Offline
Niestety zmiana Lennego nie wchodzi za bardzo w grę bo używamy jakiejś biblioteki bluetoothowej zależnej chyba od libbluetooth2 (więc konieczny byłby downgrade pakietów do takich archaicznych wersji).
Myślisz że to ACPI ? Da się jakoś 'włączyć' logowanie takich zdarzeń ?
Offline
Nie myślę, że to ACPI, ale myślę, że to kernel.
A w wersji 2.6.39 i późniejszych były spore zmiany w APCI - które zaobserwowałem u siebie, na 2.6.38 komp chodził, na 2.6.39 tylko z wyłączonym ACPI, wreszcie na 2.6.39.4 ruszył po aktualizacji biosu.
Inne zmiany też były, ale z racji faktu, że z kernelami od 2.6.20.16 do 3.2.2 żadnych większych problemów poza tym wypadkiem z ACPI nie miałem, myśle, że to możliwe.
Ewentualnie jakieś błędy w sterownikach, lub nieprawidłowa współpraca kernela i userspace.
Bo userspace poza możliwością wywołania kernel-panic, nie ma innych możliwości zawieszania kompa, jeśli nie towarzyszy temu hardcorowy błąd w kernelu.
Co do biblioteki libbluetooth2 , to na 60% bzdura, na 30% lenistwo, a na 10% problem z softem.
Ewentualnie możesz chyba spróbować skompilować starą bibliotekę, al;bo zainstalować na nowym systemie paczki ze http://snapshot.debian.org/
Squeeze obsluguje bluetooth bez problemu, włącznie z urządzeniami BT ktore mają kilka lat, także nie czaję argumentu, co to za tajemniczy soft, który jakis idiota zrobil program do max takiej a siakiej wersji biblioteki libbluetooth.
Api bluetooth nie zmienilo się specjalnie.
Co do logów, to po to jest foder /var/log. a w nim pliki syslog i messages, zeby do nich czasem zajrzeć.
Jest też polecenie dmesg - ktore pokazuje logi kernela, i gdzie sa pokazane akcje wszystkich sterowników, acpi, itp.
Np:
root # dmesg | grep dvb [ 9.224498] cx88/2: cx2388x dvb driver version 0.0.9 loaded [ 9.224502] cx88/2: registering cx8802 driver, type: dvb access: shared
Poza tym popytaj w kontekście kłoptu z wersją libblue* na Squeeze [b][url=http://forum.dug.net.pl/profile.php?id=1704]NICA[/url][/b] - on jest chyba najlepszym specem od BT na forum, i dobrym [url=http://forum.dug.net.pl/viewtopic.php?pid=148866#p148866]hakerem C[/url].
To by było na tyle
;-)
Ostatnio edytowany przez Jacekalex (2012-01-27 14:05:26)
Offline
[quote=Jacekalex]Nie myślę, że to ACPI, ale myślę, że to kernel.
A w wersji 2.6.39 i późniejszych były spore zmiany w APCI - które zaobserwowałem u siebie, na 2.6.38 komp chodził, na 2.6.39 tylko z wyłączonym ACPI, wreszcie na 2.6.39.4 ruszył po aktualizacji biosu.[/quote]
Ok spróbuję może skompilować 2.6.38 z modułem hso jeśli się uda.
Co do biblioteki libbluetooth2 , to na 60% bzdura, na 30% lenistwo, a na 10% problem z softem.[/quote]
Soft używa biblioteki avetanaBT - próbowałem kompilować ją u siebie jakiś czas temu na Arch-u i nic mi z tego nie wyszło więc odpuściłem (niestety zostałem 'wrzucony' w dość rozbudowany i już trochę 'przestarzały' softwarowo projekt więc boję się trochę za dużo ruszać żeby coś się nie z...epsuło).
A 'góra' jak zwykle uważa że nie ma potrzeby czegokolwiek updatować (bo przecież do tej pory działało) a wszystko ma działać jak złoto łącznie z nowymi featurami.Co do logów, to po to jest foder /var/log. a w nim pliki syslog i messages, zeby do nich czasem zajrzeć.
Jest też polecenie dmesg - ktore pokazuje logi kernela, i gdzie sa pokazane akcje wszystkich sterowników, acpi, itp.[/quote]
Tyle wiem ;) zaglądałem i do sysloga, dmesg-a, kernel.log-a i messages i nawet daemon.log-a ale w żadnym nie było nic co by przypominało błąd/wyjątek cokolwiek co by wyjaśniało zwiechę. Miałem nadzieję że gdzieś się da zwiększyć jakiś debug-level żeby logi były bardziej szczegółowe.Poza tym popytaj w kontekście kłoptu z wersją libblue* na Squeeze [b][url=http://forum.dug.net.pl/profile.php?id=1704]NICA[/url][/b] - on jest chyba najlepszym specem od BT na forum, i dobrym [url=http://forum.dug.net.pl/viewtopic.php?pid=148866#p148866]hakerem C[/url].[/quote]
Dzięki za pomoc i trop z kernelem.Ostatnio edytowany przez kaczor1984 (2012-01-27 15:40:12)
Offline
Skompilować "avetanaBT" to nie problem, troszkę drobnych poprawek na ich system budowania, troszkę kodu usunąć, zmienić jedną nazwę metody i kompiluje się u mnie. Pytanie tylko czy to działa, ale był bym dobrej myśli.
To było jakoś tak:
{na wstępie zaznaczam że mam x86, 32bit, kernel "prawie" 3.2 i bluez 4.96+; current dir: /src/cvs/avetanabt/ }
1. cvs -z3 -d:pserver:anonymous@avetanabt.cvs.sourceforge.net:/cvsroot/avetanabt checkout avetanabt # lub paczka z SourceForge: avetanabt-20070719.tgz
2. aclocal
3. autoconf
4. ./configure
5. W "Makefile" hakujemy podając absolutną ścieżkę do katalogu budowania (bo jest niepodana, nie wnikam w ten system budowania; to brudny hak, ale bezpieczny), np.
BIN_DIR = /src/cvs/avetanabt/avetanabt/build/
6. To samo co w 5. w "c/Makefile"
7. w c/Makefile zmienić kompilator z "g++" na "gcc" (CC = gcc)
8. w c/Makefile do CFLAGS dodać "-fpermissive" (nie wiem na ile to bezpieczne... ale sam kompilator wprost podał tą flagę przy errorach... ale to bez znaczenia w sumie... i tak trzeba testować cały produkt (podsystem Bluetooth), tj. albo działa albo nie)
9. wyrzucić z c/sdp_internal.h całą metodę "static inline uint64_t ntoh64(uint64_t n)"
10. w c/ zmienić "hci_local_name" na "hci_read_local_name"
11. make
Z czego po 7. winno się robić 11. i poprawiać to co faktycznie kompilator wywali.
Ostatnio edytowany przez NIC (2012-01-28 02:10:30)
Offline
Dzięki za pomoc NIC.
Jeśli kernel bez ACPI nie poprawi sytuacji (okazuje się że włączyłem moduły od ACPI przy kompilowaniu 2.6.39-4 a wcześniej były wyłączone) to pewnie skorzystam z poradnika. Ja próbowałem na Archu 64bit więc tym więcej było 'kruczków'.
Offline
Time (s) | Query |
---|---|
0.00010 | SET CHARSET latin2 |
0.00004 | SET NAMES latin2 |
0.00129 | SELECT u.*, g.*, o.logged FROM punbb_users AS u INNER JOIN punbb_groups AS g ON u.group_id=g.g_id LEFT JOIN punbb_online AS o ON o.ident='3.142.43.244' WHERE u.id=1 |
0.00065 | REPLACE INTO punbb_online (user_id, ident, logged) VALUES(1, '3.142.43.244', 1732389492) |
0.00039 | SELECT * FROM punbb_online WHERE logged<1732389192 |
0.00060 | DELETE FROM punbb_online WHERE ident='18.117.156.170' |
0.00043 | SELECT topic_id FROM punbb_posts WHERE id=191993 |
0.00004 | SELECT id FROM punbb_posts WHERE topic_id=20510 ORDER BY posted |
0.00027 | SELECT t.subject, t.closed, t.num_replies, t.sticky, f.id AS forum_id, f.forum_name, f.moderators, fp.post_replies, 0 FROM punbb_topics AS t INNER JOIN punbb_forums AS f ON f.id=t.forum_id LEFT JOIN punbb_forum_perms AS fp ON (fp.forum_id=f.id AND fp.group_id=3) WHERE (fp.read_forum IS NULL OR fp.read_forum=1) AND t.id=20510 AND t.moved_to IS NULL |
0.00027 | SELECT search_for, replace_with FROM punbb_censoring |
0.00095 | SELECT u.email, u.title, u.url, u.location, u.use_avatar, u.signature, u.email_setting, u.num_posts, u.registered, u.admin_note, p.id, p.poster AS username, p.poster_id, p.poster_ip, p.poster_email, p.message, p.hide_smilies, p.posted, p.edited, p.edited_by, g.g_id, g.g_user_title, o.user_id AS is_online FROM punbb_posts AS p INNER JOIN punbb_users AS u ON u.id=p.poster_id INNER JOIN punbb_groups AS g ON g.g_id=u.group_id LEFT JOIN punbb_online AS o ON (o.user_id=u.id AND o.user_id!=1 AND o.idle=0) WHERE p.topic_id=20510 ORDER BY p.id LIMIT 0,25 |
0.00071 | UPDATE punbb_topics SET num_views=num_views+1 WHERE id=20510 |
Total query time: 0.00574 s |