Vero V crashes during playback - WIFI connected

Help and Support Vero V
41

So yesterday I was watching “No Other Choice”, which I ripped as an mkv from a 4K UHD blu-ray, and the Vero V fully crashed multiple times (at least 6 times) - this was with just playing the movie (no seeking), where I had to power cycle to resume. Unfortunately, can’t get it wired there while keeping the wife happy. Is the newest staging build built upon the May build?

42

I have had a couple of crashes as well, but, the Vero did not restart, it was just a frozen picture and audio lopping.
Switched to ethernet.

43

If I can get logs via latest staging via My OSMC and not a random tarball I should be able to see the issue

Unfortunately until anyone does that I have no clue

Sam

44

Nothing random about the tarballs I uploaded. They contain all the files that were in the pstore folder after the crashes, which I thought is what you were looking for. Did you have some issue with them?

1 Like
45

And may I a call your attention to this thread I started back in November of 2023 - Vero V hangs playing UHD rips. Lots of logs were posted there, plus we exchanged many emails on this subject. As well as replacing my Vero V in case it was a hardware failure in my specific unit.

After 2 1/2 years of no fix it seems that this is a hardware design flaw in the Vero V. It should be sold with a disclaimer noting this shortcoming.

Chris

1 Like
46

Okay, I’m lucky with reproducing it - I’ve got it locking up completely twice by itself, and a third by seeking extensively and captured the logs:

I did have to upload the logs after restart, as the system hangs completely, and power cycling is the only option. I hope that the logs of the previous session are in there.

With my limited level of understanding, I can’t see anything out of the ordinary in these logs, but hopefully somebody can. If not, what other level of debugging can we do?

1 Like
47

This is what AI suggest when it analyzes the dmesg log from one of the crashes, A problem with the Realtek 8822cs WiFi driver.
I do not have a clue if it is wrong or right, i just want the problem fixed. Hope it helps

We need to analyze the provided dmesg log. The log shows two sections: “dmesg-ramoops-1:” and “dmesg-ramoops-0:”. They appear to be two separate panic logs, possibly from two crashes. The content includes many kernel messages, and ends with an Oops: “Unable to handle kernel NULL pointer dereference at virtual address 00000000” in both sections (the end of each is the same). The Oops occurs in dev_gro_receive, and the call stack involves the 8822cs WiFi driver (Realtek). The log also shows many “DOLBY ERROR” messages, and some HDMI/audio init messages.

We need to analyze the dmesg log to determine the cause of the crash. Let’s extract key information.

First, note the timestamps: The log starts at around 112 seconds, then many events, then the Oops at 1855.002059 seconds. There is also a second panic at the same time? Actually both files end with same Oops, so likely they are two ramoops dumps from the same crash? Or two separate crashes? The first file ends with a similar Oops. Both have the same Oops at 1855.002059. So it appears that the system crashed due to a NULL pointer dereference in dev_gro_receive while processing network packets, called from the WiFi driver’s napi_recv.

Let’s examine the Oops details:

  • PC is at dev_gro_receive+0x2b8/0x3b4.

  • LR is at dev_gro_receive+0x298/0x3b4.

  • The faulting address is 0x0.

  • The call trace shows:
    dev_gro_receive → napi_gro_receive → _rtw_napi_gro_receive (from 8822cs) → napi_recv → rtw_recv_napi_poll → net_rx_action → __do_softirq

So it’s a kernel bug where a NULL pointer is dereferenced in dev_gro_receive. This is likely due to a network packet being processed that has a NULL skb->dev or something similar, or maybe the netdev structure is corrupted. The driver 8822cs is the Realtek WiFi driver.

Additionally, there are many “DOLBY ERROR” messages earlier, indicating issues with Dolby Vision metadata parsing. But that seems unrelated to the crash, though it might be a symptom of other problems.

We also see that the system was playing a video (3840x2160p24hz, with DTS-HD MA audio, etc.) and the WiFi was active (scanning, etc.). The crash occurred in a softirq context (ksoftirqd/0), which handles network interrupts.

So the likely cause is a bug in the WiFi driver (8822cs) that leads to a NULL pointer being passed to dev_gro_receive. Possibly a memory corruption or uninitialized pointer.

We should provide analysis: root cause is NULL pointer dereference in dev_gro_receive, triggered by the WiFi driver’s napi_recv. The driver likely passes a skb with NULL dev or something similar. We might suggest updating the WiFi driver or checking for known issues with that driver on this kernel (4.9.269).

Also note the kernel version: 4.9.269-90-osmc, and hardware is VeroV (Amlogic based). The crash happened while playing media and WiFi was active.

Now we need to produce a concise analysis for the user.

The provided dmesg logs show a kernel panic caused by a NULL pointer dereference in the network stack. Below is a summary of the key findings and the likely root cause.

Summary of the Crash

  • Crash Type: Kernel Oops – NULL pointer dereference

  • Faulting Instruction: dev_gro_receive+0x2b8/0x3b4

  • Faulting Address: 0x00000000

  • Process: ksoftirqd/0 (PID 6) – softirq handler running in kernel context

  • Kernel Version: 4.9.269-90-osmc

  • Hardware: VeroV (Amlogic SoC)

  • Crash Time: ~1855 seconds after boot (approximately 30 minutes)

Crash Stack Trace (simplified)

text

dev_gro_receive+0x2b8/0x3b4
  napi_gro_receive+0x78/0x14c
    _rtw_napi_gro_receive+0xc/0x14 [8822cs]
      napi_recv+0xe4/0x100 [8822cs]
        rtw_recv_napi_poll+0x34/0xa0 [8822cs]
          net_rx_action+0x13c/0x35c
            __do_softirq+0x23c/0x398

The crash occurred in the generic networking layer while processing a received packet. The call chain originates from the Realtek 8822cs WiFi driver (8822cs.ko).

Likely Root Cause

The NULL pointer dereference happens inside dev_gro_receive, which expects a valid struct net_device pointer from the skb->dev field. The most plausible scenario is that the WiFi driver (8822cs) passed a socket buffer (skb) with a NULL or corrupted dev pointer to the network stack.

Possible reasons:

  1. Driver bug – The driver does not properly initialize the skb->dev field before passing the packet up.

  2. Memory corruption – A previous bug (e.g., buffer overflow) corrupted the skb metadata.

  3. Concurrency issue – The driver may have freed the net_device while packets were still in the receive queue.

Given the stack trace points directly to the WiFi driver’s receive path (napi_recv), the issue is almost certainly in the 8822cs driver or its interaction with the networking core.

Additional Observations

  • The logs contain many Dolby Vision metadata parser errors (DOLBY ERROR: meta(226), pts64(...) -> parser process fail). While these are likely unrelated to the crash, they indicate possible issues with media playback (e.g., corrupted streams or bugs in the Dolby Vision handler).

  • The system was actively playing a 4K video with DTS-HD MA audio and the WiFi was scanning/associating before the crash.

  • Several NOHZ: local_softirq_pending warnings appear earlier, suggesting some softirq latency, but these are not directly causative.

Recommended Actions

  1. Update or replace the WiFi driver – The 8822cs module is the primary suspect. Look for an updated version from the manufacturer or consider using a different driver if available.

  2. Check for known issues – Search for “8822cs NULL pointer dev_gro_receive” or similar. This may be a known bug in the Realtek driver.

  3. Reproduce the crash – If possible, try to reproduce the crash without WiFi activity (disable WiFi) to confirm it’s network‑related.

  4. Enable debugging – Compile the kernel with CONFIG_DEBUG_NET and CONFIG_DEBUG_SKB to catch such errors earlier.

  5. Review memory usage – Ensure no other kernel module is corrupting memory (e.g., the media playback stack). The Dolby Vision errors might hint at memory corruption, but they are less likely to affect the WiFi path.

Conclusion

The kernel panic is a NULL pointer dereference in dev_gro_receive, triggered by a bad skb passed from the Realtek 8822cs WiFi driver. The solution involves fixing or updating the WiFi driver, or disabling it if the issue is not needed.

1 Like
48

Thanks @thansen_dk - a bug in the WiFi driver seems like a plausible root cause for this crashing issue. Hopefully, a driver update can solve the issue.

That said. I’ve also thrown Claude on my logs, and it puts up another angle:

The AMLogic hardware codec is involved in every crash.

In cedelecoha, vixinimiqi and uquyozejey the last visible activity is the AMLogic hardware decoder being reset or fed:

  • AMLInsecureVideoCodec::reset

  • AMLInsecureVideoCodec::setVideoRect

  • AMLInsecureVideoCodec::SetSpeed

  • CDVDAudio::Flush / CDVDAudio::Pause

vixinimiqi shows the failure occurs while seeking in the stream — repeated SeekTime → FlushBuffers → AMLInsecureVideoCodec::reset cycles, then log truncates. cedelecoha shows the same: PageUp pressed → SeekChapter:6 → FlushBuffers → AMLInsecureVideoCodec::reset → truncation.

The boot-time kernel log already shows complaints from the same subsystem:

  • ERROR: could not get clock /amhdmitx:hdmi_vpu_clk(4)

  • get gate clk_hevc_mux control failed (null)

These appear at every boot in every log file — the HEVC clock gate and HDMI VPU clock cannot be acquired by the driver. That is the same hardware block driving AMLInsecureVideoCodec.

Alternative root-cause hypothesis

The Realtek Wi-Fi theory does not match the evidence. The actual common pattern across all dumps is:

  • Kodi is playing No Other Choice (2025).mkv from a Jellyfin server over the local network.

  • Playback is going through AMLInsecureVideoCodec, the AMLogic hardware decoder (HEVC clock gate cannot be controlled per boot).

  • During playback — particularly while seeking — the codec/VPU stack hangs, taking the system down with it.

  • Wi-Fi traffic happens to be the visible activity in journals because the stream is being delivered over wlan0; that is correlation, not causation.

Not sure if this is misdirection or noise (especially as people report not experiencing this issue when cabled), but there may be multiple things going wrong (i.e. WiFi driver issues causing the AMLInsecureVideoCodec::reset).

1 Like
49

Maybe there are multiple issues, but the fact is that it only happens when connected to WiFi, at least in my case.

1 Like
50

Issue is only with WiFi. I bought a 100’ cable to stretch between rooms for testing and ethernet had no such issues. The older Vero 4+ also had none of these WiFi issues, it could play these UHD files all day without crashing or freezing.

2 Likes
51

I agree 100%.

I have made the same tests with my vero 4+ and ethernet to the Vero V, no problem at all.

1 Like
54

Thanks for providing the logs via My OSMC. This is the way we expect to receive logs.

I’m investigating this and will give you an update shortly.

I don’t have any reason to believe it is a hardware defect. It is unfortunately a problem that we’ve had issues reproducing here. If we could reproduce it here, we would’ve fixed it promptly. I have tried to buy equipment and even offer customers to send their equipment for us to test at our cost.

I made some changes to enable persistent logging so we can get a better understanding and I think this should yield a solution.

Thanks for your understanding

Sam

55

This is completely irrelevant to the issue at hand, but I appreciate the enthusiasm.

Sam

58

I’ve taken a stab at this. There are two ways to fix this. I’d prefer to take the first fix, but I cannot guarantee its efficacy as I can’t reproduce the issue here.

Please try this approach first:

wget "https://collab.osmc.tv/index.php/s/MyBXQfooYgHPpNR/download/vero564-image-4.9.269-95-osmc.deb" -O kernel.deb
sudo dpkg -i kernel.deb
reboot

If things don’t pan out, let me know, and I’ll suggest the second approach. Logs would be useful if there is still an issue.

Many thanks

Sam

59

Did not work, froze.

60

Can you provide a log please? Then I can check if you updated properly and also see the issue

Sam

62

Not quite sure I understand the pastebin site. If copying the url after a save of the text is what you need then see: https://paste.osmc.tv/ojejotofal.vbs.
The journal is the only viable information as the unit completely froze, nothing new in pstore or kodi logs. Started playback approx. 10:17, around 11:05 is when I noticed the video was frozen. Didn’t reboot until 12:20.
Chris

63

Here’s the dmesg after I rebooted: https://paste.osmc.tv/fuhuqevudo.vbs.

64

Is it so difficult to just type grab-logs -A instead of giving Sam half the story?

1 Like
65

Doesn’t seem difficult, I just didn’t remember. Been a couple of years since I was heavily troubleshooting this issue.
For what it’s worth, in case after a sceond reboot there’s anything of use in grab-logs it’s at: https://paste.osmc.tv/givapukavo.

1 Like