From patchwork Sat Jun 5 07:39:55 2010 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Timo Teras X-Patchwork-Id: 54740 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 838ACB7D43 for ; Sat, 5 Jun 2010 17:40:00 +1000 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755446Ab0FEHjz (ORCPT ); Sat, 5 Jun 2010 03:39:55 -0400 Received: from ey-out-2122.google.com ([74.125.78.25]:12533 "EHLO ey-out-2122.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755249Ab0FEHjy (ORCPT ); Sat, 5 Jun 2010 03:39:54 -0400 Received: by ey-out-2122.google.com with SMTP id 25so131266eya.19 for ; Sat, 05 Jun 2010 00:39:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=hgEUxQbbyUQIJ+WQ7LrOghCF/RtzusrjMKCtvZhnVgU=; b=ReZep+jah9Xv7rMri5sd926IML5sadbLt4CdUMpfijD99Lrz8ElPFJ10Etu2I1xJ6h mCEt1i3xyle5Jn6v44w9gKrfGObc7Mc2/soFjJmlKSeeFiZhNP+KpgV3q0bQMm40j0ZG /+tGiQ93h7SSnBYLe2soCaHvqtxPGN3X+8MAI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=fnNeRyvj5sISGhgRl0sM0uZs5gMRMx9RBqx38uoUQHzz6bLyllU1XRrPXDtisA2s3t JDMcmwq/2hh7TBkw6j5/zeqO0QQlHXs56sqG9IOKhUXDJ8Ojy8xe3bbed3JTFwZeWKQL 5ikM29eAFuCA0TaYX4lUc9QjNcGF4sEpMKuyc= Received: by 10.213.35.193 with SMTP id q1mr9036337ebd.38.1275723593124; Sat, 05 Jun 2010 00:39:53 -0700 (PDT) Received: from [10.26.34.4] (letku109.adsl.netsonic.fi [194.29.195.109]) by mx.google.com with ESMTPS id 13sm1188696ewy.1.2010.06.05.00.39.52 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 05 Jun 2010 00:39:52 -0700 (PDT) Message-ID: <4C09FF4B.4050601@iki.fi> Date: Sat, 05 Jun 2010 10:39:55 +0300 From: =?UTF-8?B?VGltbyBUZXLDpHM=?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4 MIME-Version: 1.0 To: Phil Sutter , =?UTF-8?B?ZnJhbsOnb2lzIHJvbWlldQ==?= , netdev@vger.kernel.org Subject: [PATCH] Re: still having r8169 woes with XID 18000000 References: <4C08ED47.1030800@iki.fi> <20100604123641.ED8154CD45@orbit.nwl.cc> <4C08F953.1050800@iki.fi> <20100604134351.7981F4CD45@orbit.nwl.cc> <4C09387F.1050403@iki.fi> <4C09611B.2090805@iki.fi> In-Reply-To: <4C09611B.2090805@iki.fi> X-Enigmail-Version: 1.0.1 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On 06/04/2010 11:24 PM, Timo Teräs wrote: > On 06/04/2010 08:31 PM, Timo Teräs wrote: > r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded > r8169 0000:00:09.0: PCI->APIC IRQ transform: INT A -> IRQ 18 > r8169 0000:00:09.0: no PCI Express capability > eth0: RTL8169sc/8110sc at 0xf835c000, 00:30:18:a6:2b:6c, XID 18000000 IRQ 18 > r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded > r8169 0000:00:0b.0: PCI->APIC IRQ transform: INT A -> IRQ 19 > r8169 0000:00:0b.0: no PCI Express capability > eth1: RTL8169sc/8110sc at 0xf8360000, 00:30:18:a6:2b:6d, XID 18000000 IRQ 19 > r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded > r8169 0000:00:0c.0: PCI->APIC IRQ transform: INT A -> IRQ 16 > r8169 0000:00:0c.0: no PCI Express capability > eth2: RTL8169sc/8110sc at 0xf8364000, 00:30:18:a6:2b:6e, XID 18000000 IRQ 16 > r8169: mdio_write(f8364000, 0x00000003, 0000000a1) required 2000 cycles > r8169: mdio_write(f8364000, 0x00000000, 000001000) required 2000 cycles > r8169: mdio_write(f8364000, 0x00000000, 00000a0ff) required 2000 cycles > r8169: mdio_write(f8364000, 0x00000014, 00000fb54) required 2000 cycles > > And eth2 was not working. Reloading the module gave a lot of other > mdio_write and mdio_read errors. > > It seems to be pretty random when the errors occur, but that's the > reason why the NIC stops working: mdio_write() fails (one or more times) > at some crucial point of the board specific phy config code resulting in > bad state. > > Any ideas how to debug this further? Ok, I compared Realtek's and the in-tree driver. The only essential --- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html difference is that Realtek driver uses udelay(100) in mdio_write()'s busy polling loop where as the in-tree uses udelay(25). And that seems to be the magic difference! Using udelay(100) fixes this! I'm guessing that the phy needs slight delay between consecutive mdio_write's even if it has advertised that the write has been completed. And yes, just adding a small delay in the end of mdio_write does seem to work too. Francois, you think the below patch is ok? Should I send it as properly formatted commit? diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c index 217e709..6db62bf 100644 --- a/drivers/net/r8169.c +++ b/drivers/net/r8169.c @@ -559,6 +559,7 @@ static void mdio_write(void __iomem *ioaddr, break; udelay(25); } + udelay(25); } static int mdio_read(void __iomem *ioaddr, int reg_addr)