Spotkałem się na Raspberry PI 3. W wyniku dużego obciążenia (raczej pamięci, niż CPU) potrafi się zawiesić w taki sposób, że kernel działa, ale userland nie -- np. jak łączę się telnetem na port ssh, to przyjmuje połączenie (kernel), ale już nie odpowiada welcome stringiem.
W logach (w tym wysyłanych zdalnie po UDP na inny serwer) też nic nie ma.
Nie doszedłem jeszcze, co to powoduje. Zasilanie jest mało prawdopodobne, bo zasilacz ma duży zapas, ale może dla spokoju obejrzę to zasilanie pod oscyloskopem (może na kondensatorach zaoszczędzili, może przewody za długie)...
Ta informacja dot. tylko opi, na forum opi jest cały wątek o tym i ostrzeżenie a nawet petycja do producenta, żeby zaprzestał dystrybuować nieprawidłowo skonfigurowanego softu (sic!)na oficjalnej stronie...
Robiłem testy porównawcze dd z i bez gzipa oraz stress/stress-ng i różnice temperaturowe cpu są praktycznie żadne. Wynika to zapewne z tego, że coś (różne w zalezności od metody) się w końcu gdzies i tak zapycha i pełnej utylizacji zasobów cpu i tak nie będzie.
Pytanie, czy dd z pustego (/dev/zero) w próżne (/dev/null) używa w ogóle sprzętowo I/O. IMO powinno się to dziać tylko w obrębie procesora, bo gdzie (do którego fizycznego urządzenia) to I/O miałoby iść?
Walka trwa. Od soboty uruchomiłem trzecią płytkę z wcześniejszego zakupu. Do dziś chodzi bez zarzutu. Teraz pytanie: czy można bezkarnie przekładać kartę z systemem z płytki na płytkę? Zakładam, że są sprzętowo identyczne. I żeby nie było że zadaję głupie pytania: przekładałem i działa, ale zastanawiam się czy nie wpłynie to negatywnie na wiarygodność testów.
Można, chyba że (np.) gdzies na twardo jest zdefiniowana zalezność czegoś od MAC kontrolera sieci i to coś sie inaczej zachowuje z innym MACiem, ale byłby to tak rzadki przypadek, że można śmiało olac.
Używam intensywnie od ponad roku i na początku zwisy miałem w dwóch przypadkach: przy pomyłce w FEX (jak zaczynałem to nie było jeszcze oficjalnej obsługi Orange Pi Zero i przerabiałem z Orange Pi One), jak się ciepło zrobiło.
Po doprowadzeniu powyższego do ładu uptime miałem ponad 300 dni. A teraz byłoby blisko 400 gdybym nie musiał zrobić restartu przy okazji modyfikacji zasilania/podmiany jądra.
Sprzęt zajmuje się głównie przerzucaniem pakietów po sieci i USB-owym RS-485.
W tej chwili support dla Orange Pi Zero już jest tak więc o ile używasz kernela 3.4 to sugeruję upewnić się, że masz dobrze podlinkowany /boot/script.bin.
Natomiast jeśli chodzi o termikę to profilaktycznie proponuję podkleić choćby najmniejszy radiator na chipa.
Przy czym nie należy się bać temperatur na poziomie 40-50 stopni.
Welcome to ARMBIAN 5.38 stable Debian GNU/Linux 8 (jessie) 3.4.113-sun8i System load: 0.18 0.21 0.22 Up time: 88 days Memory usage: 13 % of 494MB IP: *.*.*.* CPU temp: 44°C Usage of /: 13% of 14G
U mnie niestety coś tam banglam GPIO. Bardzo możliwe, że większość zwisów ma związek z jakąś niepoprawną obsługą GPIO, ale miałem też przypadki zamrożenia się płytki, z którą kompletnie nic nie robiłem (być może samo zainicjowanie GPIO czy eksporty robią problem), ale fakt - płytka, na której nic nie kombinuję z GPIO działa zwykle najdłużej. Aktualnie przeniosłem projekt na Raspbery Pi Zero W i od kilku dni intensywnie testuję - na razie żadnych zwisów. Docelowo muszę mieć połączenie po ethernecie - nie wiem jeszcze w którą stronę pójść.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.