linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Murray <amurray@embedded-bits.co.uk>
To: shiv prakash Agarwal <chhotu.shiv@gmail.com>
Cc: Alex Williamson <alex.williamson@redhat.com>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Pratyush Anand <pratyush.anand@st.com>,
	Yinghai Lu <yinghai@kernel.org>
Subject: Re: Writing to BARs of PCIE device
Date: Fri, 4 Apr 2014 12:57:03 +0100	[thread overview]
Message-ID: <CAPcvp5GwigUPS_x+aq6BSWDQF_J6wthPL1H8FrVx_DR03rdmOA@mail.gmail.com> (raw)
In-Reply-To: <CAHH3p5L6BO0PfXG_pB18-Tt1waLEL6bDV_=-1wR+afeQXHGh=g@mail.gmail.com>

On 4 April 2014 07:14, shiv prakash Agarwal <chhotu.shiv@gmail.com> wrote:
> Thanks Alex,
>
> 1. I am not concerned about device functionality but need to verify
> PCIE interface only by stressing it.
>
> 2. But I don't see writes getting reflected for most of addresses.

That's probably to be expected - You are treating the address space
provided by the BARs as RAM, rather than MMIO. It's entirely up to the
endpoint vendor to determine how this address space responds to reads
and writes. You'll find that the address space probably consists of
registers, some of which will likely be read only.

>
> 3. Also very often, it hangs in middle with CPU soft lockup and rcu
> preempt failures as below:

This may also be expected. The endpoint may consider some of your
reads/writes to be invalid, e.g. writing to a read-only register,
writing/reading at an incorrect time/location. This may result in the
endpoint raising error messages or even failing to respond to read
requests. (How do you know that you're not telling the endpoint to
stop responding to subsequent reads?)

>
> [ 9732.090081] BUG: soft lockup- CPU#0 stuck for 22s! [update-notifier:1319]
> [ 9742.108839] INFO: rcu_preempt self-detected stall on CPU
> [ 9742.108848] INFO: rcu_preempt detected stalls on CPUs/tasks: { 0}
> (detected by 3, t=366016 jiffies, g=88556, c=88555, q=2037)
>
> 4. So query is why above 2 issues? I know it will affect device
> functionality but at least stress write test suite should work, right?

Only where you know that the BAR memory for your particular endpoint
is designed to support such behavior. I can't imagine that any off the
shelf device would.

A better stress test would be to plug in a load of network / SATA
cards and heavily use them.

Thanks,

Andrew Murray

  reply	other threads:[~2014-04-04 11:57 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-03 15:08 Writing to BARs of PCIE device shiv prakash Agarwal
2014-04-03 15:23 ` Alex Williamson
2014-04-04  6:14   ` shiv prakash Agarwal
2014-04-04 11:57     ` Andrew Murray [this message]
2014-04-09 11:32       ` shiv prakash Agarwal

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=CAPcvp5GwigUPS_x+aq6BSWDQF_J6wthPL1H8FrVx_DR03rdmOA@mail.gmail.com \
    --to=amurray@embedded-bits.co.uk \
    --cc=alex.williamson@redhat.com \
    --cc=bhelgaas@google.com \
    --cc=chhotu.shiv@gmail.com \
    --cc=linux-pci@vger.kernel.org \
    --cc=pratyush.anand@st.com \
    --cc=yinghai@kernel.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).