filesystem hangs with kernel: Internal error: Oops: 96000004 [#1] PREEMPT SMP during copy operation #271
Comments
|
This error has finally just now occurred on ext4... So I guess it's not exclusive to btrfs. Googling it now, without looking for just btrfs hits, it seems to be widespread across rock64 boards. Maybe even a hardware issue? I haven't finished researching. |
Kwiboo
pushed a commit
to Kwiboo/linux-rockchip
that referenced
this issue
Oct 23, 2023
Add a new test case to query on an empty bpf_mprog and pass the revision directly into expected_revision for attachment to assert that this does succeed. ./test_progs -t tc_opts [ 1.406778] tsc: Refined TSC clocksource calibration: 3407.990 MHz [ 1.408863] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x311fcaf6eb0, max_idle_ns: 440795321766 ns [ 1.412419] clocksource: Switched to clocksource tsc [ 1.428671] bpf_testmod: loading out-of-tree module taints kernel. [ 1.430260] bpf_testmod: module verification failed: signature and/or required key missing - tainting kernel rockchip-linux#252 tc_opts_after:OK rockchip-linux#253 tc_opts_append:OK rockchip-linux#254 tc_opts_basic:OK rockchip-linux#255 tc_opts_before:OK rockchip-linux#256 tc_opts_chain_classic:OK rockchip-linux#257 tc_opts_chain_mixed:OK rockchip-linux#258 tc_opts_delete_empty:OK rockchip-linux#259 tc_opts_demixed:OK rockchip-linux#260 tc_opts_detach:OK rockchip-linux#261 tc_opts_detach_after:OK rockchip-linux#262 tc_opts_detach_before:OK rockchip-linux#263 tc_opts_dev_cleanup:OK rockchip-linux#264 tc_opts_invalid:OK rockchip-linux#265 tc_opts_max:OK rockchip-linux#266 tc_opts_mixed:OK rockchip-linux#267 tc_opts_prepend:OK rockchip-linux#268 tc_opts_query:OK rockchip-linux#269 tc_opts_query_attach:OK <--- (new test) rockchip-linux#270 tc_opts_replace:OK rockchip-linux#271 tc_opts_revision:OK Summary: 20/0 PASSED, 0 SKIPPED, 0 FAILED Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/r/20231006220655.1653-6-daniel@iogearbox.net Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>
|
Hit this problem on oDroid C2, Armbian Bookwork (happened on bullseye also). Got a mix of disks and filesystems attached, with things running on top.
Samba, NFS and GlusterFS. I saw the hang before I installed GlusterFS, so I don't believe that is involved, but the rest was present. The hints I got from a terminal that was open before the hand happened: Point being, this does not seem to be isolated to just one platform/OS |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
On Armbian Buster, Rock64 (RK3328). This was also happening on the latest backported version of 5.10, I think 5.10.72? I tried upgrading to fix it to no avail.
I have a couple 8TB HDDs that I use as backups. All I did was reformat one of them as btrfs and start copying the data back over from the other (still EXT4). I tried rsync and simple cp. Without fail, a few minutes into the operation, the copy operation will hang indefinitely, and all open terminals receive these kernel messages:
After that, every subsequent copy operation from the EXT4 drive to this new btrfs partition will hang until I reboot the rock64.
However, the drive otherwise continues to work fine. fsck and btrfs scrub find no problems. The super weird thing is I can still write files, and copy a small shell script from the home folder, all just fine--but copying from the other 8TB drive will immediately hang. I have had zero issues with either drive until trying btrfs now. I'm able to rsync between them just fine when they're both EXT4.
journalctl.txt
specific-error.txt
The text was updated successfully, but these errors were encountered: