From: Robert Hancock <hancockrwd@gmail.com>
To: "Jörn 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: Thu, 25 Mar 2010 18:56:03 -0600 [thread overview]
Message-ID: <51f3faa71003251756h17374375yd3a5d2acee2ffab9@mail.gmail.com> (raw)
In-Reply-To: <51f3faa71003161630g69160ea9tc1a2d448682632e5@mail.gmail.com>
On Tue, Mar 16, 2010 at 5:30 PM, Robert Hancock <hancockrwd@gmail.com> wrote:
> On Tue, Mar 16, 2010 at 2:35 AM, Jörn Engel <joern@dublin.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?
next prev parent reply other threads:[~2010-03-26 0:56 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 [this message]
2010-03-26 3:29 ` David Miller
2010-03-26 9:12 ` J�rn Engel
2010-03-27 1:55 ` Robert Hancock
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=51f3faa71003251756h17374375yd3a5d2acee2ffab9@mail.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).