On Wed, Jul 24, 2013 at 11:13 PM, Peter LaDow wrote:
> There are other items, such as drivers for our custom hardware modules
> implemented on the FPGA. Perhaps I'll pull our drivers and run a
> stock kernel. Maybe a stock 83xx configuration (such as the
> MPC8349E-MITX). If we have problems ev
On Wed, Jul 24, 2013 at 3:08 PM, Benjamin Herrenschmidt
wrote:
> No, they resolve to the same thing under the hood. Did you do other
> changes ? Could it be another unrelated kernel bug causing something
> like use-after-free of network buffer or similar oddity unrelated to the
> network driver ?
On Wed, 2013-07-24 at 08:39 -0700, Peter LaDow wrote:
> A bit of history that may help. We were using an e100 (an 82559)
> part, but Intel EOL'd that part so we picked up the 82540EP (which
> they have also recently EOL'd). The e100 driver uses a different DMA
> model. It uses pci_map_single/pci
On Tue, Jul 23, 2013 at 9:27 PM, Benjamin Herrenschmidt
wrote:
> CONFIG_NOT_COHERENT_CACHE will do it for you (in
> arch/powerpc/kernel/dma.c) provided the driver does the right things vs.
> the DMA accessors but afaik e1000 does.
Well, when I went to make the changes I noted a few things. First
> On Fri, Jul 19, 2013 at 6:46 AM, Gerhard Sittig wrote:
> > So: No, not having to fiddle with DMA stuff when doing PCI need
> > not be a problem, it's actually expected. But since a DMA engine
> > might be involved (that's just not under your command), the
> > accompanying problems may arise.
On Tue, 2013-07-23 at 21:22 -0700, Peter LaDow wrote:
> On Fri, Jul 19, 2013 at 6:46 AM, Gerhard Sittig wrote:
> > So: No, not having to fiddle with DMA stuff when doing PCI need
> > not be a problem, it's actually expected. But since a DMA engine
> > might be involved (that's just not under you
On Fri, Jul 19, 2013 at 6:46 AM, Gerhard Sittig wrote:
> So: No, not having to fiddle with DMA stuff when doing PCI need
> not be a problem, it's actually expected. But since a DMA engine
> might be involved (that's just not under your command), the
> accompanying problems may arise. You may ne
On Thu, Jul 18, 2013 at 4:30 PM, Peter LaDow wrote:
>
> It does seem that for incoming PCI transactions the Freescale DMA
> engine is not used. And in our device tree we have the DMA engine
> commented out. That is, the "fsl,mpc8349-dma" and "fsl,elo-dma"
> compatible items are not present in th
On 07/18/2013 05:02:33 PM, Benjamin Herrenschmidt wrote:
On Thu, 2013-07-18 at 14:30 -0700, Peter LaDow wrote:
> We are still stumped on this one, but during a review of the system
> setup one thing came up that we aren't sure about is the device tree
> and the DMA engine.
>
> It does seem that f
On Thu, Jul 18, 2013 at 14:30 -0700, Peter LaDow wrote:
>
> We are still stumped on this one, but during a review of the system
> setup one thing came up that we aren't sure about is the device tree
> and the DMA engine.
>
> It does seem that for incoming PCI transactions the Freescale DMA
> engi
On Thu, 2013-07-18 at 14:30 -0700, Peter LaDow wrote:
> We are still stumped on this one, but during a review of the system
> setup one thing came up that we aren't sure about is the device tree
> and the DMA engine.
>
> It does seem that for incoming PCI transactions the Freescale DMA
> engine is
We are still stumped on this one, but during a review of the system
setup one thing came up that we aren't sure about is the device tree
and the DMA engine.
It does seem that for incoming PCI transactions the Freescale DMA
engine is not used. And in our device tree we have the DMA engine
commente
On Wed, Jul 10, 2013 at 2:40 PM, Benjamin Herrenschmidt
wrote:
> Did you get any traces that show the flow that happens around a case of
> corruption ?
Well, I captured a lot of data, both logging kernel output and
capturing PCI traffic. I've put the full console log output on
pastebin at http:/
On Wed, Jul 10, 2013 at 2:40 PM, Benjamin Herrenschmidt
wrote:
> Well, it should work,
I tried forcing NET_IP_ALIGN to 0, and I did see the DMA accesses
align on 32-bit boundaries with all the byte enables set. However,
the memory corruption still occurred.
> but it's possible that there i
On Wed, 2013-07-10 at 14:06 -0700, Peter LaDow wrote:
> I have a bit more information, but I'm not sure of the impact. So far
> I have been dump lots of debugging output trying to determine where
> this memory corruption could be coming from. I've sprinkled the
> driver with wmb() (near every DMA
I have a bit more information, but I'm not sure of the impact. So far
I have been dump lots of debugging output trying to determine where
this memory corruption could be coming from. I've sprinkled the
driver with wmb() (near every DMA function and the hardware IO), loads
of printk's to get the D
On Sat, Jun 22, 2013 at 5:00 PM, Benjamin Herrenschmidt
wrote:
> Afaik e300 is slightly out of order, maybe it's missing a memory barrier
> somewhere One thing to try is to add some to the dma_map/unmap ops.
I went through the driver and added memory barriers to the
dma_map_page/dma_unmap_pag
On Sun, 2013-06-23 at 20:47 -0700, Peter LaDow wrote:
> >
> >
> > On Jun 23, 2013, at 6:16 PM, Benjamin Herrenschmidt
> > wrote:
> >> Also dbl check that the MMU is indeed mapping all these pages with the
> >> "M" bit.
> >
> > Just to be clear, do you mean the e1000 registers in PCI space? Or
>
>
> On Jun 23, 2013, at 6:16 PM, Benjamin Herrenschmidt
> wrote:
>> Also dbl check that the MMU is indeed mapping all these pages with the
>> "M" bit.
>
> Just to be clear, do you mean the e1000 registers in PCI space? Or the RAM
> pages?
>
> Thanks,
> Pete
On Sun, 2013-06-23 at 17:56 -0700, Peter LaDow wrote:
>
> On Jun 22, 2013, at 5:00 PM, Benjamin Herrenschmidt
> wrote:
>
> > On Fri, 2013-06-21 at 10:14 -0700, Peter LaDow wrote:
> >>
> > Afaik e300 is slightly out of order, maybe it's missing a memory
> barrier
> > somewhere One thing to t
On Jun 22, 2013, at 5:00 PM, Benjamin Herrenschmidt
wrote:
> On Fri, 2013-06-21 at 10:14 -0700, Peter LaDow wrote:
>>
> Afaik e300 is slightly out of order, maybe it's missing a memory barrier
> somewhere One thing to try is to add some to the dma_map/unmap ops.
>
> Also audit the driver
On Fri, 2013-06-21 at 10:14 -0700, Peter LaDow wrote:
> After a (finally!) successful search of the list archive, I did find
> this:
>
> http://web.archiveorange.com/archive/v/9IQA26gPvdf4foaTcmCV
>
> Which seems very related to my problem. However, the patch that is
> ultimately referenced is i
On Fri, Jun 21, 2013 at 9:56 AM, Peter LaDow wrote:
> We are running into a case where we get memory corruption when an
> external PCI master writes to the processor. We are using an MPC8349
> with an external Intel 82540EP (an E1000) part. I've spent several
> weeks on the e1000 list trying to
23 matches
Mail list logo
