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 |