public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Robert Hancock <hancockr@shaw.ca>
To: Andi Kleen <ak@suse.de>
Cc: linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: X86_64 + VIA + 4g problems
Date: Mon, 02 Jan 2006 14:15:40 -0600	[thread overview]
Message-ID: <43B989EC.2050704@shaw.ca> (raw)
In-Reply-To: <200601022053.31534.ak@suse.de>

Andi Kleen wrote:
>>This brings up something I've been wondering. It's possible to run most 
>>64-bit capable PCI devices in a 32-bit slot (i.e. with the 64-bit part 
>>hanging out of the slot). In this configuration the device will not be 
>>able to use 64-bit DMA (unless it supports dual address cycle). However, 
>>who is supposed to detect this and know to not try to use DMA addresses 
>>above 4GB on that device? 
> 
> 
> 64bit PCI-X bus has nothing to do with the addressing capability. It
> just gives you more bandwidth.

Indeed, I misunderstood how this worked.. Accesses to addresses >4GB 
must always use DAC addressing, the address can just be decoded faster 
if the extra 64-bit data lines are connected.

I think there could still be an issue if the PCI bus does not support 
DAC and the device tries to use PCI DAC addressing causing the bus to 
choke or the wrong RAM to get accessed. Apparently this is a real 
problem according to MS:

http://www.microsoft.com/whdc/system/platform/server/PAE/PAEdrv.mspx

"Unfortunately, Microsoft is finding that not all PCI buses on a system 
board support DAC, which is required for a 32-bit PCI adapter to address 
more than 4 GB of memory. Furthermore, there is no way for a DAC-capable 
PCI device (or its associated driver) to know that it is running on a 
non-DAC-capable bus."

Microsoft's solution is to disable all memory above 4GB if 
non-DAC-capable buses are present - largely due to their API limitations 
and the number of broken drivers that don't call proper DMA functions. 
Haha to them, I guess..

I'm not sure if this would be an issue with Linux. I would suspect that 
it could be, if there are indeed such buses that can't support DAC.. In 
this case the right thing to do would be to reject requests for DMA 
masks larger than 4GB for devices located on such a bus.

-- 
Robert Hancock      Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@nospamshaw.ca
Home Page: http://www.roberthancock.com/

  reply	other threads:[~2006-01-02 20:15 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <5qvTv-8f-17@gated-at.bofh.it>
     [not found] ` <5qAKf-7n4-19@gated-at.bofh.it>
2006-01-02 19:18   ` X86_64 + VIA + 4g problems Robert Hancock
2006-01-02 19:53     ` Andi Kleen
2006-01-02 20:15       ` Robert Hancock [this message]
2006-01-02 20:39         ` Andi Kleen
     [not found]   ` <5qBcJ-7ZZ-5@gated-at.bofh.it>
     [not found]     ` <5qDez-2Qf-19@gated-at.bofh.it>
     [not found]       ` <5r2nz-63n-233@gated-at.bofh.it>
2006-01-04  3:03         ` Robert Hancock
2006-01-02 11:09 Dieter Stüken
2006-01-02 12:26 ` Carsten Otto
2006-01-02 16:22 ` Andi Kleen
2006-01-02 16:52   ` Carsten Otto
2006-01-02 17:46     ` Carsten Otto
2006-01-02 19:01     ` Andi Kleen
2006-01-03 22:54       ` Carsten Otto
2006-01-03 10:04   ` Dieter Stüken
2006-01-03 13:58     ` Andi Kleen
2006-01-03 19:56       ` Dieter Stüken
2006-01-03 21:08       ` Dieter Stüken
2006-01-03 21:26         ` Andi Kleen
2006-01-04 10:27       ` Dieter Stüken
2006-01-04 10:57         ` Andi Kleen
2006-01-04 10:57       ` Dieter Stüken

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=43B989EC.2050704@shaw.ca \
    --to=hancockr@shaw.ca \
    --cc=ak@suse.de \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox