Диагностировать зависание одноплатника

Обычно у таких одноплатников есть debug uart, куда в том числе падают и сообщения ядра.

Есть смысл подцепиться к этому интерфейсу и поймать момент зависания.

Может увидите какой trace или поймёте что виснет.

Спасибо за подсказку! Попробую.

к предыдущему ответу можно добавить отправку оперативных логов на другой сервер как по классике syslog, так и чисто ядерные лого через netconsole (https://www.kernel.org/doc/Documentation/networking/netconsole.txt)

И вам спасибо!

Пока ковыряться буду, отмечу тему как решённую.

Успешно гонял стресс-тест. Значит, питальник и охлад в порядке.

Модемы со своим питанием?

Да, у них питание отдельное.

Может питание нестабильное, помехи и т.п.

Или слабое, проседает.

Когда аппарат отключается по железу - сообщений в логи он дать не успевает. В первую очередь постоянно контролируйте температуру (где нибудь в /sys/devices/virtual/thermal/thermal_zone0/temp) и ее зависимость от нагрузки. Во вторую - попробуйте другой БП. В третью - скиньте частоту процессора. В четвертую - экспериментируйте с загрузкой памяти, она тоже может быть битая. Стресс-тесты в подобных случаях мало помогает, надо играться с загрузкой вашими конкретными задачами и находить зависимости зависаний от режима.

Спасибо! Буду пробовать. Аппарат у меня не отключается, а именно зависает. Я так думаю, потому что лампочки на нём продолжают мигать. И даже лампочки сетевых интерфейсов тоже мигают, хотя он и не отвечает на пинги. Память проверять почему-то не догадался. А температуру проверял, стресстест нагревает куда сильнее чем мои задачи, и ничего.

Что там за проц, не А20 случаем?

Нет, Rockchip RK3328. А сам одноплатник — Orange Pi R1 Plus.

Orange Pi, debian от производителя

инстантом F. У них же васянские сборки от 1965 года официальными считаются.

Я бы для начала промониторил потребление. До, в момент зависания и после

Всем привет, я вернулся :) Наконец раздобыл UART-USB переходник и выяснил, что мой одноплатник не зависает, а у него отваливается сеть. И вот что вываливается в dmesg в этот момент:

[ 1685.066812] NETDEV WATCHDOG: lan0 (r8152): transmit queue 0 timed out
[ 1685.066986] WARNING: CPU: 0 PID: 0 at net/sched/sch_generic.c:467 dev_watchdog+0x390/0x398
[ 1685.067000] Modules linked in: rfkill cdc_ether usbnet r8152 cdc_acm cpufreq_dt zram usb_f_acm u_serial g_serial libcomposite ip_tables x_tables autofs4 realtek dwmac_rk stmmac_platform stmmac pcs_xpcs gpio_syscon
[ 1685.067203] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.10.44-rockchip64 #2.1.4
[ 1685.067214] Hardware name: Xunlong Orange Pi R1 Plus (DT)
[ 1685.067232] pstate: 00000005 (nzcv daif -PAN -UAO -TCO BTYPE=--)
[ 1685.067250] pc : dev_watchdog+0x390/0x398
[ 1685.067267] lr : dev_watchdog+0x390/0x398
[ 1685.067278] sp : ffff800011bfbd00
[ 1685.067290] x29: ffff800011bfbd00 x28: ffff0000051ba280 
[ 1685.067318] x27: 0000000000000004 x26: 0000000000000140 
[ 1685.067346] x25: 00000000ffffffff x24: 0000000000000000 
[ 1685.067373] x23: ffff0000047e141c x22: ffff0000047e1000 
[ 1685.067400] x21: ffff0000047e14c0 x20: ffff8000118c7000 
[ 1685.067428] x19: 0000000000000000 x18: 0000000000000000 
[ 1685.067455] x17: 0000000000000000 x16: 0000000000000000 
[ 1685.067482] x15: ffff8000118d3ac0 x14: 0000000000000239 
[ 1685.067511] x13: ffff8000118d3f70 x12: 00000000ffffffea 
[ 1685.067549] x11: ffff80001195edd0 x10: ffff800011946d90 
[ 1685.067577] x9 : ffff800011946de8 x8 : 0000000000017fe8 
[ 1685.067604] x7 : c0000000ffffefff x6 : 0000000000000003 
[ 1685.067631] x5 : 0000000000000000 x4 : 0000000000000000 
[ 1685.067658] x3 : ffff8000118cd0e8 x2 : 0000000000000103 
[ 1685.067685] x1 : 5852bed2cf27d500 x0 : 0000000000000000 
[ 1685.067711] Call trace:
[ 1685.067732]  dev_watchdog+0x390/0x398
[ 1685.067755]  call_timer_fn+0x30/0x1f8
[ 1685.067773]  run_timer_softirq+0x460/0x5d8
[ 1685.067791]  efi_header_end+0x164/0x418
[ 1685.067811]  irq_exit+0xc8/0xe0
[ 1685.067828]  __handle_domain_irq+0x98/0x108
[ 1685.067848]  gic_handle_irq+0xa8/0xe0
[ 1685.067864]  el1_irq+0xc8/0x180
[ 1685.067885]  arch_cpu_idle+0x18/0x28
[ 1685.067902]  default_idle_call+0x2c/0x1b0
[ 1685.067920]  do_idle+0x218/0x268
[ 1685.067935]  cpu_startup_entry+0x28/0x60
[ 1685.067965]  rest_init+0xd8/0xe8
[ 1685.067986]  arch_call_rest_init+0x10/0x1c
[ 1685.068004]  start_kernel+0x80c/0x848
[ 1685.068017] ---[ end trace 0c4bb2f5a1153263 ]---
[ 1685.068058] r8152 5-1:1.0 lan0: Tx timeout
[ 1689.931035] r8152 5-1:1.0 lan0: Tx timeout
[ 1690.187067] xhci-hcd xhci-hcd.0.auto: xHCI host not responding to stop endpoint command.
[ 1690.187090] xhci-hcd xhci-hcd.0.auto: USBSTS:
[ 1690.213991] xhci-hcd xhci-hcd.0.auto: xHCI host controller not responding, assume dead
[ 1690.214068] xhci-hcd xhci-hcd.0.auto: HC died; cleaning up
[ 1690.214318] r8152 5-1:1.0 lan0: Tx status -108
[ 1690.214403] r8152 5-1:1.0 lan0: Tx status -108
[ 1690.214439] r8152 5-1:1.0 lan0: Tx status -108
[ 1690.214463] r8152 5-1:1.0 lan0: Tx status -108
[ 1690.214570] usb 5-1: USB disconnect, device number 2
[ 1690.214661] r8152 5-1:1.0 lan0: get_registers -19
[ 1690.267530] r8152 5-1:1.0 lan0: Get ether addr fail

Прошу совета опытных железячников. Это и есть последствие «васянских сборок», как выразился bo4ok? Стоит ли пытаться как-то разобраться, или сконпелять своё ядро, или писать производителю? Вариант «выкинуть и взять другой» прошу не озвучивать, потому что это всегда успеется.

/me совсем не опытный железячник, но без собственноручно пересобранного ядра(со своими параметрами и полноценной отладочной информацией) с подобным разобраться - думаю будет сложно.

Я в этом не шарю, но похоже, что весь стек USB отваливается, а сеть на нём висит. Встречал подобную фигню на ранних третьих распберри, потом, видимо, в дровах сделали рестарт автоматом, и оно исчезло.

Я в этом не шарю, но похоже, что весь стек USB отваливается, а сеть на нём висит. Встречал подобную фигню на ранних третьих распберри, потом, видимо, в дровах сделали рестарт автоматом, и оно исчезло.

вон пишут сеть там на usb, отваливается под нагрузкой

https://forum.armbian.com/topic/15165-nanopi-r2s-lan0-goes-offline-with-high-traffic/page/2/

костыль:

/usr/sbin/ethtool -K lan0 rx off tx off

весь стек USB отваливается, а сеть на нём висит. Встречал подобную фигню на ранних третьих распберри, потом, видимо, в дровах сделали рестарт автоматом, и оно исчезло.

Мой опыт показывает, что не только на rpi3 такая фигня случается. На одноплатнике с каким-то amlogic тоже падал usb. Причём я тогда научился предсказуемо ронять usb. Достаточно подключить к компьютеру телефон и интенсивно дёргать второго через pyadb. На rpi вовсе достаточно сделать

$ adb devices

Вообще с падением usb сталкивался и на intel, но по другим причинам. Явно какая-то штука в ядре зарыта.

Atlant, bo4ok, kindof, Slavik763, спасибо за советы! Буду пробовать, пытаться.