From: Robert Hancock <hancockrwd@gmail.com>
To: "� Engel" <joern@dublin.logfs.org>
Cc: David Miller <davem@davemloft.net>,
torvalds@linux-foundation.org, linux-kernel@vger.kernel.org,
netdev@vger.kernel.org, romieu@fr.zoreil.com
Subject: Re: [Regression] r8169: enable 64-bit DMA by default for PCI Express devices (v2)
Date: Fri, 26 Mar 2010 19:55:44 -0600 [thread overview]
Message-ID: <4BAD65A0.7090309@gmail.com> (raw)
In-Reply-To: <20100326091234.GA11959@Dublin.logfs.org>
On 03/26/2010 03:12 AM, � Engel wrote:
> On Thu, 25 March 2010 18:56:03 -0600, Robert Hancock wrote:
>>
>> Francois, ping? Is there anyone else that has access to this kind of
>> information about these chips?
>>
>> It's kind of interesting that there's only been one report of this
>> though. Either the affected chips are rare among people testing
>> 2.6.34-rc or there's something more to this. Maybe something
>> wierd/unusual about Jörn's system?
>>
>> Jörn, are any other devices on your system working with 64-bit
>> addressing? Try doing this:
>>
>> find /sys -name "*dma_mask_bits*" | xargs cat
>>
>> Does anything show more than 32?
>
> I've slightly changed the command:
> # for i in `find /sys -name "*dma_mask_bits*"`; do echo -n "$i: "; cat $i; done
> /sys/devices/pci0000:00/0000:00:00.0/dma_mask_bits: 32
> /sys/devices/pci0000:00/0000:00:00.0/consistent_dma_mask_bits: 32
> /sys/devices/pci0000:00/0000:00:02.0/dma_mask_bits: 36
> /sys/devices/pci0000:00/0000:00:02.0/consistent_dma_mask_bits: 36
> /sys/devices/pci0000:00/0000:00:1c.0/dma_mask_bits: 32
> /sys/devices/pci0000:00/0000:00:1c.0/consistent_dma_mask_bits: 32
> /sys/devices/pci0000:00/0000:00:1c.1/dma_mask_bits: 32
> /sys/devices/pci0000:00/0000:00:1c.1/consistent_dma_mask_bits: 32
> /sys/devices/pci0000:00/0000:00:1c.1/0000:01:00.0/dma_mask_bits: 32
> /sys/devices/pci0000:00/0000:00:1c.1/0000:01:00.0/consistent_dma_mask_bits: 32
> /sys/devices/pci0000:00/0000:00:1d.0/dma_mask_bits: 32
> /sys/devices/pci0000:00/0000:00:1d.0/consistent_dma_mask_bits: 32
> /sys/devices/pci0000:00/0000:00:1d.1/dma_mask_bits: 32
> /sys/devices/pci0000:00/0000:00:1d.1/consistent_dma_mask_bits: 32
> /sys/devices/pci0000:00/0000:00:1d.2/dma_mask_bits: 32
> /sys/devices/pci0000:00/0000:00:1d.2/consistent_dma_mask_bits: 32
> /sys/devices/pci0000:00/0000:00:1d.3/dma_mask_bits: 32
> /sys/devices/pci0000:00/0000:00:1d.3/consistent_dma_mask_bits: 32
> /sys/devices/pci0000:00/0000:00:1d.7/dma_mask_bits: 32
> /sys/devices/pci0000:00/0000:00:1d.7/consistent_dma_mask_bits: 32
> /sys/devices/pci0000:00/0000:00:1e.0/dma_mask_bits: 32
> /sys/devices/pci0000:00/0000:00:1e.0/consistent_dma_mask_bits: 32
> /sys/devices/pci0000:00/0000:00:1f.0/dma_mask_bits: 32
> /sys/devices/pci0000:00/0000:00:1f.0/consistent_dma_mask_bits: 32
> /sys/devices/pci0000:00/0000:00:1f.1/dma_mask_bits: 32
> /sys/devices/pci0000:00/0000:00:1f.1/consistent_dma_mask_bits: 32
> /sys/devices/pci0000:00/0000:00:1f.2/dma_mask_bits: 32
> /sys/devices/pci0000:00/0000:00:1f.2/consistent_dma_mask_bits: 32
> /sys/devices/pci0000:00/0000:00:1f.3/dma_mask_bits: 32
> /sys/devices/pci0000:00/0000:00:1f.3/consistent_dma_mask_bits: 32
>
> One device, which should be this one:
> 00:02.0 VGA compatible controller: Intel Corporation 82G33/G31 Express Integrated Graphics Controller (rev 10)
Well, that one's 36 bits, but it's unclear whether that driver would
actually be likely to access anything over 4GB. It's possible that
there's just some general problem with 64-bit DMA on that machine.
The fact that even stuff like lspci and MII is breaking seems odd,
though. It could be that model of card doesn't like the PCIDAC register
bit being set (maybe it means something different on that model, or
something).
I suppose a publicly accessible datasheet for these chips is too much to
hope for?
next prev parent reply other threads:[~2010-03-27 1:55 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20100315150806.GA15354@Dublin.logfs.org>
[not found] ` <20100315151041.GA15667@Dublin.logfs.org>
2010-03-15 18:57 ` [Regression] r8169: enable 64-bit DMA by default for PCI Express devices (v2) David Miller
2010-03-15 23:28 ` Robert Hancock
2010-03-16 8:35 ` J�rn Engel
2010-03-16 23:30 ` Robert Hancock
2010-03-16 23:40 ` David Miller
2010-03-26 0:56 ` Robert Hancock
2010-03-26 3:29 ` David Miller
2010-03-26 9:12 ` J�rn Engel
2010-03-27 1:55 ` Robert Hancock [this message]
2010-03-27 6:38 ` J�rn Engel
2010-03-27 17:46 ` Robert Hancock
2010-03-27 22:00 ` J�rn Engel
2010-03-27 11:57 ` =?unknown-8bit?B?RnJhbsOnb2lz?= Romieu
2010-03-17 20:52 ` Francois Romieu
2010-03-18 9:03 ` J�rn Engel
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=4BAD65A0.7090309@gmail.com \
--to=hancockrwd@gmail.com \
--cc=davem@davemloft.net \
--cc=joern@dublin.logfs.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=romieu@fr.zoreil.com \
--cc=torvalds@linux-foundation.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;
as well as URLs for NNTP newsgroup(s).