From mboxrd@z Thu Jan 1 00:00:00 1970 From: Heiner Kallweit Subject: Re: Experimental fix for MSI-X issue on r8169 Date: Wed, 22 Aug 2018 07:56:19 +0200 Message-ID: <185ed376-fadd-6358-5501-e13775bbab5f@gmail.com> References: <98df6b0a-44df-9c0d-ddf6-11b892ccd990@gmail.com> <20180821.212423.615788696464102670.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Cc: steved424@gmail.com, gogen@disroot.org, netdev@vger.kernel.org, linux@endlessm.com To: David Miller , jian-hong@endlessm.com Return-path: Received: from mail-wm0-f45.google.com ([74.125.82.45]:39905 "EHLO mail-wm0-f45.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726696AbeHVJ02 (ORCPT ); Wed, 22 Aug 2018 05:26:28 -0400 Received: by mail-wm0-f45.google.com with SMTP id q8-v6so942092wmq.4 for ; Tue, 21 Aug 2018 23:03:04 -0700 (PDT) In-Reply-To: <20180821.212423.615788696464102670.davem@davemloft.net> Content-Language: en-US Sender: netdev-owner@vger.kernel.org List-ID: On 22.08.2018 06:24, David Miller wrote: > From: Jian-Hong Pan > Date: Wed, 22 Aug 2018 11:01:02 +0800 > > ... >> [ 56.462464] r8169 0000:02:00.0: MSI-X entry: context resume: >> ffffffff ffffffff ffffffff ffffffff > ... >> uh! The MSI-X entry seems missed after resume on this laptop! > > Yeah, having all of the MSI-X entry values be all-1's is not a good > sign. > all-1's seems to indicate that PCI access to the MSI-X table BAR/region fails. Because falling back to MSI helps, accessing the other BAR/region with the memory-mapped registers works. I'll check with Realtek whether this symptom rings any bell. > But this is quite a curious set of debugging traces we now have. > > In the working case, the vector number in the DATA field seems > to change, which suggests that something is assigning new values > and programming them into these fields at resume time. > > But in the failing cases, all of the values are garbage. > > I would expect, given what the working trace looks like, that in the > failing case some values would be wrong and the DATA value would have > some new yet valid value. But that is not what we are seeing here. > > Weird. > >