Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp333666imm; Wed, 22 Aug 2018 05:09:14 -0700 (PDT) X-Google-Smtp-Source: AA+uWPwpzqZeZqLi/Hk8gGGJYEvT3e7Uckee/P3q4NNUT8MWIIH1yM5b3hb7T2ZNBdrojoutO70I X-Received: by 2002:a17:902:47c2:: with SMTP id d2-v6mr53343747plh.139.1534939754523; Wed, 22 Aug 2018 05:09:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1534939754; cv=none; d=google.com; s=arc-20160816; b=TYRAIwn8BTU+fVZHmHKlQcYf5Dg2gBFcZN0x6wkg3JlXWyguChCA7MSkqWA4V3XpcF AzSbWRsGHtnKZd5fEkYffKlbmp9urXb8jzDX/joF1PH+chOUTEurHayGynqDd6Yprpwc A064iJap4N4BeRAh2apiRTaf9k68k3TqjV7SA0CWHUqtRLhzl+0xGLoj9UVnoPPgbYJF +bQPGpHRFOI40phLsxVNWMWROoc/SJayI1udjKiPz3E46CAiQE3PRhZYLI9aIpkuMTsR xt9IMm6E5DOmvypAl2t2oGSJXn+Otf7SV7L8tI/s9EBRAux9rxClVgSGTA3YZBc9ccVC O9ZQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date :arc-authentication-results; bh=uRHJ1K0esUfanlhmoXHvIbqQVKYezhOg8zArKG2Yzrk=; b=PP8UiN5ZvK8hE4z0jQcjqjECeB/9Gks7mUBKEFAnufo+KDyICJWkKUALfqsM333LP1 op/okTZuWUoQJ3Nv1AgEqUca5K8Ljz7y5wNGDF3qiffH5OuuVujOtXhLbgORHbEURqNi ca2cyRp9CLrfH7BiH1LeY9iFvqaYB1dFKISoYDV7lxzIo1Wm9ZKWZGWCig6424Ik3I/3 JgnZDgr8mbSx1tvZpOdjCdiXvyQHF1trx/LRr2/yZp16p+0Nmd6v05jJo4e2M7VyXPAk G3yXLA4zXb0bCe4FVKGfE9PsYBTTfpkdhLXvAC4pdM/+2Y8KuR0ph7qOEaqNrWPRln4R mD5A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 63-v6si1699365pfg.67.2018.08.22.05.08.58; Wed, 22 Aug 2018 05:09:14 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729023AbeHVPJb (ORCPT + 99 others); Wed, 22 Aug 2018 11:09:31 -0400 Received: from Galois.linutronix.de ([146.0.238.70]:35947 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728791AbeHVPJb (ORCPT ); Wed, 22 Aug 2018 11:09:31 -0400 Received: from hsi-kbw-5-158-153-52.hsi19.kabel-badenwuerttemberg.de ([5.158.153.52] helo=nanos.tec.linutronix.de) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1fsRZ9-0005nl-A5; Wed, 22 Aug 2018 13:44:47 +0200 Date: Wed, 22 Aug 2018 13:44:44 +0200 (CEST) From: Thomas Gleixner To: Heiner Kallweit cc: David Miller , helgaas@kernel.org, jian-hong@endlessm.com, nic_swsd@realtek.com, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux@endlessm.com, linux-pci@vger.kernel.org, marc.zyngier@arm.com, hch@lst.de Subject: Re: [PATCH] r8169: don't use MSI-X on RTL8106e In-Reply-To: Message-ID: References: <20180820184438.GA154536@bhelgaas-glaptop.roam.corp.google.com> <9d7d960a-6c55-dc4b-7969-f5cf46bff0ce@gmail.com> <20180821.123108.89921430801253333.davem@davemloft.net> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 21 Aug 2018, Heiner Kallweit wrote: > On 21.08.2018 21:31, David Miller wrote: > > From: Heiner Kallweit > > Date: Mon, 20 Aug 2018 22:46:48 +0200 > > > >> I'm in contact with Realtek and according to them few chip versions > >> seem to clear MSI-X table entries on resume from suspend. Checking > >> with them how this could be fixed / worked around. > >> Worst case we may have to disable MSI-X in general. > > > > I worry that if the chip does this, and somehow MSI-X is enabled and > > an interrupt is generated, the chip will write to the cleared out > > MSI-X address. This will either write garbage into memory or cause > > a bus error and require PCI error recovery. > > > > It also looks like your test patch doesn't fix things for people who > > have tested it. > > > The test patch was based on the first info from Realtek which made me > think that the base address of the MSI-X table is cleared, what > obviously is not the case. > > After some further tests it seems that the solution isn't as simple > as storing the MSI-X table entries on suspend and restore them on > resume. On my system (where MSI-X works fine) MSI-X table entries > on resume are partially different from the ones on suspend. Which is not a surprise. Please don't try to fiddle with that at the driver level. The irq and PCI core code are the ones in charge and if you'd restore at the wrong point then hell breaks lose. Can you please do the following: 1) Store the PCI config space at suspend time 2) Compare the PCI config space at resume time and print the difference Do that on a working and a non-working version of Realtek NICs. Thanks, tglx