Hi Seeed team,
We’re running a kiosk-style measurement application on both a standard reTerminal and a reTerminal DM, and have two separate issues we’d like guidance on.
**Issue 1 — reTerminal DM screen freeze (vc4_dsi timeout)**
On our reTerminal DM, the screen occasionally freezes and stops responding to touch. This happened even during plain OS desktop usage (lightdm still enabled, no custom app running) — we captured it while the stock first-boot “SSH enabled / default password not changed” dialog was on screen. So we believe this is unrelated to our application and is a driver/OS-level issue.
Kernel log at the time of freeze:
```
vc4_dsi fe700000.dsi: transfer interrupt wait timeout
vc4_dsi fe700000.dsi: instat: 0x00000000
[drm:vc4_dsi_host_transfer [vc4]] *ERROR* DSI transfer failed, resetting: -110
```
We noticed our standard reTerminal uses Seeed’s own out-of-tree `mipi_dsi` kernel module, which talks to the panel through an STM32 microcontroller (`mipi_dsi: (i2c_md_probe) STM32 firmware version 1.9`). The reTerminal DM doesn’t seem to have this STM32 intermediary — the stock `vc4_dsi` DRM driver appears to drive the panel directly. We suspect this architectural difference is why the standard reTerminal doesn’t show this problem.
The system itself stays alive (SSH still responds), only the display hangs. So far the only reliable recovery we’ve found is a physical power cycle — we haven’t yet verified whether something like `xset dpms force off` / `force on` over SSH would recover it.
Questions:
1. Is this a known issue on reTerminal DM? Any existing reports/threads we should be aware of?
2. Is there a remote-recoverable method (without physical power cycle)?
3. Any recommended kernel/`config.txt`/firmware settings to avoid or reduce this?
4. Could this be unit-specific, or is it a known issue across this model?
Environment: reTerminal DM, Debian 11 Bullseye, Python 3.9.2, X11 (Xorg via `xinit`), PySide6 6.8.0.2.
-–
**Issue 2 — Is software rendering the “correct” fix for the v3d MMU hang on standard reTerminal?**
On our standard reTerminal, running a PySide2/Qt5 app continuously for ~3 days used to cause the screen to go black (touch unresponsive, but SSH/ping still alive), with this in the kernel log:
```
v3d fec00000.v3d: MMU error from client L2T (0) at 0xXXXXXXX, pte invalid
```
We worked around it by forcing CPU-based (software) rendering:
```
QT_QUICK_BACKEND=software
QT_XCB_GL_INTEGRATION=none
LIBGL_ALWAYS_SOFTWARE=1
PYOPENGL_PLATFORM=egl
```
This has been stable for 3+ days of continuous runtime with zero v3d errors since applying it.
Questions:
1. Is disabling GPU rendering the recommended way to work around this v3d MMU error, or is there a better-supported fix (kernel/firmware update, different overlay, etc.)?
2. Any known downsides to running fully software-rendered long-term on this hardware, beyond the obvious rendering performance hit?
3. Is there a timeline for a proper fix at the driver/firmware level?
Environment: reTerminal (standard), Debian 13 Trixie, kernel 6.1.21-v8+, X11, PySide6 6.8.0.2.
-–
Happy to share more logs (`dmesg`, `journalctl -k`) if useful. Thanks in advance!