linux-kernel - Re: [Regression] r8169: enable 64-bit DMA by default for PCI Express devices (v2)

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: <51f3faa71003251756h17374375yd3a5d2acee2ffab9@mail.gmail.com>
Date:	Thu, 25 Mar 2010 18:56:03 -0600
From:	Robert Hancock <hancockrwd@...il.com>
To:	Jörn 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 Tue, Mar 16, 2010 at 5:30 PM, Robert Hancock <hancockrwd@...il.com> wrote:
> On Tue, Mar 16, 2010 at 2:35 AM, Jörn Engel <joern@...lin.logfs.org> wrote:
>> On Mon, 15 March 2010 17:28:45 -0600, Robert Hancock wrote:
>>>
>>> What are the symptoms?
>>
>> No more network. :)
>>
>> According to ifconfig the interface is up and running.  If I read
>> /sys/class/net/eth0 correctly, two packets have been sent and none
>> received.  LED on network card and switch is off.  mii-tool is
>> unhappy.
>>
>> With patch in:
>> Bikini:~# mii-tool
>>  No MII transceiver present!.
>>
>> With patch reverted:
>> Bikini:~# mii-tool
>> eth0: negotiated 100baseTx-FD flow-control, link ok
>>
>> I just noticed lspci is also unhappy.
>>
>> With patch in:
>> Bikini:~# lspci -vv > lspci
>> pcilib: sysfs_read_vpd: read failed: Connection timed out.
>>
>> With patch reverted:
>> Bikini:~# lspci -vv > lspci2
>> Bikini:~# diff -u lspci*
>> --- lspci       2010-03-16 09:03:02.000000000 +0100
>> +++ lspci2      2010-03-16 09:09:36.000000000 +0100
>> @@ -246,7 +246,7 @@
>>                Vector table: BAR=4 offset=00000000
>>                PBA: BAR=4 offset=00000800
>>        Capabilities: [cc] Vital Product Data
>> -               Not readable
>> +               Unknown small resource type 00, will not decode more.
>>        Capabilities: [100] Advanced Error Reporting
>>                UESta:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
>>                UEMsk:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
>>
>> As you might expect, delta is part of the ethernet controller.
>>
>> All "With patch in" output above is typed off the screen.  Beware of
>> typos.
>>
>>> Does setting use_dac=0 in the module options
>>> for r8169 also resolve the problem?
>>
>> /sys/modules/r8169 does not exist.  How odd.  Anyway, simply changing
>> the default in r8169.c to 0 fixes the problems for me.  Good call.
>
>
> I can't really explain how the MII and lspci output is being
> affected.. However, it's possible that some of the chips supported by
> this driver don't actually support 64-bit DMA. Your chip is quite a
> bit older than mine (RTL8102E seems to be one of the older, if not the
> oldest, PCI-E chipset supported by the driver).
>
> Francois, do you know if that's the case, or do you have any active
> contacts at Realtek who can say?
>
> In the meantime, I don't object to reverting the patch for now unless
> we get this sorted out quickly..

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?
--
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/