lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4BAD65A0.7090309@gmail.com>
Date:	Fri, 26 Mar 2010 19:55:44 -0600
From:	Robert Hancock <hancockrwd@...il.com>
To:	� Engel <joern@...lin.logfs.org>
CC:	David Miller <davem@...emloft.net>, torvalds@...ux-foundation.org,
	linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
	romieu@...zoreil.com
Subject: Re: [Regression] r8169: enable 64-bit DMA by default for PCI Express
 devices (v2)

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?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ