On Sun, Aug 11, 2013 at 7:32 PM, Benjamin Herrenschmidt
wrote:
> Do that help with e1000 as well ? IE. A bad clock might have caused
> malfunctions of the DMA for example...
No, it didn't help with the e1000. In fact, we have separate clocks
for the on-board components. This particular case was
On Mon, Aug 5, 2013 at 7:01 PM, David Hawkins wrote:
> I suspect the lack of either the 5V or 3.3V power rail to the card
> might be the problem.
>
> Did you probe the PCI edge connect to see what supplies were present?
For those that are interested, we did figure out what was going on.
Turns out
On Mon, Aug 5, 2013 at 4:07 PM, Peter LaDow wrote:
> However, replacing the 82540 based card with either a 3com 3C905TXM or
> the Netgear FA331, there is no response on the 0x10 IDSEL line. Thus
> it appears these cards are NOT responding to configuration reads. I
> think I have
On Mon, Aug 5, 2013 at 1:27 PM, David Hawkins wrote:
> 2. Have you probed the PCI bus using a bus analyzer or scope?
Ok. I managed to find someone with a bus extender, and have connected
both our analyzer and card.
With a working card (the 82540EM based card), I see configuration
reads on 0x000
On Mon, Aug 5, 2013 at 2:08 PM, David Hawkins wrote:
> My analyzer has an extender card that you first plug in, and then
> plug the board into that ... any chance someone in your organization
> has one of those cards? Alternatively, confirm the board works in
> a machine that has more than one slo
On Mon, Aug 5, 2013 at 1:27 PM, David Hawkins wrote:
> 1. Have you checked the power supplies on the PCI board?
>
>PCI boards can be powered from 3.3V or 5V, or both. I've had
>old PCs that only supply one or the other rail, and various
>evaluation boards that only supply 3.3V.
>
>
On Mon, Aug 5, 2013 at 11:25 AM, Anatolij Gustschin wrote:
> Maybe this card needs bigger delay to respond after PCI reset. You can
> try to re-build U-Boot with defined CONFIG_PCI_BOOTDELAY. Use 1000
> for CONFIG_PCI_BOOTDELAY in the first step and if detection works,
> try to decrease this value
On Mon, Aug 5, 2013 at 11:25 AM, Anatolij Gustschin wrote:
> Maybe this card needs bigger delay to respond after PCI reset. You can
> try to re-build U-Boot with defined CONFIG_PCI_BOOTDELAY. Use 1000
> for CONFIG_PCI_BOOTDELAY in the first step and if detection works,
> try to decrease this value
I have a PCI card (a Netgear FA331, vendor:device 100b:0020) that is
failing to be detected by our PPC platform. This device works just
fine in a PC, and other cards work just fine in the same PCI slot (we
have an Intel 82540EM based card that works).
But for some reason, neither u-boot nor the k
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
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 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. You may ne
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
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 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 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.
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 e10
I'm posting this to the ppc-dev since I think the problem may be
specific to the PPC kernel.
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
w
22 matches
Mail list logo
