Date: Wed, 10 Apr 2024 08:58:24 +0000 From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 270089] mpr: panic in mpr_complete_command during zpool import Message-ID: <bug-270089-3630-JCDWrpg0TF@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-270089-3630@https.bugs.freebsd.org/bugzilla/> References: <bug-270089-3630@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D270089 --- Comment #20 from Dan Kotowski <dan.kotowski@a9development.com> --- > Since this is on an ARM server, there may be something subtle there due t= o arm's weaker memory model than amd64 that's causing this. I don't know if it's related or not, but PCIe GPUs under Linux DRM can experience weird artifacting and tearing as a result of some sort of memory issue. The fix from the firmware developer was to reorder operations in gli= bc memcpy. > Subject: [PATCH] Aarch64: Make memcpy more compatible with device memory >=20 > For normal non-cacheable memory ACE supports 4x128 bit r/w WRAP > transfers or 1x128 bit r/w INCR transfers. By re-ordering the > stp's in memcpy / memmove we can accomodate this better without > impacting the existing code. >=20 > This fixes an issue seen on multiple Cortex-A72 SOCs when writing > directly to a PCIe memmapped frame-buffer, which resulted in > corruption. https://gist.github.com/jnettlet/f6f8b49bb7c731255c46f541f875f436 Test for framebuffer memcpy bugs: https://gist.github.com/jnettlet/80f8d09d01c0dc0ffc0122f36ed78de6 Unfortunately I lack the knowledge to know how to build a test util for FreeBSD, but I do wonder if the coherency issue on the bus is impacting my = case as well? Another user in the vendor's Discord channel recently stated that they've b= een experiencing issues with using 2x NVMe drives off of a SuperMicro bifurcated PCIe-to-NVMe adapter. And I've since been able to replicate the issues usin= g a Linux mdadm mirror as well. I have not seen panics when testing single drives, only when using pools of= 2 or more. Perhaps it only presents when there are multiple commands issued in paralle= l? > is this a zpool import from a pool that was created on another system? I have been able to reproduce with zpools from known-working systems and tr= ying to create new ones as well. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-270089-3630-JCDWrpg0TF>