Re: [Ocf-linux-users] Run cryptotest for md5 alg on talitos h/w driver lead to kernel Oops or gener
Brought to you by:
david-m
|
From: David M. <dav...@mc...> - 2011-10-12 04:34:53
|
Jivin 张绪峰 lays it down ...
>
>
>
>
> ? 2011-10-12 11:53:37,"David McCullough" <dav...@mc...> ??:
> >
> >Jivin ??? lays it down ...
> >> After run some tests and have a investigation, I found the generated error interrupt
> >> have relationship with the length of the descriptor pointer entry, here is the relative codes:
> >> ---------------------------------------------------------------------------------------------------------------
> >> } else if (crp->crp_flags & CRYPTO_F_IOV) {
> >> /* using IOV buffers */
> >> struct uio *uiop = (struct uio *)crp->crp_buf;
> >> if (uiop->uio_iovcnt > 1) {
> >> printk("%s: iov frags unimplemented\n",
> >> device_get_nameunit(sc->sc_cdev));
> >> err = EINVAL;
> >> goto errout;
> >> }
> >> td->ptr[in_fifo].ptr = dma_map_single(device,
> >> uiop->uio_iov->iov_base, crp->crp_ilen, DMA_TO_DEVICE);
> >> td->ptr[in_fifo].len = crp->crp_ilen;
> >> /* crp_olen is never set; always use crp_ilen */
> >> td->ptr[out_fifo].ptr = dma_map_single(device,
> >> uiop->uio_iov->iov_base,
> >> crp->crp_ilen, DMA_TO_DEVICE);
> >> td->ptr[out_fifo].len = crp->crp_ilen;
> >> } else {
> >> /* using contig buffers */
> >> ------------------------------------------------------------------------------------------------------
> >> If I change "td->ptr[in_fifo].len = crp->crp_ilen;" to "td->ptr[in_fifo].len = 32;" and
> >> change "td->ptr[out_fifo].len = crp->crp_ilen; " to "td->ptr[out_fifo].len = 32", then I can
> >> run "./cryptotest -va md5 1 1024" successfully without any error interrupt, but surly it's
> >> not correct.
> >
> >Kim's the best person to help you on this one I think. Hopefully he's
> >kicking around somewhere :-)
> >
> >What was the value of crp->crp_ilen before you changed it to 32 ?
> Thanks for your reply, David.
>
> The value of crp->crp_ilen depends on what I set for the number of bytes of text to encrypt,
> eg. if I run "./cryptotest -va md5 1 1024", then crp->crp_ilen is 1024.
Ok, that makes sense.
Not sure why this would be causing the HW/driver to get upset, hopefully
someone who knows the chip can comment :-)
Its interesting that the drivers is mapping the same address for
INPUT/OUTPUT (uiop->uio_iov->iov_base) when it could do it once as a
DMA_BIDIRECTIONAL ? I don't think it would matter myself, but it might be
something to look at ?
Cheers,
Davidm
> >Cheers,
> >Davidm
> >
> >
> >> At 2011-10-10 16:03:49,"???" <sea...@12...> wrote:
> >>
> >>
> >> Hi experts,
> >>
> >> I meet a problem when run cryptotest for md5 alg on talitos h/w driver.
> >> Board: Freescale mpc8572ds board
> >> OS: linux-2.6.34
> >>
> >> Reproduce steps:
> >> 1. # mknod /dev/crypto c 10 70
> >> 2. # insmod ocf.ko
> >> 3. # insmod cryptodev.ko
> >> 4. # insmod talitos.ko
> >> 5. # ./cryptotest -va md5 1 1024
> >> crid = 3000000
> >> alg = md5
> >> session = 0x0
> >> device = talitos0
> >> count = 1, size = 1024
> >> cleartext:
> >> 0000: 38 21 33 74 73 31 21 75 68 37 36 68 33 74 30 75
> >> 0010: 32 75 32 31 61 74 73 69 39 65 38 30 69 61 6f 6a
> >> cryptotest: line 465:ioctl(CIOCCRYPT): Input/output error
> >> 6. # dmesg
> >> talitos0: got error interrupt - ISR 0x00000002_00000200
> >> 7. # ./cryptotest -va md5 1 64
> >> Unable to handle kernel paging request for data at address 0x00000004
> >> Faulting instruction address: 0xc00d18fc
> >> Oops: Kernel access of bad area, sig: 11 [#1]
> >> PREEMPT 8 68 38 65 33 73SMP NR_CPUS=2 LTT NESTING LEVEL : 0
> >> MPC8572 DS
> >> NIP [c00d18fc] vma_prio_tree_remove+0x118/0x130
> >> LR [c00de52c] __remove_shared_vm_struct+0x60/0x90
> >> Call Trace:
> >> [ef115de0] [c141c0b8] 0xc141c0b8 (unreliable)
> >> [ef115e00] [c00de52c] __remove_shared_vm_struct+0x60/0x90
> >> [ef115e10] [c00de59c] unlink_file_vma+0x40/0x5c
> >> [ef115e30] [c00dbde8] free_pgtables+0x60/0xbc
> >> [ef115e50] [c00de238] exit_mmap+0x124/0x1b4
> >> [ef115e80] [c0044c1c] mmput+0x58/0x120
> >> [ef115e90] [c0049948] exit_mm+0x148/0x168
> >> [ef115ec0] [c004baac] do_exit+0x5d8/0x6b0
> >> [ef115f10] [c004bbcc] do_group_exit+0x48/0xa8
> >> [ef115f30] [c004bc40] sys_exit_group+0x14/0x28
> >> [ef115f40] [c0010ef0] ret_from_syscall+0x0/0x4
> >> --- Exception: c01 at 0xfef56c0
> >> LR = 0xfef5690
> >> Instruction dump:
> >> 3949ffd4 91280000 91090004 900b002c 915f0038 900b0030 93ea0038 4bffff8c
> >> 814b0030 380b002c 812b002c 912a0000 <91490004> 900b002c 900b0030 4bffff6c
> >> ---[ end trace 11d846f2058aa86c ]---
> >> Fixing recursive fault but reboot is needed!
> >> BUG: scheduling while atomic: cryptotest/138/0x00000003
> >> Modules linked in: ocf(P) cryptodev(P) talitos
> >> Call Trace:
> >> [ef115bd0] [c0007a04] show_stack+0x44/0x160 (unreliable)
> >> [ef115c00] [c00392f0] __schedule_bug+0x80/0x84
> >> [ef115c10] [c0541ba0] schedule+0x460/0x638
> >> [ef115c90] [c004bb00] do_exit+0x62c/0x6b0
> >> [ef115ce0] [c000dfa4] die+0xf0/0x224
> >> [ef115d10] [c001523c] bad_page_fault+0x90/0xc8
> >> [ef115d20] [c00113a8] handle_page_fault+0x7c/0x80
> >> --- Exception: 300 at vma_prio_tree_remove+0x118/0x130
> >> LR = __remove_shared_vm_struct+0x60/0x90
> >> [ef115de0] [c141c0b8] 0xc141c0b8 (unreliable)
> >> [ef115e00] [c00de52c] __remove_shared_vm_struct+0x60/0x90
> >> [ef115e10] [c00de59c] unlink_file_vma+0x40/0x5c
> >>
> >>
> >> The interrupt error is MDEU AE (address error), but it's really difficult for me to trace the root cause.
> >> I'm not sure why the kernel Oops happens when tried 64 sizes, and it was not always happens, I suspect
> >> it was caused by the same reason with error interrupt.
> >> Moreover, it's ok to run "./cryptotest -va md5 1 8".
> >> Please help me, thanks in advance!
> >>
> >>
> >>
> >>
> >> Thanks,
> >> Xufeng Zhang
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >
> >--
> >David McCullough, dav...@mc..., Ph:+61 734352815
> >McAfee - SnapGear http://www.mcafee.com http://www.uCdot.org
>
>
>
>
--
David McCullough, dav...@mc..., Ph:+61 734352815
McAfee - SnapGear http://www.mcafee.com http://www.uCdot.org
|