Bug#783718: linux-image-3.16.0-4-kirkwood: Regression: mv_cesa crypto driver fails a self-test
Control: fixed -1 4.0.4-1
Control: fixed -1 3.18.5-1~exp1
On Sun, 2015-05-31 at 01:54 +0100, Ben Hutchings wrote:
> On Fri, 2015-05-29 at 13:27 +0200, JM wrote:
> > I have tested linux-image-kirkwood-4.0.0-2 from unstable and I can
> > confirm that this bug has been fixed upstream and mv_cesa passes
> > kernel self-tests.
>
> Unfortunately I can't see any relevant changes to the driver or tests
> between 3.16 and 4.0.
Neither can I, nor to arch/arm/mach-mvebu/ or
arch/arm/boot/dts/kirkwood*, which were long shots anyway :-(
The upgrade from 3.16 to 4.0 will have also have involved a switch from
board file to DTS based support. It would be conceivable that v3.16
board files were broken and that DTS would work, but I booted v3.16 with
a DTB and it still fails as described.
http://thread.gmane.org/gmane.linux.kernel.cryptoapi/6720/focus=6730
looks interesting. One of the two issues (non-zero nbytes to callback)
was fixed in v3.3 but the other one (dcaches) doesn't look to have been
fixed, at least not in a way which is obvious in the logs.
Those two did make me wonder about some of the scatter list and bounds
value stuff I see in "git log v3.16..v4.0 -- drivers/crypto" from
Leonidas S. Barbosa, which seemed to hit in v3.19, but unfortunately all
the v3.19's we uploaded FTBFS on armel so I can't easily check.
https://buildd.debian.org/status/logs.php?pkg=linux&arch=armel shows
v3.18 built which might be worth trying since it would split the
upstream commit range about in half at least, although it is still a big
range. I tried 3.18.5-1~exp1 and it didn't have the errors, so it seems
like it was already fixed by then.
Ian.
Reply to: