linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Christophe Lizzi <lizzi@csti.fr>
To: linuxppc-dev@lists.linuxppc.org
Cc: plaurent@csti.fr
Subject: PREP memory layout and PCI transactions
Date: Fri, 28 Jan 2000 10:47:10 +0100	[thread overview]
Message-ID: <200001280947.KAA09960@devl58> (raw)



Hi,

I'm currently porting a third-party RAID driver from ix86 to LinuxPPC.
The target is an MTX board with 32 Mbytes of RAM, running a 2.2.10 kernel.

The driver requests the device to fill some memory locations in kernel
space via DMA. This works just fine when such memory locations come
from pages allocated by get_free_page() or kmalloc().

However, this fails when these locations come from the *static* data
of the module, or from pages allocated by vmalloc().

Specifically, the pages returned by get_free_page() or kmalloc() are located
around kernel virtual addresses C1xxxxxx (bus addresses 81xxxxxx), while the
static data in question and the pages returned by vmalloc() are located
behind virtual addresses C4xxxxxx (bus addresses 84xxxxxx).

The PCI analyser sees on the PCI bus a memory write transaction initiated
by the device to such an 84xxxxxx address in memory. We can observe that this
transaction is never completed because the DEVSEL signal on the bus is not
asserted during the correct 5 clock time interval. The transaction is then
terminated as with a master-abort termination, meaning that this address
is not known by the memory controler as an address that can be accessed
from the PCI bus.

Is this a feature, a known restriction, or a bug? Maybe a register
describing the accessible address range from the bus is not correctly
initialised into the Falcon chip?

Thanks for your attention and time,

--Christophe

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

             reply	other threads:[~2000-01-28  9:47 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-01-28  9:47 Christophe Lizzi [this message]
2000-01-28 10:35 ` PREP memory layout and PCI transactions Gabriel Paubert
2000-01-28 15:52 ` Michel Lanners

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=200001280947.KAA09960@devl58 \
    --to=lizzi@csti.fr \
    --cc=linuxppc-dev@lists.linuxppc.org \
    --cc=plaurent@csti.fr \
    /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).