Re: Orange PI 5 MAX: very unstable using kernel 6.19.0 and 6.18.10, 6.18.9 perfectly stable

[Qu Wenruo <wqu@suse.com>]

在 2026/2/13 06:41, David Arendt 写道:
> Hello,
> 
> I am using a Kubernetes Cluster with 3 Orange PI5 MAX nodes. The data is 
> stored using a btrfs filesystem as backend. If using kernel 6.19.0 or 
> kernel 6.18.10 I have experienced many crashes during high IO load on 
> all 3 nodes. Reverting back to 6.18.9 solves the problems completely. 
> Unfortunately the crashes are spontaneous reboots without leaving a 
> trace in any logfile, so I have no stacktrace of them. After the crashes 
> I have sometimes incorrect btrfs csums for a file but these may also be 
> a result of a partial write due to the crash. On one node I had a btrfs 
> error logged without crashing, but I am not sure if this is the root 
> cause or a result of a prior crash. A scrub after reboot returned no 
> error with 6.19.0.

The offending tree dump items are:

Feb 10 13:31:07 opi02 kernel:  item 92 key (13218356101120
Feb 10 13:31:07 opi02 kernel:  item 93 key (13216208642048
Feb 10 13:31:07 opi02 kernel:  item 94 key (13218356162560

Obviously item 93 is smaller than all its previous and next item keys.

hex(13218356101120) = 0xc05a36b8000
hex(13216208642048) = 0xc05236be000
hex(13218356162560) = 0xc05a36c7000

It looks like something fliped, "0xc05a3" -> "0xc0523"

0xa -> 0x2 is exactly one bit flipped.

So either the memory hardware has something wrong and resulting a 
sticking bit (always 0), or there is something inside the kernel 
touching memory it shouldn't.

And this exactly matches the symptom, changing random bit of your 
kernel, crash always expected.


Can you run a memtest to make sure it is not hardware problems first?

Thanks,
Qu


> 
> Unfortunately I don't have more information at the moment.
> 
> Thanks in advance,
> 
> David Arendt
> 
>