From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Miller Subject: Re: Experimental fix for MSI-X issue on r8169 Date: Tue, 21 Aug 2018 21:24:23 -0700 (PDT) Message-ID: <20180821.212423.615788696464102670.davem@davemloft.net> References: <98df6b0a-44df-9c0d-ddf6-11b892ccd990@gmail.com> Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: hkallweit1@gmail.com, steved424@gmail.com, gogen@disroot.org, netdev@vger.kernel.org, linux@endlessm.com To: jian-hong@endlessm.com Return-path: Received: from shards.monkeyblade.net ([23.128.96.9]:50036 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726676AbeHVHrb (ORCPT ); Wed, 22 Aug 2018 03:47:31 -0400 In-Reply-To: Sender: netdev-owner@vger.kernel.org List-ID: 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. 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.