From: Robert Hancock <hancockr@shaw.ca>
To: Sanka Piyaratna <cesanka@yahoo.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: PCIe device driver question
Date: Thu, 31 Jul 2008 02:44:54 -0600 [thread overview]
Message-ID: <48917B86.8030600@shaw.ca> (raw)
In-Reply-To: <490172.6073.qm@web31708.mail.mud.yahoo.com>
Sanka Piyaratna wrote:
> I allocate memory in the user land using memalign function (typically I allocate about 500 MB) and pass this to the kernel space. In my device driver, I call get_user_pages() to lock down the memory and extract the relevant pages. A scatter-gather list is generated using these page addresses and hence derive the dma_addresses using page_to_phys() function. These addresses are programmed into a FIFO in the hardware device using a memory mapped register interface (PCI BAR based). Subsequently the hardware start filling up the pages and interrupt when a block of pages are complete. I notice the hardware hang (PCIe packets don't seem to get the acknowledgements from the root complex) when the DMA address is < 0x0000_0001_0000_0000. I have verified in the hardware that the PCIe packet is created with the correct address as programed by the device driver dma_address. If i can guard some how that the memory allocation is with in a certain area, I can stop the
> problem from occuring. Are there any bridge functionality in the Intel architecture that may mask a certain region of memory?
How are you formatting the addresses in the TLP? The PCI Express spec
says that for addresses below 4GB the 32-bit addressing format must be
used (you can't use the 64-bit format unconditionally). It could be that
is what is making the chipset unhappy.
next prev parent reply other threads:[~2008-07-31 8:45 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-30 22:55 PCIe device driver question Sanka Piyaratna
2008-07-31 8:44 ` Robert Hancock [this message]
-- strict thread matches above, loose matches on Subject: below --
2008-07-31 9:58 Sanka Piyaratna
[not found] <fa.+kKL98uFtvbcX3ymh2HlJuUDVwY@ifi.uio.no>
2008-07-30 19:24 ` Robert Hancock
[not found] <fa.PmBLCqOb4Xo53y3W9hAdnsU50Og@ifi.uio.no>
[not found] ` <fa.42mxuHHJP7XQmYeyxNoEC/NFUHA@ifi.uio.no>
2008-07-30 19:21 ` Robert Hancock
2008-07-31 13:11 ` V.Radhakrishnan
2008-07-31 17:37 ` Robert Hancock
2008-07-31 18:47 ` V.Radhakrishnan
2008-07-31 18:52 ` Robert Hancock
2008-07-31 20:47 ` V.Radhakrishnan
2008-07-30 16:09 Sanka Piyaratna
2008-07-30 16:51 ` V.Radhakrishnan
2008-07-30 16:55 ` Alan Cox
2008-07-30 16:00 Sanka Piyaratna
2008-07-30 15:47 ` Alan Cox
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=48917B86.8030600@shaw.ca \
--to=hancockr@shaw.ca \
--cc=cesanka@yahoo.com \
--cc=linux-kernel@vger.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 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.