On Fri, 2009-09-11 at 10:17 +0300, Mikhail Zolotaryov wrote:
> Benjamin Herrenschmidt wrote:
> > On Wed, 2009-09-09 at 17:40 +0300, Mikhail Zolotaryov wrote:
> >
> >> Hi Tom,
> >>
> >> In my case __dma_sync() calls flush_dcache_range() (it's due to
> >> alignment) from a tasklet - no OOPS. It uses dcbf instruction instead of
> >> dcbi - that's the difference as dcbf is not privileged.
> >>
> >
> > What it calls depends on the direction of the transfer.
> Would not agree with you in this point as __dma_sync() code is:
Well, it -does- depend on the direction of the transfer... and -also- on
the size & alignement :-)
Anyway, that is probably not the problem. From the log I've seen, it
just looks like a page fault due to a bad virtual address passed there.
Cheers,
Ben.
> case DMA_FROM_DEVICE:
> /*
> * invalidate only when cache-line aligned otherwise
> there is
> * the potential for discarding uncommitted data from
> the cache
> */
> if ((start & (L1_CACHE_BYTES - 1)) || (size &
> (L1_CACHE_BYTES - 1)))
> flush_dcache_range(start, end);
> else
> invalidate_dcache_range(start, end);
> break;
>
> So, actual instruction used depends on address/size alignment.
>
> > The tasklet runs
> > in priviledged mode, dcbi should work just fine... if passed a correct
> > address :-)
> >
> > Cheers,
> > Ben.
> >
> >
> >> Tom Burns wrote:
> >>
> >>> Hi Mikhail,
> >>>
> >>> Sorry, this DMA code is in a tasklet. Are you suggesting the
> >>> processor is in supervisor mode at that time? Calling
> >>> pci_dma_sync_sg_for_cpu() from the tasklet context is what generates
> >>> the OOPS. The entire oops is as follows, if it's relevant:
> >>>
> >>> Oops: kernel access of bad area, sig: 11 [#1]
> >>> NIP: c0003ab0 LR: c0010c30 CTR: 02400001
> >>> REGS: df117bd0 TRAP: 0300 Tainted: P (2.6.24.2)
> >>> MSR: 00029000 <EE,ME> CR: 44224042 XER: 20000000
> >>> DEAR: 3fd39000, ESR: 00800000
> >>> TASK = de5db7d0[157] 'cat' THREAD: df116000
> >>> GPR00: e11e5854 df117c80 de5db7d0 3fd39000 02400001 0000001f 00000002
> >>> 0079a169
> >>> GPR08: 00000001 c0310000 00000000 c0010c84 24224042 101c0dac c0310000
> >>> 10177000
> >>> GPR16: deb14200 df116000 e12062d0 e11f6104 de0f16c0 e11f0000 c0310000
> >>> e11f59cc
> >>> GPR24: e11f62d0 e11f0000 e11f0000 00000000 00000002 defee014 3fd39008
> >>> 87d39009
> >>> NIP [c0003ab0] invalidate_dcache_range+0x1c/0x30
> >>> LR [c0010c30] __dma_sync+0x58/0xac
> >>> Call Trace:
> >>> [df117c80] [0000000a] 0xa (unreliable)
> >>> [df117c90] [e11e5854] DoTasklet+0x67c/0xc90 [ideDriverDuo_cyph]
> >>> [df117ce0] [c001ee24] tasklet_action+0x60/0xcc
> >>> [df117cf0] [c001ef04] __do_softirq+0x74/0xe0
> >>> [df117d10] [c00067a8] do_softirq+0x54/0x58
> >>> [df117d20] [c001edb4] irq_exit+0x48/0x58
> >>> [df117d30] [c00069d0] do_IRQ+0x6c/0xc0
> >>> [df117d40] [c00020e0] ret_from_except+0x0/0x18
> >>> [df117e00] [c00501e0] unmap_vmas+0x2c4/0x560
> >>> [df117e90] [c0053ebc] exit_mmap+0x64/0xec
> >>> [df117ec0] [c00171ac] mmput+0x50/0xd4
> >>> [df117ed0] [c001aef8] exit_mm+0x80/0xe0
> >>> [df117ef0] [c001c818] do_exit+0x134/0x6f8
> >>> [df117f30] [c001ce14] do_group_exit+0x38/0x74
> >>> [df117f40] [c0001a80] ret_from_syscall+0x0/0x3c
> >>> Instruction dump:
> >>> 7c0018ac 38630020 4200fff8 7c0004ac 4e800020 38a0001f 7c632878 7c832050
> >>> 7c842a14 5484d97f 4d820020 7c8903a6 <7c001bac> 38630020 4200fff8
> >>> 7c0004ac
> >>> Kernel panic - not syncing: Aiee, killing interrupt handler!
> >>> Rebooting in 180 seconds..
> >>>
> >>>
> >>> Cheers,
> >>> Tom
> >>>
> >>> Mikhail Zolotaryov wrote:
> >>>
> >>>> Hi Tom,
> >>>>
> >>>> possible solution could be to use tasklet to perform DMA-related job
> >>>> (as in most cases DMA transfer is interrupt driven - makes sense).
> >>>>
> >>>>
> >>>> Tom Burns wrote:
> >>>>
> >>>>> Hi,
> >>>>>
> >>>>> With the default config for the Sequoia board on 2.6.24, calling
> >>>>> pci_dma_sync_sg_for_cpu() results in executing
> >>>>> invalidate_dcache_range() in arch/ppc/kernel/misc.S from
> >>>>> __dma_sync(). This OOPses on PPC440 since it tries to call directly
> >>>>> the assembly instruction dcbi, which can only be executed in
> >>>>> supervisor mode. We tried that before resorting to manual cache
> >>>>> line management with usermode-safe assembly calls.
> >>>>>
> >>>>> Regards,
> >>>>> Tom Burns
> >>>>> International Datacasting Corporation
> >>>>>
> >>>>> Mikhail Zolotaryov wrote:
> >>>>>
> >>>>>> Hi,
> >>>>>>
> >>>>>> Why manage cache lines manually, if appropriate code is a part of
> >>>>>> __dma_sync / dma_sync_single_for_device of DMA API ? (implies
> >>>>>> CONFIG_NOT_COHERENT_CACHE enabled, as default for Sequoia Board)
> >>>>>>
> >>>>>> Prodyut Hazarika wrote:
> >>>>>>
> >>>>>>> Hi Adam,
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>> Yes, I am using the 440EPx (same as the sequoia board). Our
> >>>>>>>> ideDriver is DMA'ing blocks of 192-byte data over the PCI bus
> >>>>>>>>
> >>>>>>>>
> >>>>>>> (using
> >>>>>>>
> >>>>>>>
> >>>>>>>> the Sil0680A PCI-IDE bridge). Most of the DMA's (depending on
> >>>>>>>> timing)
> >>>>>>>> end up being partially corrupted when we try to parse the data in
> >>>>>>>> the
> >>>>>>>> virtual page. We have confirmed the data is good before the PCI-IDE
> >>>>>>>> bridge. We are creating two 8K pages and map them to physical DMA
> >>>>>>>>
> >>>>>>>>
> >>>>>>> memory
> >>>>>>>
> >>>>>>>
> >>>>>>>> using single-entry scatter/gather structs. When a DMA block is
> >>>>>>>> corrupted, we see a random portion of it (always a multiple of
> >>>>>>>> 16byte
> >>>>>>>> cache lines) is overwritten with old data from the last time the
> >>>>>>>>
> >>>>>>>>
> >>>>>>> buffer
> >>>>>>>
> >>>>>>>
> >>>>>>>> was used.
> >>>>>>>>
> >>>>>>> This looks like a cache coherency problem.
> >>>>>>> Can you ensure that the TLB entries corresponding to the DMA
> >>>>>>> region has
> >>>>>>> the CacheInhibit bit set.
> >>>>>>> You will need a BDI connected to your system.
> >>>>>>>
> >>>>>>> Also, you will need to invalidate and flush the lines appropriately,
> >>>>>>> since in 440 cores,
> >>>>>>> L1Cache coherency is managed entirely by software.
> >>>>>>> Please look at drivers/net/ibm_newemac/mal.c and core.c for
> >>>>>>> example on
> >>>>>>> how to do it.
> >>>>>>>
> >>>>>>> Thanks
> >>>>>>> Prodyut
> >>>>>>>
> >>>>>>> On Thu, 2009-09-03 at 13:27 -0700, Prodyut Hazarika wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>>> Hi Adam,
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> Are you sure there is L2 cache on the 440?
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>> It depends on the SoC you are using. SoC like 460EX (Canyonlands
> >>>>>>>>
> >>>>>>>>
> >>>>>>> board)
> >>>>>>>
> >>>>>>>
> >>>>>>>> have L2Cache.
> >>>>>>>> It seems you are using a Sequoia board, which has a 440EPx SoC.
> >>>>>>>> 440EPx
> >>>>>>>> has a 440 cpu core, but no L2Cache.
> >>>>>>>> Could you please tell me which SoC you are using?
> >>>>>>>> You can also refer to the appropriate dts file to see if there is
> >>>>>>>> L2C.
> >>>>>>>> For example, in canyonlands.dts (460EX based board), we have the L2C
> >>>>>>>> entry.
> >>>>>>>> L2C0: l2c {
> >>>>>>>> ...
> >>>>>>>> }
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> I am seeing this problem with our custom IDE driver which is
> >>>>>>>>> based on
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>> pretty old code. Our driver uses pci_alloc_consistent() to allocate
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>> the
> >>>>>>>
> >>>>>>>
> >>>>>>>>> physical DMA memory and alloc_pages() to allocate a virtual
> >>>>>>>>> page. It then uses pci_map_sg() to map to a scatter/gather
> >>>>>>>>> buffer. Perhaps I should convert these to the DMA API calls as
> >>>>>>>>> you suggest.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>> Could you give more details on the consistency problem? It is a good
> >>>>>>>> idea to change to the new DMA APIs, but pci_alloc_consistent()
> >>>>>>>> should
> >>>>>>>> work too
> >>>>>>>>
> >>>>>>>> Thanks
> >>>>>>>> Prodyut On Thu, 2009-09-03 at 19:57 +1000, Benjamin
> >>>>>>>> Herrenschmidt wrote:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> On Thu, 2009-09-03 at 09:05 +0100, Chris Pringle wrote:
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> Hi Adam,
> >>>>>>>>>>
> >>>>>>>>>> If you have a look in include/asm-ppc/pgtable.h for the following
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>> section:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>> #ifdef CONFIG_44x
> >>>>>>>>>> #define _PAGE_BASE (_PAGE_PRESENT | _PAGE_ACCESSED |
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>> _PAGE_GUARDED)
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>> #else
> >>>>>>>>>> #define _PAGE_BASE (_PAGE_PRESENT | _PAGE_ACCESSED)
> >>>>>>>>>> #endif
> >>>>>>>>>>
> >>>>>>>>>> Try adding _PAGE_COHERENT to the appropriate line above and see if
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>> that
> >>>>>>>>
> >>>>>>>>>> fixes your issue - this causes the 'M' bit to be set on the page
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>> which
> >>>>>>>>
> >>>>>>>>>> sure enforce cache coherency. If it doesn't, you'll need to check
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>> the
> >>>>>>>>
> >>>>>>>>>> 'M' bit isn't being masked out in head_44x.S (it was originally
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>> masked
> >>>>>>>>
> >>>>>>>>>> out on arch/powerpc, but was fixed in later kernels when the cache
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>> coherency issues with non-SMP systems were resolved).
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>> I have some doubts about the usefulness of doing that for 4xx.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>> AFAIK,
> >>>>>>>
> >>>>>>>
> >>>>>>>>> the 440 core just ignores M.
> >>>>>>>>>
> >>>>>>>>> The problem lies probably elsewhere. Maybe the L2 cache coherency
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>> isn't
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> enabled or not working ?
> >>>>>>>>>
> >>>>>>>>> The L1 cache on 440 is simply not coherent, so drivers have to make
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>> sure
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> they use the appropriate DMA APIs which will do cache flushing when
> >>>>>>>>> needed.
> >>>>>>>>>
> >>>>>>>>> Adam, what driver is causing you that sort of problems ?
> >>>>>>>>>
> >>>>>>>>> Cheers,
> >>>>>>>>> Ben.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >> _______________________________________________
> >> Linuxppc-dev mailing list
> >> Linuxppc-dev@lists.ozlabs.org
> >> https://lists.ozlabs.org/listinfo/linuxppc-dev
> >>
> >
> >
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
