From: Mark Hounschell <markh@compro.net>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: linux-pci@vger.kernel.org, Mark Hounschell <dmarkh@cfl.rr.com>,
linux-kernel@vger.kernel.org
Subject: Re: problems doing direct dma from a pci device to pci-e device
Date: Tue, 15 Sep 2009 07:23:49 -0400 [thread overview]
Message-ID: <4AAF7945.2030905@compro.net> (raw)
In-Reply-To: <20090911154714.70a94454@lxorguk.ukuu.org.uk>
Alan Cox wrote:
>> I now have an AM3 based DFI DK 790FXB-M3H5 motherboard. This board has 3 regular
>> PCI slots and 3 PCI-E (16x) slots. I also have a PCI-E (x4) version of the VMIC-5565
>> reflective memory card in one of the PCI-E slots and our gpiohsd card in one of the regular
>> PCI slots. All on the motherboard. No expansion slots being used. However I cannot get
>> data from our gpiohsd into the PCI-E VMIC-5565 cards memory. I can certainly get the data there
>> from a userland buffer, no problem. Just not from one card to the other directly. Oh and when
>> I put the regular PCI version of the VMIC into one of the regular PCI slots everything works
>> as expected. They are then both on the same PCI bus and no bridges are involved though.
>
> Have you verified with the vendor that such DMA works properly ? There is
> a long history of there being boards where some device to device DMA
> exploded or vanished. The arrival of PCI capture cards doing direct to
> video DMA cleaned the world up (eg the BT848) but I wouldn't be suprised
> if this recurred somewhere since they were popular and nobody really
> noticed as they didn't run such an unusual config.
>
I have now verified the the VMIC card does support this type of I/O. I dug up the MB I was
using during my original testing. It's has almost the same slot configuration but an nvidia chip
set as opposed to AMD. It does in fact work fine using that MB with the nvidia chip set.
I have 3 different boards with AMD chip sets and none of them work.
> Also does the board have a true IOMMU in the PCI-E side of the system ?
> It's not a chipset I know.
>
I'm not sure what you mean by "a true" IOMMU, afaict the IOMMU is now
called "Virtualization Technology" or works in conjunction with it and almost
any new MB has it. "Virtualization" can be enabled or disabled via a BIOS setting.
So I assume when "Virtualization" is disabled that the IOMMU is disabled. Would
that be a correct assumption? And I also assume, from the AMD spec on it, that
when the IOMMU is disabled addresses are passed unaltered through it?
The MB I have in which all this works, works with the BIOS "Virtualization"
setting enabled or disabled. That was unexpected and I don't really understand that.
Also the MBs that it doesn't work on, doesn't work with it enabled or disabled.
So I am still at complete loss as to what is really happening.
I suppose the BIOS setting in each of the MBs could be broken. The one that
works is disabled even when enabled in the BIOS, and the one that doesn't work
is enabled even when disabled in the BIOS?? Just a guess.
I guess with some time I might be able to figure out how to probe the IOMMU
off the bridges in question to see if they are on or off??
I was hoping the lspci data I sent would show something obvious to the experts
unrelated to the IOMMU.
Thanks again in advance for any additional pointers
Regards Mark
prev parent reply other threads:[~2009-09-15 11:23 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-11 14:13 problems doing direct dma from a pci device to pci-e device Mark Hounschell
2009-09-11 14:41 ` Richard B. Johnson
2009-09-11 14:50 ` Mark Hounschell
2009-09-11 14:47 ` Alan Cox
2009-09-11 15:25 ` Mark Hounschell
2009-09-11 15:46 ` Richard B. Johnson
2009-09-11 19:42 ` Mark Hounschell
2009-09-11 20:04 ` Mark Hounschell
2009-09-14 5:36 ` Grant Grundler
2009-09-14 8:03 ` Mark Hounschell
2009-09-15 11:23 ` Mark Hounschell [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=4AAF7945.2030905@compro.net \
--to=markh@compro.net \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=dmarkh@cfl.rr.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox