linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Peter LaDow <petela@gocougs.wsu.edu>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: linuxppc-dev@lists.ozlabs.org
Subject: Re: Inbound PCI and Memory Corruption
Date: Wed, 10 Jul 2013 14:06:28 -0700	[thread overview]
Message-ID: <CAN8Q1EetHpVkWFmbDGCE-3J4H7oJm0zE66SAdJyvtDb7OBc-gg@mail.gmail.com> (raw)
In-Reply-To: <1371945647.3944.106.camel@pasglop>

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 DMA addresses, and lots and lots of PCI traces.

One things that I noticed is that the addresses programmed into the
descriptor ring for the E1000 are not 32-bit aligned.  The E1000 part
is aligning the transfers, and use the BE's to mask off bytes.  Is
there an issue with the PPC (notably the MPC8349) with incoming PCI
transactions that are 32-bit word aligned but write less than a full
word?

In looking at the PCI trace, all the DMA's of packets from the E1000
start at a 32-bit aligned address, but the first and last words are
not full word writes.  For example (probably need a fixed font to
view):

Command | Address  |  Data     | /BE
Mem Wr  | 2950D180 |           |
                     FFFF0000  | 0011
                     FFFFFFFF  | 0000
                     DBA24DF0  | 0000
                     00085F19  | 0000
                     24000024  | 0000
                     0000C530  | 0000
                     80D81180  | 0000
                     F10DCA0A  | 0000
                     FF0DCA0A  | 0000
                     CF06CC06  | 0000
                     A1BA1000  | 0000
                     01400BC5  | 0000
                     F1001000  | 0000
                     00000000  | 0000
                     00000000  | 0000
                     68730000  | 0000
                     00000F22  | 1100

Note that the first word is only a 16-bit transfer (in the upper half)
and the last is only 16-bits (in the lower half).  And I dumped the
descriptors and here's what is read (via DMA):

Command | Address  |  Data     | /BE
Mem Rd  | 2A2A72F0 |           |
                     2950D812  | 0000
                     00000000  | 0000
                     C8C70040  | 0000
                     00000000  | 0000

Note that the descriptor programmed into the part has a DMA address
that is not word aligned.  And the E1000 part sets the proper byte
enables and does a write to the aligned address of 0x2850D180.

Is there any traction on this idea?

Thanks,
Pete

  parent reply	other threads:[~2013-07-10 21:06 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-21 16:56 Inbound PCI and Memory Corruption Peter LaDow
2013-06-21 17:14 ` Peter LaDow
2013-06-23  0:00   ` Benjamin Herrenschmidt
2013-06-24  0:56     ` Peter LaDow
2013-06-24  1:16       ` Benjamin Herrenschmidt
2013-06-24  3:47         ` Peter LaDow
2013-06-24  3:49           ` Benjamin Herrenschmidt
2013-06-25 18:44         ` Peter LaDow
2013-07-10 21:06     ` Peter LaDow [this message]
2013-07-10 21:40       ` Benjamin Herrenschmidt
2013-07-10 22:16         ` Peter LaDow
2013-07-11 21:00         ` Peter LaDow
2013-07-18 21:30           ` Peter LaDow
2013-07-18 22:02             ` Benjamin Herrenschmidt
2013-07-19 17:44               ` Scott Wood
2013-07-19 13:46             ` Gerhard Sittig
2013-07-24  4:22               ` Peter LaDow
2013-07-24  4:27                 ` Benjamin Herrenschmidt
2013-07-24 15:39                   ` Peter LaDow
2013-07-24 22:08                     ` Benjamin Herrenschmidt
2013-07-25  6:13                       ` Peter LaDow
2013-08-02 15:01                         ` Peter LaDow
2013-07-24  8:40                 ` David Laight
2013-07-19 20:13             ` Timur Tabi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAN8Q1EetHpVkWFmbDGCE-3J4H7oJm0zE66SAdJyvtDb7OBc-gg@mail.gmail.com \
    --to=petela@gocougs.wsu.edu \
    --cc=benh@kernel.crashing.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).