linux-crypto.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sven Schnelle <svens@stackframe.org>
To: Kim Phillips <kim.phillips@freescale.com>
Cc: <linux-crypto@vger.kernel.org>
Subject: Re: Kernel OOPS with Freescale talitos driver on ppc
Date: Tue, 20 Sep 2011 09:40:39 +0200	[thread overview]
Message-ID: <87zkhz3bm0.fsf@begreifnix.stackframe.org> (raw)
In-Reply-To: <20110919162001.e296597e.kim.phillips@freescale.com> (Kim Phillips's message of "Mon\, 19 Sep 2011 16\:20\:01 -0500")

Kim Phillips <kim.phillips@freescale.com> writes:

> On Mon, 19 Sep 2011 13:33:57 +0200
> Sven Schnelle <svens@stackframe.org> wrote:
>
>> Hi Kim,
>> 
>> i'm seeing the following oops on ppc (Freescale P1020):
>> 
>> talitos ffe30000.crypto: cur_desc: (channel 1) 00000000
>> Unable to handle kernel paging request for data at address 0x00000000
>
> You should have seen the "couldn't locate current descriptor" error
> message right before it crashed.

Yes, that message is printed before the oops output. Sorry for cutting
that off in the dmesg output.

>> I've fixed that with the attached patch, however, i have no idea why the
>> SEC engine doesn't return a descriptor pointer in CDPR. As i understand
>> the documentation, it should put the 'currently processed' descriptor
>> there. Can someone shed some light on this?
>
> I believe the CDPR may be overwritten by the time the core gets to
> it if there is another descriptor queued in the channel's fetch
> FIFO.

Hmm, i don't see that there are any other descriptor queued. But i can
add debug later.

> You may be able to glean more information about what happened
> by looking at the ISR execution units done/error bits in isr_lo, the
> descriptor buffer (displayed at the end of report_eu_error), or the
> EU ISRs themselves (see below).

The AESU unit says "data size error", probably because the input data to
aead_decrypt() isn't a multiple of the block size. I'm currently fixing
this in the code. However, i'm not sure if the crypto api or the HW
driver should pad the data to blocksize in such cases.

> fwiw, I just booted a vanilla 3.1-rc6 kernel on a p1020 with your
> config and CONFIG_CRYPTO_MANAGER_DISABLE_TESTS not set, and the
> selftests passed.  IPSec isn't enabled in your config.  Are you
> implementing a new algorithm?  If not, how to reproduce?

It is a custom layer 2 tunneling protocol, which doesn't use IPSec.
That's the reson we don't have that option enabled.

Thanks,

Sven

  reply	other threads:[~2011-09-20  7:40 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-19 11:33 Kernel OOPS with Freescale talitos driver on ppc Sven Schnelle
2011-09-19 21:20 ` Kim Phillips
2011-09-20  7:40   ` Sven Schnelle [this message]
2011-09-20 13:34   ` Sven Schnelle
2011-09-25  0:16     ` [PATCH] talitos: handle descriptor not found in error path Kim Phillips
2011-10-18  7:36       ` Herbert Xu
2011-10-18 16:17         ` Kim Phillips
2011-10-19 15:52           ` Herbert Xu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87zkhz3bm0.fsf@begreifnix.stackframe.org \
    --to=svens@stackframe.org \
    --cc=kim.phillips@freescale.com \
    --cc=linux-crypto@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).