linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: "tiejun.chen" <tiejun.chen@windriver.com>
To: Eran Liberty <liberty@extricom.com>
Cc: linuxppc-dev@ozlabs.org, linux-pci@vger.kernel.org
Subject: Re: Freescale P2020 CPU Freeze over PCIe abort signal
Date: Mon, 18 Oct 2010 17:52:24 +0800	[thread overview]
Message-ID: <4CBC18D8.5060804@windriver.com> (raw)
In-Reply-To: <4CBB4D80.3030007@extricom.com>

Eran Liberty wrote:
> This should probably go to the Freescale support, as it feels like a
> hardware issue yet the end result is a very frozen Linux kernel so I
> post here first...
> 
> I have a programmable FPGA PCIe device connected to a Freescale's P2020
> PCIe port. As part of the bring-up tests, we are testing two faulty
> scenarios:
> 1. The FPGA totally ignores the PCIe transaction.
> 2. The FPGA return a transaction abort.
> 
> Both are plausible PCIe behavior and their should be outcome is
> documented in the PCIe spec. The first should be terminated by the
> transaction requestor timeout mechanism and raise an error, the second
> should abort the transaction and raise and error.
> 
> In P2020 if I do any of those the CPU is left hung over the transaction.
> 
> something like:
> in_le32(addr)
> 
> is turned into:
> 7c 00 04 ac     sync   7c 00 4c 2c     lwbrx   r0,0,r9
> 0c 00 00 00     twi     0,r0,0
> 4c 00 01 2c     isync
> 
> assembly code, where in r9 (in this example) hold an address which is
> physically mapped into the PCIe resource space.
> 
> The CPU will hang over the load instruction.
> 
> Just for the fun of it, I have wrote my own assembly function omitting
> everything but the load instruction; still freeze.
> Replace "lwbrx" with a simple "lwz"; still freeze.
> 
> It looks like the CPU snoozes till the PCIe transaction is done with no
> timeouts, ignoring any abort signal.
> 

AFAIK we can set one bit on PEX_ERR_DISR to detect PCI Express completion
time-out. If so one interrupt should be issued. But I'm not sure if this can fix
your issue.

Tiejun

> I am going to:
> A. Try to reach the Freescale support.
> B. Asked the FPGA designed to give me a new behavior that will stall the
> PCIe transaction replay for 10 sec, but after those return ok.
> C. report back here with either A or B.
> 
> If you have any ideas I would love to hear them.
> 
> -- Liberty
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
> 

  parent reply	other threads:[~2010-10-18  9:50 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-07 12:30 Freescale P2020 / 85xx PCIe and Advance Error Reporting (AER) service problem Eran Liberty
2010-10-07 14:42 ` Kumar Gala
2010-10-10 10:02   ` Eran Liberty
2010-10-11  0:19 ` Benjamin Herrenschmidt
2010-10-11 10:21   ` Eran Liberty
2010-10-11 11:32     ` Benjamin Herrenschmidt
2010-10-17 19:24       ` Freescale P2020 CPU Freeze over PCIe abort signal Eran Liberty
2010-10-18  5:26         ` Bin Meng
2010-10-18  9:52         ` tiejun.chen [this message]
2010-10-18 11:44           ` Eran Liberty
2010-10-18 18:00         ` Eran Liberty
2010-10-19 16:53           ` Eran Liberty
  -- strict thread matches above, loose matches on Subject: below --
2013-01-23 17:41 siva kumar
2013-01-23 21:40 ` Scott Wood
2013-01-24 11:53   ` siva kumar
2013-01-25  1:03     ` Scott Wood

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=4CBC18D8.5060804@windriver.com \
    --to=tiejun.chen@windriver.com \
    --cc=liberty@extricom.com \
    --cc=linux-pci@vger.kernel.org \
    --cc=linuxppc-dev@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).