[tg5040] Spontaneous reboot: kernel panic in sunxi_i2c_handler after i2c3 timeout polling the analog joystick (0x29)

[hiepnm93]

Device

• NextUI 20260719-0 (73e160c, 2026-07-20), kernel 4.9.191 #912, sun50iw10 (H700), Tools arch folder tg5040
• Device shows as "TRIMUI Player1" joystick (js0/event3)

Symptom

The console spontaneously reboots every few hours of uptime, regardless of what is running (it happened while idle in the menu and while in-game). /sys/fs/pstore records Panic: Total 3 times over one session, at ~35min, ~75min and ~3h11m of uptime. Battery was fine (~78%).

Evidence (pstore, identical every time)

sunxi_i2c_do_xfer()1916 - [i2c3] xfer timeout (dev addr:0x29)
Unable to handle kernel NULL pointer dereference at virtual address 00000014
Internal error: Oops: 96000006 [#1] PREEMPT SMP
PC is at sunxi_i2c_handler+0x4dc/0x924
LR is at sunxi_i2c_handler+0x418/0x924
...
Kernel panic - not syncing: Fatal exception in interrupt
SMP: failed to stop secondary CPUs 0-1

Fault happens in interrupt context (el1_irq → gic_handle_irq → sunxi_i2c_handler), which is why it takes the whole kernel down.

What device 0x29 on i2c3 is

I probed the buses from userspace (/dev/i2c-*):

• i2c-6: 0x34 (AXP2202 PMIC) + 0x41 (used by poweroff_next)
• i2c-0, i2c-2: nothing
• i2c-3: only 0x29 answers — sequential read returns 07 e1 07 f8 f8 f8 ...

There is no DT child on twi@0x05002c00; the kernel polls 0x29 continuously and the value pattern matches the analog stick reader behind the "TRIMUI Player1" js0 device. So the flow is: joystick poll over i2c3 → chip occasionally misses a transfer (xfer timeout) → sunxi_i2c_handler dereferences a null pointer in the timeout/IRQ path → fatal panic in interrupt → reboot.

Suggestion

The i2c3/0x29 timeout itself is transient (the stick keeps working after reboot), so the fatal part is purely the driver's timeout path in sunxi_i2c_handler: it should bail out of the IRQ (complete the transfer with -ETIMEDOUT, re-arm the controller) instead of touching the timed-out transfer state and oopsing. Happy to test a build if useful.

Environment notes

• Modules loaded at panic: xradio_wlan xradio_core ... vin_v4l2 ov5648_mipi vin_io videobuf2 ... dc_sunxi(O) pvrsrvkm(O)
• Nothing unusual running; reproducible across several days of normal use

[hiepnm93]

Update - strong WiFi correlation in my pstore records (matches a community report that turning Wi-Fi off stopped these reboots):

• panic test #1: [2111.83] [AP_WRN] [STA] ASSOC + xradio_bss_info_changed, then [2111.896] i2c3 xfer timeout (60 ms later)
• panic pull latest changes #2: the oops stack itself is the WiFi workqueue (ieee80211_rx_mgmt_beacon -> mac80211_sta_rx_queued_mgmt -> ieee80211_iface_work -> xradio_bss_info_changed) racing the i2c3 timeout at the same jiffy
• panic Other device support? #3: [11456.79-.99] ASSOC/bss_info_changed burst, [11457.061] i2c3 timeout

All records also show [TXRX_WRN] status=6, retry=14 beforehand (spotty AP here). So the stick poll over i2c3 gets starved/delayed while xradio processes beacons/assoc, the transfer times out, and sunxi_i2c_handler oopses. Userspace workaround in the field: switch Wi-Fi off. Locally I also halved trimui_inputd's poll rate (bytepatch) to cut exposure. The IRQ-context NULL deref in sunxi_i2c_handler remains the part that should be fixed kernel-side.

[frysee]

I think I have a fix lined up for this already, but we'll merge h700 first.

[pvaibhav]

H700 review fixes ETA is this week.