All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anthony Foiani <tkil@scrye.com>
To: Xie Shaohui-B21989 <B21989@freescale.com>
Cc: Wood Scott-B07421 <B07421@freescale.com>,
	"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>
Subject: Re: SATA hang on 8315E triggered by heavy flash write?
Date: Fri, 31 May 2013 22:24:31 -0600	[thread overview]
Message-ID: <g4ndie9vk.fsf@dworkin.scrye.com> (raw)
In-Reply-To: <ED492CCEAF882048BC2237DE806547C90B1E8E68@039-SN2MPN1-013.039d.mgd.msft.net> (Xie Shaohui-B's message of "Thu\, 30 May 2013 07\:32\:10 +0000")


Shaohui, greetings --

Xie Shaohui-B21989 <B21989@freescale.com> writes:

> I found a MPC8315ERDB rev1.0 board and did some tests.

I bet that was fun.  :) Thanks for going the extra mile and finding
that hardware.  Were you able to unearth a 8315DS of any sort?

> First there is no limit speed issue on the board, so it seems it may
> only happen on the MPC8315DS board.

To be clear, the board we're using does boot and run just fine at
3Gbps most of the time; the CONFIG_MPC8315DS fix was one suggested by
our vendor, but even then, I suspect it was basically prophylactic.

Or, perhaps, it was conflated with the NOR / SATA issue -- see below.

> Second, the SATA can work well with NOR write operation on the ERDB
> board. So the two issues happened to you should be board issues.

Very possibly!

Our vendor has identified at least one possible error with the wiring
/ routing on this board, and have suggested a hardware modification.
Their fix makes sense, but any hardware modification introduces the
risk of breaking one of the few prototype boards.

Since we're very close to software delivery, and we have a workaround
in hand -- namely, don't write the disk during flash operations -- my
team has decided that we'll go with the software workaround until
initial delivery.

We should be able to do this modification and associated testing in
mid-July; at that point, I'll report back with our findings.

Thanks again for all your help; you and Scott have been extremely
helpful and have provided excellent support.  Apologies if it turns
out that it was all due to a wiring error.  :(

Best regards,
Anthony Foiani

      reply	other threads:[~2013-06-01  4:24 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-15  8:12 SATA hang on 8315E triggered by heavy flash write? Anthony Foiani
2013-05-21 21:44 ` Scott Wood
2013-05-22  4:16   ` Anthony Foiani
2013-05-22  6:15     ` Xie Shaohui-B21989
2013-05-23  5:52       ` Anthony Foiani
2013-05-23  6:04         ` Xie Shaohui-B21989
2013-05-23 15:10           ` Anthony Foiani
2013-05-23 15:49             ` Anthony Foiani
2013-05-27  7:50             ` Xie Shaohui-B21989
2013-05-28  0:29               ` Anthony Foiani
2013-05-30  7:32                 ` Xie Shaohui-B21989
2013-06-01  4:24                   ` Anthony Foiani [this message]

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=g4ndie9vk.fsf@dworkin.scrye.com \
    --to=tkil@scrye.com \
    --cc=B07421@freescale.com \
    --cc=B21989@freescale.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.