ssc335de. majestic freeze, fall

[sansarus]

Device
SoC
ssc335de (infinity6b0)
Sensor
os02g10
Firmware
2.6.07.11-lite
Build
master+9d85e99, 2026-07-11
Majestic
master+1433ef2, 2026-06-25 16:43
U-Boot
U-Boot 2015.01 (Oct 27 2024 - 16:59:11)

РТ лотерея.
За неделю точно падает. Либо majestic упал, либо висит, но не откликается. Часто поток venc0_P0_MAIN может жрать проц.
Первый поток и в mxplayer и в ipeye и в preview может отображать только верхние ~10% кадра а ниже вертикальные тянучки. Второй поток без проблем.
Разрешения, кадры менял - одинаково...
Камера не боевая - используется в режиме "обновить"-"firstboot"-"проверить фичу или жалобу"-"firstboot"
Поток сосёт только ipeye, в сети только роут, 2 телефона и тв приставка (ни регов, ни других камер, ни portforwarding

logread12026.08.01 23.47.06.txt

majestic.yml2026.08.01 23.31.38.txt

dmesg2026.08.01 23.30.06.txt

majestic_start2026.08.01 23.26.36.txt

)

[sansarus]

drop_cache не спасает.
majestic живёт только с костылём в rc.local (контроль pidof majestic).

Create mi dev0
Create mi dev0
[MI WRN ]: _MI_VENC_CreateMiDevice[7816]: mi device:0 has been inited
Create mi dev1
Create mhal DEV0.
[ven-w][wrap] illegal width and height. will use default value (2688 1952)
[ven-m][wrap] venc_dev_preset:1390 GetMMaHeapName s32Ret=0xa009201f, u8MMAHeapName=.
[ven-m][wrap] fw path /etc/firmware/chagall.bin
[CMDQ1] Virtual IRQ: 30
Create mhal DEV1.
[ven-w][wrap] venc MMA callback function duplicate registration Force OverWrite!!
[ven-w][wrap] venc dev created, not support set E_MHAL_VENC_MAX_ENCODE_RESOLUTION, pls set before createdev
Create mhal DEV2.
client [3563] connected, module:divp
[DIP] Virtual IRQ: 36
client [3563] connected, module:shadow
client [3563] connected, module:ai

[sansarus]

majestic > /tmp/mlog1
до падения

majestic-log2026.08.02 11.17.06.txt

[widgetii]

A fix for one specific failure mode from this report is now in majestic master. It will reach the nightly firmware images once a new majestic build is published — I will note here when that has happened.

When you do test it, please check the build first: majestic --version prints master+<hash>, <date>. You need one dated later than 2026-08-14. If it still shows 2026-08-14 or earlier, the image contains the old binary and the test cannot tell us anything.

What changed is narrow, so it is worth saying plainly what to expect: it addresses the state where the process is still running but has stopped answering — no video, no web interface, while pidof majestic still finds it. Outright crashes are a separate problem and are not expected to be fixed by this.

Please keep your rc.local restart check. If you can, record how often it fires: a count per day, before and after, is the single most useful number here.

Then after a day of uptime, could you post:

• uptime
• curl -s http://<camera>/metrics/venc

Two counters in that output — venc_empty_frames and venc_empty_frames_run — show whether the encoder is entering the state this addresses. venc_empty_frames is cumulative, so it is the one that matters if you only look occasionally; note that it resets when majestic restarts.

---

Исправление одного конкретного сценария из этого отчёта уже в master majestic. Оно попадёт в ночные сборки прошивки после публикации новой сборки majestic — я отпишусь здесь, когда это произойдёт.

Когда будете проверять, сначала убедитесь в версии: majestic --version выводит master+<хеш>, <дата>. Нужна сборка с датой позже 2026-08-14. Если там 2026-08-14 или раньше — в образе старый бинарник, и проверка ничего не покажет.

Изменение узкое: оно касается состояния, когда процесс жив, но перестал отвечать — нет видео и веб-интерфейса, а pidof majestic его находит. Падения — это отдельная проблема, и здесь они не исправлены.

Костыль в rc.local оставьте, но по возможности запишите, как часто он срабатывает: количество за сутки до и после — самое полезное число.

Через сутки аптайма пришлите, пожалуйста:

• uptime
• curl -s http://<камера>/metrics/venc

Два счётчика оттуда — venc_empty_frames и venc_empty_frames_run — показывают, входит ли энкодер в то состояние, о котором идёт речь. venc_empty_frames накопительный, поэтому он важнее, если смотреть время от времени (он обнуляется при перезапуске majestic).

[sansarus]

majestic --version
Lite SigmaStar (infinity6b0), master+93f46ae, 2026-08-25 21:05

majestic still falling at 5-10min

while majestic restarted by rc.local metrics venc_empty_frames (and _run) both "0".

without rc.local while....pidof... curl can not read metrics )).

log before majestic fall

Aug 29 17:15:35 ssc335de-os02g10 user.debug majestic[654]: Execute: /usr/sbin/motion.sh
Aug 29 17:15:35 ssc335de-os02g10 user.debug majestic[654]: JPEG was sent to client
Aug 29 17:15:45 ssc335de-os02g10 kern.debug kernel: [ven-w][wrap] BSP_FULL 041143a0, 04125000, 10c60
Aug 29 17:15:46 ssc335de-os02g10 kern.notice kernel: client [654] disconnected, module:ao
Aug 29 17:15:46 ssc335de-os02g10 kern.notice kernel: client [654] disconnected, module:ai
Aug 29 17:15:46 ssc335de-os02g10 kern.err kernel: [_MI_AI_IMPL_FreeTmpBuffer:3819] free tmp buffer.
Aug 29 17:15:46 ssc335de-os02g10 kern.notice kernel: client [654] disconnected, module:shadow
Aug 29 17:15:46 ssc335de-os02g10 kern.err kernel: MI_SHADOW_IMPL_DeInit 1829
Aug 29 17:15:46 ssc335de-os02g10 kern.notice kernel: client [654] disconnected, module:divp
Aug 29 17:15:46 ssc335de-os02g10 kern.err kernel: ^[[1;31m[DIP] Virtual IRQ: 36
Aug 29 17:15:46 ssc335de-os02g10 kern.err kernel: ^[[0m
Aug 29 17:15:46 ssc335de-os02g10 kern.err kernel: [CMDQ]Release CMDQ(2) service
Aug 29 17:15:46 ssc335de-os02g10 kern.notice kernel: client [654] disconnected, module:venc
Aug 29 17:15:46 ssc335de-os02g10 kern.err kernel: ^[[1;33m[MI WRN ]: _MI_VENC_StopMiDevice[8218]: CH0 is still running!
Aug 29 17:15:46 ssc335de-os02g10 kern.err kernel: ^[[0m
Aug 29 17:15:46 ssc335de-os02g10 kern.err kernel: ^[[1;33m[MI WRN ]: _MI_VENC_StopMiDevice[8228]: CH0 is still created!
Aug 29 17:15:46 ssc335de-os02g10 kern.err kernel: ^[[0m
Aug 29 17:15:46 ssc335de-os02g10 kern.err kernel: ^[[1;33m[MI WRN ]: _MI_VENC_StopMiDevice[8218]: CH1 is still running!
Aug 29 17:15:46 ssc335de-os02g10 kern.err kernel: ^[[0m
Aug 29 17:15:46 ssc335de-os02g10 kern.err kernel: ^[[1;33m[MI WRN ]: _MI_VENC_StopMiDevice[8228]: CH1 is still created!
Aug 29 17:15:46 ssc335de-os02g10 kern.err kernel: ^[[0m
Aug 29 17:15:46 ssc335de-os02g10 kern.err kernel: ^[[1;33m[MI WRN ]: _MI_VENC_StopMiDevice[8218]: CH2 is still running!
Aug 29 17:15:46 ssc335de-os02g10 kern.err kernel: ^[[0m
Aug 29 17:15:46 ssc335de-os02g10 kern.err kernel: ^[[1;33m[MI WRN ]: _MI_VENC_StopMiDevice[8228]: CH2 is still created!
Aug 29 17:15:46 ssc335de-os02g10 kern.err kernel: ^[[0m
Aug 29 17:15:46 ssc335de-os02g10 kern.notice kernel: client [654] disconnected, module:vpe
Aug 29 17:15:47 ssc335de-os02g10 kern.warn kernel: ^[[1;31m[HALSCL]_HalSclDestoryRealTimeModeOrLastChannel Destroy process fence 59
Aug 29 17:15:47 ssc335de-os02g10 kern.warn kernel: ^[[m
Aug 29 17:15:47 ssc335de-os02g10 kern.err kernel: ===== MhalCameraClose begin, ch = 0, VifMask: 0x3 =====
Aug 29 17:15:47 ssc335de-os02g10 kern.err kernel: ===== MhalCameraClose, 11058 end. =====
Aug 29 17:15:47 ssc335de-os02g10 kern.err kernel: [CMDQ]Release CMDQ(0) service
Aug 29 17:15:47 ssc335de-os02g10 kern.err kernel: CmdqProcDeInit
875
Aug 29 17:15:47 ssc335de-os02g10 kern.err kernel: ReleaseAllBuffer count =0
Aug 29 17:15:47 ssc335de-os02g10 kern.err kernel: [CMDQ]Release CMDQ(1) service
Aug 29 17:15:47 ssc335de-os02g10 kern.notice kernel: client [654] disconnected, module:vif
Aug 29 17:15:47 ssc335de-os02g10 kern.notice kernel: client [654] disconnected, module:sensor
Aug 29 17:15:47 ssc335de-os02g10 kern.err kernel: ^[[1;33m[MI WRN ]: MI_SNR_IMPL_DeInit[925]: snr padid 0, force disable
Aug 29 17:15:47 ssc335de-os02g10 kern.err kernel: ^[[0m
Aug 29 17:15:47 ssc335de-os02g10 kern.notice kernel: client [654] disconnected, module:sys
Aug 29 17:20:00 ssc335de-os02g10 cron.info crond[572]: USER root
pid 1288 cmd sync ; echo 3 > /proc/sys/vm/drop_caches
Aug 29 17:20:00 ssc335de-os02g10 kern.info kernel: sh (1288): drop_caches: 3

[widgetii]

Thank you — that reply told us something important: venc_empty_frames at 0 means the August fix is not what is biting you. So this is a different failure wearing the same face, and we have been guessing at it. Let us stop guessing.

First, one thing I should have asked in August: what exactly does your rc.local check do? If it kills majestic when it finds it unresponsive, then the shutdown at the end of your 29 August log is your own script, not a crash — and that changes what we are looking for. Please paste the script.

Two fixes are on the way

Both address the state you describe — the process is alive, pidof finds it, and there is no video and no web interface — and neither is the August one.

The first is in ipctool, which majestic uses to identify the sensor: OpenIPC/ipctool#185. It leaked one open /dev/i2c-N handle every time majestic reloaded its configuration. Enough reloads and the process runs out of file handles; it then keeps running and stops accepting any connection at all — no stream, no web page, and pidof still finds it. Measured on a lab camera: one handle per reload before, none after.

The second is in majestic, for a rarer version of the same outcome. I will note here when a nightly carries both.

What would settle it

Neither of those is proven to be your five-to-ten minutes, and the only way to know is to look at the camera while it is in the bad state. Three things, cheapest first. Do them while it is stuck — before restarting it:

# 1. how many file handles it is holding, and what they are
ls /proc/$(pidof majestic)/fd | wc -l
ls -l /proc/$(pidof majestic)/fd | awk '{print $NF}' | sort | uniq -c | sort -rn | head

# 2. what every thread is doing
for t in /proc/$(pidof majestic)/task/*; do
  echo "$(basename $t) $(cat $t/comm) $(cat $t/wchan) $(awk '{print $3}' $t/stat)"
done

If (1) is a large number — hundreds or more — with one kind of entry repeated, that is the file-handle problem and the ipctool fix is your answer. If (2) shows every thread in futex and state S, it is a lock-up, and then the third thing is what we need:

kill -ABRT $(pidof majestic)

That is worth doing only with core dumps armed first — Web interface → Majestic debugging, tick the box, and choose either "save locally" or one of the upload options. It normally only fires on a crash; kill -ABRT makes it fire on a freeze too, and the dump contains what every thread was waiting for. That single file would end this.

Two things worth trying in the meantime

Your configuration is a heavy one for this SoC: two H.264 channels plus a 1920×1080 snapshot channel at quality 100. Please try, one at a time, and tell us whether the interval changes:

1. jpeg.qfactor: 75 and jpeg.size: 1280x720
2. ipeye.enabled: false for one run

Neither is a fix. They tell us which half of the camera to look at, which is worth a great deal right now.

---

Спасибо — ваш ответ сказал важное: venc_empty_frames равный 0 означает, что августовское исправление не ваш случай. Это другая неисправность с тем же лицом, и мы её угадываем. Хватит угадывать.

Сначала то, о чём я должен был спросить ещё в августе: что именно делает ваш костыль в rc.local? Если он убивает majestic, когда тот не отвечает, — значит, завершение в конце вашего лога от 29 августа сделал ваш собственный скрипт, а не падение, и искать надо другое. Пришлите, пожалуйста, сам скрипт.

Два исправления в пути

Оба про то состояние, которое вы описываете: процесс жив, pidof его находит, видео нет и веб-интерфейса нет. Августовское — не про это.

Первое — в ipctool, которым majestic определяет сенсор: OpenIPC/ipctool#185. Он терял один открытый дескриптор /dev/i2c-N при каждой перезагрузке конфигурации majestic. Достаточно перезагрузок — и процессу перестаёт хватать дескрипторов; он продолжает работать и перестаёт принимать вообще любые соединения — ни потока, ни веб-страницы, а pidof его находит. Измерено на лабораторной камере: один дескриптор на перезагрузку до, ноль после.

Второе — в majestic, для более редкого варианта того же исхода. Отпишусь здесь, когда ночная сборка будет содержать оба.

Что расставит всё по местам

Ни одно из них не доказано как ваша причина пяти-десяти минут, и узнать это можно только заглянув в камеру, пока она в плохом состоянии. Три вещи, от самой дешёвой. Делать пока она висит, до перезапуска:

# 1. сколько дескрипторов держит и какие
ls /proc/$(pidof majestic)/fd | wc -l
ls -l /proc/$(pidof majestic)/fd | awk '{print $NF}' | sort | uniq -c | sort -rn | head

# 2. чем занят каждый поток
for t in /proc/$(pidof majestic)/task/*; do
  echo "$(basename $t) $(cat $t/comm) $(cat $t/wchan) $(awk '{print $3}' $t/stat)"
done

Если в (1) большое число — сотни и больше — с одной повторяющейся записью, это проблема дескрипторов, и исправление в ipctool — ваш ответ. Если в (2) все потоки в futex и состоянии S — это взаимная блокировка, и тогда нужно третье:

kill -ABRT $(pidof majestic)

Делать это имеет смысл, только предварительно включив дампы: веб-интерфейс → Majestic debugging, поставить галочку и выбрать «сохранять локально» либо один из вариантов отправки. Обычно дамп снимается только при падении; kill -ABRT снимает его и при зависании, и в нём видно, чего ждал каждый поток. Одного такого файла хватит, чтобы закрыть вопрос.

Что стоит попробовать пока

Ваша конфигурация тяжёлая для этого SoC: два канала H.264 плюс снимок 1920×1080 с качеством 100. Попробуйте, по одному изменению за раз, и скажите, меняется ли интервал:

1. jpeg.qfactor: 75 и jpeg.size: 1280x720
2. ipeye.enabled: false на один прогон

Ни то, ни другое не исправление. Они говорят, в какой половине камеры искать, а это сейчас стоит многого.

[widgetii]

Update: both fixes have landed in majestic master, and the first one is now confirmed on your SoC family rather than only on a nearby one.

I found an ssc337 (infinity6b0, same family as your ssc335de) and ran it with your configuration — two H.264 channels, a 1920×1080 snapshot channel at quality 100, audio and motion detection on — under two continuous RTSP viewers, three more connecting and disconnecting, and a snapshot every two seconds. Then eight configuration reloads, on the old build and the new one:

build	/dev/i2c-1 handles held	after 8 reloads	total handles
master+c611981 (before)	1	9	43 → 52
master+d0d1888c (after)	0	0	43 → 42

One leaked handle per reload, and none after. Both builds still identify the sensor on every reload, so nothing was traded away for it.

Two other things that board told us, and both are worth your attention:

It did not fail. Seven minutes under that load with memory, handles and the multimedia heap all flat, and no five-to-ten-minute failure. So whatever is specific to your camera is not the configuration alone, and not the SoC alone.

No BSP_FULL at all. Your dmesg is flooded with [ven-w][wrap] BSP_FULL; that board produced not one in the whole run, on the same configuration and the same SoC family. That makes it something about your sensor, scene or board rather than a general fault — but it is also why your kernel log is useless as evidence: the flood is fast enough that an out-of-memory kill or any other kernel message scrolls out of the buffer long before you read it. Which is why the measurements in my previous comment are the ones that will settle this, and they still need taking while the camera is stuck, before you restart it.

The nightly firmware images will carry both fixes once a new majestic build is published; I will note it here when that has happened.

---

Обновление: оба исправления в master majestic, и первое теперь подтверждено на вашей серии SoC, а не только на соседней.

Нашлась камера ssc337 (infinity6b0, то же семейство, что и ваш ssc335de). Запустил её с вашей конфигурацией — два канала H.264, снимок 1920×1080 с качеством 100, звук и детектор движения включены — под двумя постоянными зрителями RTSP, ещё тремя подключающимися и отключающимися, и снимком каждые две секунды. Затем восемь перезагрузок конфигурации, на старой сборке и на новой:

сборка	дескрипторов /dev/i2c-1	после 8 перезагрузок	всего дескрипторов
master+c611981 (до)	1	9	43 → 52
master+d0d1888c (после)	0	0	43 → 42

Один потерянный дескриптор на перезагрузку — и ни одного после. Обе сборки по-прежнему определяют сенсор при каждой перезагрузке, так что ничем ради этого не пожертвовали.

Ещё два наблюдения с той камеры, оба стоят вашего внимания:

Она не упала. Семь минут под этой нагрузкой: память, дескрипторы и мультимедийная куча — ровные, никакого отказа за пять-десять минут. Значит, специфика вашей камеры — не в одной конфигурации и не в одном SoC.

Ни одного BSP_FULL. Ваш dmesg забит строками [ven-w][wrap] BSP_FULL; та камера не выдала ни одной за весь прогон, на той же конфигурации и том же семействе SoC. Похоже, дело в вашем сенсоре, сцене или плате, а не в общей неисправности — но именно поэтому ваш кернел-лог бесполезен как улика: поток строк идёт так быстро, что сообщение об OOM-убийстве или любое другое успевает уйти из буфера задолго до того, как вы туда заглянете. Поэтому вопрос закроют измерения из моего предыдущего комментария, и снимать их надо пока камера висит, до перезапуска.

Ночные сборки прошивки получат оба исправления после публикации новой сборки majestic; отпишусь здесь, когда это произойдёт.