Advanced Troubleshooting Help: Sony BRAVIA XR-83A90J (83-inch OLED, 2021) - Intermittent Red Light (8 blinks)
What I'm hoping for from anyone who's worked on the VH2 chassis:
- What does Sony call the panel-management / sub-MCU board in the service manual? The kernel driver names it "BE / Backend Control"; I'm trying to map that to the actual board designation for parts ordering (G board? PA board? part of the main?).
- Have you seen this signature (display works, backend-control SPI hung, intermittent 8-blink, dead wired ethernet alongside it) actually resolved by replacing the T-Con, the panel-management board, or only by a panel swap? Want to triage cheapest-likely first before authorizing.
- Anyone know the IR sequence to enter service mode on a VH2 / A90J so I can read the actual blink-code error history? Sony's com.sony.dtv.system.crashlog@1.0 service has the data; it lives in /data/vendor/sony/... which non-root ADB can't touch on a user build, so service mode looks like the only path.
- Encompass shows parts here: https://sony.encompass.com/model/SONXR83A90J - if you've ordered the BE-side board for an A90J, what part number was it?
Happy to share the raw bugreport, dropbox, thread dumps, and Scalar API dump with anyone who wants to verify, I have about 30 MB of captures archived. Sony support has been unhelpful which is why I'm here. Thanks.
My Diagnosis so far:
83 inch Sony Bravia XR-83A90J, 2021 OLED, out of warranty. Symptom is the classic 8-blink red standby LED protection code, intermittent. The TV powers on and can display picture for hours or for about 20 seconds before it shuts off and 8-blinks again. The pattern is asynchronous, not tied to time-on or specific content. Separately, the wired ethernet port is dead on two known-good cables on two different switches; wifi works perfectly. Audio is unaffected (eARC passthrough to a Denon AVR-X3700H) and HDMI-CEC negotiates normally with the AVR, a PS5, and an NVIDIA Shield. Topology is Shield to Denon to TV HDMI3, so the TV is purely a display in this chain.
I was able to enable network ADB on the set and pull a full Android bugreport plus thread dumps, dropbox, dumpsys, etc. The Android side is healthy in every measurable way. Scalar REST API returns full system, network, picture-quality, and sound state. UI navigates fine when there's picture. No kernel panics, no tombstones, no native crashes anywhere in dropbox or pstore. Boot reason is plain reboot. pstore/ramoops empty, no SYSTEM_LAST_KMSG. The OS is not crashing.
Hypothesis-killer for any software cause: during one of the outages, Sony pushed an OTA that upgraded the TV from Android 10 (QTG3, fw 5.5.0) to Android 12 (build STT2.230505.001.S100, fw 5.7.0, Nov 2025 security patch). Post-upgrade the fault is identical in every measurable way. A major Android version bump fixing zero symptoms eliminates the remaining software hypothesis. Sony's own OTA infrastructure tested it for me.
The actual fault signature, which is why I think I'm in the right place to ask: load average pegged at around 39 while the CPU is otherwise about 80 percent idle. That's not CPU load, it's roughly 38 kernel threads stuck in uninterruptible D-state, and the named set is the giveaway:
[SonyBECtrlSpi] D <- SPI bus thread to the "Backend Control" subsystem
[SonyBECtrlError] D <- backend error-handler thread - itself wedged
[SelfDiagHandle] D <- the self-diagnostic thread that drives the blink code
[MLVdo_thread] D <- main video pipeline
[SonySOPQCtrlVdo] D <- Sony picture-quality (SOPQ) control
[SonySOPQCtrlUpd] D
[SonySOPQCtrlSys] D
[FRC Unmute] D <- frame-rate conversion (MEMC)
[NR main loop] D
[DI Film Adaptiv] D
[AudHDMIParser1/2/3] D
[Hdcp22Thread1/2] D
[VsyncThread] D <- graphics composer vsync
Thermal HAL never initializes (HAL Ready false), zero /sys/class/thermal/thermal_zone* entries. On the A90J the temp sensors are read over the same backend bus that's hung, so the absence of temp readings is itself consistent with the diagnosis rather than a separate issue. Also aud_cpupost is pegged at about 25 percent sustained CPU continuously, which is absurd given the TV is purely a display in this topology, and reads as collateral from the audio offload path coordinating through the dead backend.
My read is that the SoC issues control transactions to the panel-management sub-MCU board over its SPI bus and they never complete. RT driver threads block forever in D, SelfDiagHandle can't run cleanly, and the MICOM falls back to the physical 8-blink protection code when whatever threshold (panel power sequencing, ABL, thermal proxy on the dead sensor path) gets crossed. The primary video timing path to the panel clearly still works, since we get picture when it's up, so this isn't the T-Con video timing dying outright; it's the control/management side of the panel hardware. The dead ethernet on the same chassis is probably a related mainboard / interconnect issue but I haven't proven that.
