From: Gary Thomas <gary@mlbassoc.com>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Linux PPC Development <linuxppc-dev@ozlabs.org>
Subject: Re: Change in PCI behaviour
Date: Sat, 04 Dec 2010 05:49:28 -0700 [thread overview]
Message-ID: <4CFA38D8.3060209@mlbassoc.com> (raw)
In-Reply-To: <4CEBD33D.7020603@mlbassoc.com>
On 11/23/2010 07:44 AM, Gary Thomas wrote:
> On 11/22/2010 01:26 PM, Benjamin Herrenschmidt wrote:
>> On Mon, 2010-11-22 at 03:01 -0700, Gary Thomas wrote:
>>> I have a bit more information on this. I'm pretty sure that the failures
>>> are only happening in my SCSI (SATA actually) code. My board (8347ea)
>>> has
>>> a PCI bus with a SIL SATA controller. This combo works perfectly in
>>> 2.6.28.
>>> In 2.6.32, it will run for a while (possibly quite a while), then
>>> timeout
>>> trying to do a large block write - typically 256 blocks. Once this
>>> timeout
>>> happens, the SIL controller is stuck and accesses to it will eventually
>>> cause the whole system to hang (as above).
>>>
>>> Was there any major change in how PCI or DMA was handled between 2.6.28
>>> and 2.6.32? Given the ephemeral nature of these failures (multiple runs
>>> all eventually fail, but never the same twice), my only hope of
>>> fixing it
>>> will be to have some ideas what might have changed.
>>
>> Maybe the changes you did to the PCI outbound windows are now breaking
>> DMA ? Make sure the outbound and inbound don't overlap for example and
>> that all RAM is reachable for inbound.
>
> Here's what I did to work around this - in my DTS, I set up my PCI as
> ranges = <0x02000000 0x0 0xC4000000 0xC4000000 0x0 0x1C000000
> 0x01000000 0x0 0x00000000 0xB8000000 0x0 0x00100000>;
> Before, I had it as
> ranges = <0x02000000 0x0 0xC0000000 0xC0000000 0x0 0x20000000
> 0x01000000 0x0 0x00000000 0xB8000000 0x0 0x00100000>;
>
> I wasn't sure how to reserve the memory (based on your earlier suggestion),
> so I just narrowed the window. Note that I did not change the PCI hardware
> registers (maybe the FSL code does?), so the outbound window should still
> be the whole 512MB.
>
> If this isn't viable, perhaps you could explain a bit more how to reserve
> such a chunk of memory so that the PCI mappings remain the same.
Any ideas on this? I'm a bit lost as to how to reserve the memory like
you suggested and what I've tried so far has met little success.
Thanks again
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
next prev parent reply other threads:[~2010-12-04 12:49 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-19 15:42 Change in PCI behaviour Gary Thomas
2010-11-19 21:46 ` Benjamin Herrenschmidt
2010-11-21 17:59 ` Gary Thomas
2010-11-22 10:01 ` Gary Thomas
2010-11-22 20:26 ` Benjamin Herrenschmidt
2010-11-23 14:44 ` Gary Thomas
2010-12-04 12:49 ` Gary Thomas [this message]
2010-12-04 21:07 ` Benjamin Herrenschmidt
2010-11-22 10:37 ` Gabriel Paubert
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=4CFA38D8.3060209@mlbassoc.com \
--to=gary@mlbassoc.com \
--cc=benh@kernel.crashing.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 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.