On 01/05/2011 5:29 PM Gilles Chanteperdrix wrote:
>Steven A. Falco wrote:
>> On 01/05/2011 04:33 PM, Gilles Chanteperdrix wrote:
>>> Herrera-Bendezu, Luis wrote:
>>>> Gilles:
>>>>
>>>>> Herrera-Bendezu, Luis wrote:
>>>>>> Hello:
>>>>>>
>>>>>> I have the following setup:
>>>>>> PPC405EX
>>>>>> Linux 2.6.30.3
>>>>>> Xenomai 2.4.10
>>>>>> I-pipe 2.7-02
>>>>>> ppc_4xx-gcc (GCC) 4.2.2
>>>>>> Configuration file is attached
>>>>> Do you have the same issue with the latest version of the I-pipe patch
>>>>> for this same version of the Linux kernel? It should be 2.8-00.
>>>> Tried I-pipe 2.8-00 which needs Linux 2.6.32.
>>> Sorry, I misread the ftp list, I was rather thinking about:
>>> http://download.gna.org/adeos/patches/v2.6/powerpc/older/adeos-ipipe-2.6.30.3-powerpc-DENX-2.7-
>06.patch
>>>
>>>
>>> It resulted on same problem
>>>> as reported with Linux 2.6.30.3 I-pipe 2.7-02.
>>>>
>>>> Was there any particular set of changes that you expected it could fix the
>>>> problem? Do you think more recent versions may work? If yes, which version
>>>> could be tried?
>>> Yes, there was a fix, specifially in the powerpc tree, with mappings
>>> issue. But I think it is older than 2.6.32.
>>>
>>> Now that I look at your message again, your problem seems more likely to
>>> be in your code. Specifically, you say: "bus address returned by
>>> pci_alloc_consistent()". I do not think pci_alloc_consistent return
>>> value is a bus address. The dma_handle returned by pointer probably is.
>>> But I am not sure you are supposed to know this.
>>
>> pci_alloc_consistent() returns two values. The kernel address is
>> returned directly (as a void *), and the bus address is returned
>> through the dma_handle pointer (third function argument).
>>
>> Luis' original email indicated that he tried rtdm_mmap_to_user()
>> on the kernel address, and he tried rtdm_iomap_to_user() on the
>> bus address. Either way caused the crash he reported.
>
>Ok. Could you try to do the same operation with the native API? You just
>have to pass H_SHARED | H_DMA | H_NONCACHED as flags to rt_heap_create
>to get the same effect as pci_dma_alloc_coherent.
>
>Just to see if the error lies in RTDM implementation or in Xenomai
>generic code.
>
>
>>
>> We have a home-grown program (mm) that basically opens /dev/mem
>> and allows peek/poke. Using that with the bus address works to
>> access the memory. We also pass that address to our hardware,
>> and it correctly DMAs the data. So we believe the bus address
>> is correct.
>
>You mean much like devmem2? Now even part of the busybox?
>
>>
>> I believe Luis has also tried a third approach - allocating with
>> kzalloc(size, GFP_DMA), and using rtdm_mmap_to_user() on the
>> resulting pointer. That works, but getting the bus address is
>> a bit ugly - basically page_to_phys(virt_to_page()) of the pointer.
>>
>> So there is something different about the way pci_alloc_consistent()
>> allocates memory as compared to kzalloc(GFP_DMA). kzalloc(GFP_DMA)
>> works with rtdm_mmap_to_user() but pci_alloc_consistent() does
>> not.
>
>This gives me an idea. Could you try the following patch? Even before
>trying the native API.
>
>diff --git a/ksrc/skins/rtdm/drvlib.c b/ksrc/skins/rtdm/drvlib.c
>index 3495e63..d7dd3db 100644
>--- a/ksrc/skins/rtdm/drvlib.c
>+++ b/ksrc/skins/rtdm/drvlib.c
>@@ -1810,7 +1810,7 @@ static int rtdm_mmap_buffer(struct file *filp, struct
>vm_area_struct *vma)
> vaddr = (unsigned long)mmap_data->src_vaddr;
> paddr = mmap_data->src_paddr;
> if (paddr == 0) /* kmalloc memory? */
>- paddr = __pa(vaddr);
>+ paddr = page_to_phys(virt_to_page(vaddr));
>
> maddr = vma->vm_start;
> size = vma->vm_end - vma->vm_start;
>
>
>--
> Gilles.
Note: patch was slightly modified to:
diff --git a/ksrc/skins/rtdm/drvlib.c b/ksrc/skins/rtdm/drvlib.c
index 8922689..c8967db 100644
--- a/ksrc/skins/rtdm/drvlib.c
+++ b/ksrc/skins/rtdm/drvlib.c
@@ -1784,7 +1784,8 @@ static int rtdm_mmap_buffer(struct file *filp, struct vm_a
paddr = mmap_data->src_paddr;
if (!paddr)
/* kmalloc memory */
- paddr = virt_to_phys((void *)vaddr);
+ paddr = page_to_phys(virt_to_page(vaddr)) +
+ (unsigned long)(vaddr % PAGE_SIZE);
maddr = vma->vm_start;
size = vma->vm_end - vma->vm_start;
Problem remains. These are the two pieces of code: (1) does cause kernel panic
when memory is accessed from user space while (2) works fine:
#if DMA_KZALLOC == 0
// (1)
vsync_private.vbi_mem.kaddr =
pci_alloc_consistent(vsync_private.vf_data->fa->pdev,
vsync_private.vbi_mem.size,
&vsync_private.vbi_mem.daddr);
if (vsync_private.vbi_mem.kaddr == NULL) {
dev_err(&ofdev->dev,
"%s: no memory for PCI DMA\n", __FUNCTION__);
retval = -ENOMEM;
goto error_fs_bsem_free;
}
#else
// (2)
vsync_private.vbi_mem.kaddr = kzalloc(vsync_private.vbi_mem.size,
GFP_DMA);
vsync_private.vbi_mem.daddr =
page_to_phys(virt_to_page(vsync_private.vbi_mem.kaddr)) +
(unsigned long)vsync_private.vbi_mem.kaddr % PAGE_SIZE;
#endif
...
retval = rtdm_mmap_to_user(user_info,
vsync_private.vbi_mem.kaddr,
vsync_private.vbi_mem.size,
PROT_READ | PROT_WRITE,
&pcontext->vbi_mem.uaddr,
NULL,
NULL);
This is the kernel log when application ancvbirt attempts to read DMA memory
vbi_mem.uaddr:
DataData machine check in kernel mode.
Oops: Machine check, sig: 7 [#1]
Flex-AM
Modules linked in: magnum dsp vsync vreg flx_alt_tse codec flx_alt_fpga at24 pca
953x [last unloaded: at24]
NIP: c0008e24 LR: c0010920 CTR: c01d50e4
REGS: cfff9f50 TRAP: 0202 Not tainted (2.6.30.3-00059-g8f94ee9-dirty)
MSR: 00021030 <ME,CE,IR,DR> CR: 04000022 XER: 20000000
TASK = cdca3180[1716] 'ancvbirt' THREAD: cdc94000
GPR00: 00008030 cfff9d60 cdca3180 cfff9d70 00000001 00000005 c01d2d44 00006027
GPR08: 00000034 c0010920 00021032 c0008e24 cfff8248 10066ad4 0fff2400 0ffe86f8
GPR16: 0ffb702c 0ffdf610 cfff9e38 00008000 c032949c 10624dd3 00044b83 00000004
GPR24: c03e5098 cfff9e4c c03b3350 00000007 cfff9ec8 c03e5140 c03e513c 00000000
NIP [c0008e24] __ipipe_grab_irq+0x0/0xa4
LR [c0010920] __ipipe_ret_from_except+0x0/0xc
Call Trace:
Instruction dump:
4804c1ed 2f830200 7c651b78 409e0014 80010014 38210010 7c0803a6 4e800020
3c60c032 386361b0 38800200 4801af99 <9421fff0> 7c0802a6 93e1000c 90010014
Kernel panic - not syncing: Fatal exception
Rebooting in 1 seconds..
Luis
_______________________________________________
Xenomai-help mailing list
[email protected]
https://mail.gna.org/listinfo/xenomai-help
