Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752195AbbEGNAG (ORCPT ); Thu, 7 May 2015 09:00:06 -0400 Received: from down.free-electrons.com ([37.187.137.238]:56530 "EHLO mail.free-electrons.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751894AbbEGNAE (ORCPT ); Thu, 7 May 2015 09:00:04 -0400 Date: Thu, 7 May 2015 14:57:02 +0200 From: Maxime Ripard To: Neil Brown , Shaohua Li Cc: linux-raid@vger.kernel.org, linux-kernel@vger.kernel.org, Lior Amsalem , Thomas Petazzoni , Gregory Clement , Boris Brezillon Subject: Possible RAID6 regression with ASYNC_TX_DMA enabled in 4.1 Message-ID: <20150507125702.GI11057@lukather> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="UthUFkbMtH2ceUK2" Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2626 Lines: 73 --UthUFkbMtH2ceUK2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, I'm currently trying to add support for the PQ operations on the marvell XOR engine, in dmaengine, obviously to be able to use async_tx to offload these operations. I'm testing these patches with a RAID6 array with 4 disks. However, since the commit 59fc630b8b5f ("RAID5: batch adjacent full stripe write", every write to that array fails with the following stacktrace. http://code.bulix.org/eh8iew-88342?raw It seems to be generated by that warning here: http://lxr.free-electrons.com/source/crypto/async_tx/async_tx.c#L173 And indeed, if we dump the status of depend_tx here, it's already been acked. That doesn't happen if ASYNC_TX_DMA is disabled, hence using the software version of it, instead of relying on our XOR engine. It doesn't happen on any commit prior to the one mentionned above, with the exact same changes applied. These changes are meant to be contributed, so I can definitely push them somewhere if needed. I don't really know where to look for though, the change that is causing this is probably the change in ops_run_reconstruct6, but I'm not sure that this partial revert alone would work with regard to the rest of the patch. Maxime --=20 Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com --UthUFkbMtH2ceUK2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJVS2EeAAoJEBx+YmzsjxAgI5oQAJNU+1HF5pTal8QB6Q3NIuD4 SsNp8uNee2nTDq1Ix972pr7E6vcG0MZ6Pkvx+f6Qcx3LZuKlNKazIKFTvUTXTEN3 2t5Xe4O3GRFkij2XtBDfdqZAR6rsIz4itrUngm9iXv/SUFaV8baBLWM8YDyHeXU0 TdXUXomj8L32jfkQdlQ2+ztbPlV5QQabMTWmgO5IXfxronMMRC3p+zXb+hbO1BV+ pqKVXMhLO09utaKNPSow7SuhnVMaz46QTCWK6Uim/82B8svNuUXfh16ZW1bLKazS TY2F6jcUC08qk37i1PbzrXJW6o8mQrl1kkUM5Wag3oXDC8DVaEp1XcV/QFa6Aqao BYDw8SjCWdaIHGb2Vh+5Jak5aU2kseFFIOCHXmITsnAKtYtDZmwt5HYcfROOup5B 1XRmw3JvE1Fm++wMbGrrM121m4b3rXVsagzfIco0utOZ7aZYJFsETZjIo31XUzlB yvjkx5nGBzM4Gjf7KwKLdrEji9TJqJVUTzdaHVUPKXu2T3aPSvKvvjBiQZa6JJ2H 3Z87zZ5/Qz7DHF/GBPve3SZ6wTTAYGJJTRz///1kDO5rNPdo42aXoD3x75n2IuSV gD/79xBePUcawVjQ2Sf3CbvooE9qjoifCVRiiVWCIUKIkdhU74llLGwnHxsUt70I 9OdW3L4LrDxrZBDST4R9 =lIFf -----END PGP SIGNATURE----- --UthUFkbMtH2ceUK2-- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/