linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Lad, Prabhakar" <prabhakar.csengg@gmail.com>
To: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Cc: Kishon Vijay Abraham I <kishon@ti.com>,
	Chris Paterson <Chris.Paterson2@renesas.com>,
	Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
	linux-pci <linux-pci@vger.kernel.org>
Subject: Re: PCIe EPF
Date: Wed, 1 Apr 2020 09:00:03 +0100	[thread overview]
Message-ID: <CA+V-a8vK36es7Q6AB-t2wkyF-DNJa6GP5HZ41YgJG-PopxuHfw@mail.gmail.com> (raw)
In-Reply-To: <TYAPR01MB4544F0435DB48E168EF41B90D8C90@TYAPR01MB4544.jpnprd01.prod.outlook.com>

Hi Shimoda-san,

On Wed, Apr 1, 2020 at 2:25 AM Yoshihiro Shimoda
<yoshihiro.shimoda.uh@renesas.com> wrote:
>
> Hi Prabhakar-san,
>
> > From: Lad, Prabhakar, Sent: Wednesday, April 1, 2020 2:26 AM
> <snip>
> > > > > Did you try to probe the failure further by comparing the hexdumps? Where does
> > > > > the mismatch happen?
> > > > >
> > > > I shall dump the memory and check the values, but basically crc is failing.
> > >
> > > I'm also interesting about comparing the hexdump between host and ep.
> > > This is my gut feeling though, I'm guessing this is a timing issue
> > > because using coherent memory API will be on non-cache even if CPU access,
> > > but using steaming DMA API will be on cache if CPU access by
> > > dma_unmap_single(DMA_FROM_DEVICE) and get_random_bytes() in pci_endpoint_test_write().
> > >
> > > If my guess is correct, almost all hexdumps are the same, but last
> > > some bytes (I'm not sure how much bytes though) are not match.
> > >
> > So I did some experiments only focusing on read operation for now
> >
> > 1:  I tried printing the crc value in pci_epf_test_write() function
> > with below code snippet:
> >
> > @@ -472,6 +474,9 @@ static int pci_epf_test_write(struct pci_epf_test *epf_test)
> >          */
> >         usleep_range(1000, 2000);
> >
> > +       dev_err(dev, "%s %llx %llx csum: %x = %x\n", __func__, reg->dst_addr,
> > +               phys_addr, reg->checksum, crc32_le(~0, dst_addr, reg->size));
> > +
> >  err_dma_map:
> >         kfree(buf);
> >
> > But with this I get :
>
> I don't know why this happen for now.
>
> <snip>
> > 2: Instead of get_random_bytes() in pci_epf_test_write() I used
> > memset() with the fixed value
> <snip>
> > +++ b/drivers/pci/endpoint/functions/pci-epf-test.c
> > @@ -431,6 +431,8 @@ static int pci_epf_test_write(struct pci_epf_test *epf_test)
> >         }
> >
> >         get_random_bytes(buf, reg->size);
> > +       memset(buf, 0xDF, reg->size);
> >         reg->checksum = crc32_le(~0, buf, reg->size);
> >
> > And later for the dst buffer I did memset for dst_buffer
> >
> > @@ -472,6 +474,10 @@ static int pci_epf_test_write(struct pci_epf_test
> > *epf_test)
> >          */
> >         usleep_range(1000, 2000);
> >
> > +       memset(dst_addr, 0xDF, reg->size);
>
> I think this memset is not needed because this function calls memcpy_toio(dst_addr, buf,..).
>
> > +       dev_err(dev, "%s %llx %llx csum: %x\n", __func__, reg->dst_addr,
> > +               phys_addr, reg->checksum);
> > +
> >  err_dma_map:
> >         kfree(buf);
> >
> > But with this I get similar issue as above:
>
> I don't know why like the case 1 for now...
>
> <snip>
> >
> > 3: After making sure -s was aligned to 128 bytes memset and crc32_le
> > in pci_epf_test_write() didnt hit above issues,
> >  and now when I compared the crc value of both the buffers this
> > matched on endpoint!
>
> OK.
>
> > 4: Now focusing more in rootdevice, I added memset(buf, 0xDF,
> > reg->size); in pci_epf_test_write() function
> > and was dumping the contents of buffer in pci_endpoint_test_read()
> > with below function:
> >
> > static void print_buffer(struct device *dev, void *buff_addr, size_t size)
> > {
> >     size_t i;
> >     u64 *addr = buff_addr;
> >
> >     for(i = 0; i < size; i += sizeof(addr))
> >         dev_err(dev, "buf[%zu] : %llx\n", i, *addr);
> >
> >     dev_err(dev, "\n\n\n\n");
> > }
> >
> > Below is the dump from pci_endpoint_test_read() of one passing case
> > and other no-passing case:
> > The contents of buffer match as expected, but the crc32_le is
> > differrent and I am clue-less why is this
> > being caused when using non-coherent memory.
> >
> > root@hihope-rzg2m:~# pcitest -r -s 2176
> <snip>
> > [  528.556991] pci-endpoint-test 0000:01:00.0: pci_endpoint_test_read
> > ffff0004b61f9000 7e951000 910c690d=910c690d
>
> I'd like to know how to print these crc values. Your report on the case 1
> mentioned on pci-epf-test.c like below though.
>
> > +       dev_err(dev, "%s %llx %llx csum: %x = %x\n", __func__, reg->dst_addr,
> > +               phys_addr, reg->checksum, crc32_le(~0, dst_addr, reg->size));
>
> Also, as I mentioned on previous email, this is possible to cause timing issue.
> So, I'd like to where you added the hexdump on pci_endpoint_test.c.
> Perhaps, copy and pasting your whole debug diff is useful to understand about it.
>

Following is the complete diff:

diff --git a/drivers/misc/pci_endpoint_test.c b/drivers/misc/pci_endpoint_test.c
index 3c49514b4813..e7bf58a1fee8 100644
--- a/drivers/misc/pci_endpoint_test.c
+++ b/drivers/misc/pci_endpoint_test.c
@@ -561,6 +561,23 @@ static bool pci_endpoint_test_write(struct
pci_endpoint_test *test,
     return ret;
 }

+static void print_buffer(struct device *dev, void *buff_addr, size_t size)
+{
+    size_t i;
+    u64 *addr = buff_addr;
+
+    for(i = 0; i < size; i += sizeof(addr))
+        dev_err(dev, "buf[%zu] : %llx\n", i, *addr);
+
+    for(i = 0; i < size; i +=1) {
+        if (0x910c690d == crc32_le(~0, buff_addr, i))
+            dev_err(dev, "%x\n",
+                crc32_le(~0, buff_addr, i));
+    }
+
+    dev_err(dev, "\n\n\n\n");
+}
+
 static bool pci_endpoint_test_read(struct pci_endpoint_test *test,
                    unsigned long arg)
 {
@@ -608,7 +625,7 @@ static bool pci_endpoint_test_read(struct
pci_endpoint_test *test,
     }

     orig_phys_addr = dma_map_single(dev, orig_addr, size + alignment,
-                    DMA_FROM_DEVICE);
+                    DMA_BIDIRECTIONAL);
     if (dma_mapping_error(dev, orig_phys_addr)) {
         dev_err(dev, "failed to map source buffer address\n");
         ret = false;
@@ -640,12 +657,17 @@ static bool pci_endpoint_test_read(struct
pci_endpoint_test *test,
     wait_for_completion(&test->irq_raised);

     dma_unmap_single(dev, orig_phys_addr, size + alignment,
-             DMA_FROM_DEVICE);
+             DMA_BIDIRECTIONAL);

     crc32 = crc32_le(~0, addr, size);
     if (crc32 == pci_endpoint_test_readl(test, PCI_ENDPOINT_TEST_CHECKSUM))
         ret = true;

+    print_buffer(dev, addr, size);
+    dev_err(dev, "%s %px %llx %x=%x\n", __func__, orig_addr,
+        orig_phys_addr, crc32,
+        pci_endpoint_test_readl(test, PCI_ENDPOINT_TEST_CHECKSUM));
+
 err_phys_addr:
     kfree(orig_addr);
 err:

Note: I have added DMA_BIDIRECTIONAL that is because I am also
printing the buffer on ep
and calulating the crc

> > READ (   2176 bytes):           OKAY
> > root@hihope-rzg2m:~# pcitest -r -s 2176
> <snip>
> > [  533.457921] pci-endpoint-test 0000:01:00.0: pci_endpoint_test_read
> > ffff0004b61f9000 7e959800  ce535039=910c690d
> > READ (   2176 bytes):           NOT OKAY
> >
> > Note: for failure case the crc is always ce535039
>
> The value of ce535039 is from pci_endpoint_test_readl(test, PCI_ENDPOINT_TEST_CHECKSUM)?
> If so, it's strange because all 0xdf values with 2176 bytes should be 910c690d by crc32_le().
>
The value ce535039 is the one which is calculated from the buffer and
value 910c690d is the one
which is passed from the BAR memory which is correct.

Cheers,
--Prabhakar

  reply	other threads:[~2020-04-01  8:00 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-18 11:37 PCIe EPF Lad, Prabhakar
2020-03-20  5:28 ` Kishon Vijay Abraham I
2020-03-21 22:49   ` Lad, Prabhakar
2020-03-24  1:58     ` Kishon Vijay Abraham I
2020-03-24 14:41       ` Lad, Prabhakar
2020-03-28 18:44         ` Lad, Prabhakar
2020-03-29 14:04           ` Lad, Prabhakar
2020-03-30 11:59             ` Kishon Vijay Abraham I
2020-03-30 13:09               ` Lad, Prabhakar
2020-03-30 13:20                 ` Kishon Vijay Abraham I
2020-03-30 13:46                   ` Lad, Prabhakar
2020-03-31  7:10                     ` Yoshihiro Shimoda
2020-03-31 17:25                       ` Lad, Prabhakar
2020-04-01  1:25                         ` Yoshihiro Shimoda
2020-04-01  8:00                           ` Lad, Prabhakar [this message]
2020-04-01  8:50                             ` Yoshihiro Shimoda
2020-04-01  9:24                               ` Lad, Prabhakar
2020-04-02  1:22                                 ` Yoshihiro Shimoda
2020-04-02  4:58                                   ` Yoshihiro Shimoda
2020-04-02 17:44                                     ` Lad, Prabhakar

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=CA+V-a8vK36es7Q6AB-t2wkyF-DNJa6GP5HZ41YgJG-PopxuHfw@mail.gmail.com \
    --to=prabhakar.csengg@gmail.com \
    --cc=Chris.Paterson2@renesas.com \
    --cc=kishon@ti.com \
    --cc=linux-pci@vger.kernel.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=yoshihiro.shimoda.uh@renesas.com \
    /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).