lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20180821.212423.615788696464102670.davem@davemloft.net>
Date:   Tue, 21 Aug 2018 21:24:23 -0700 (PDT)
From:   David Miller <davem@...emloft.net>
To:     jian-hong@...lessm.com
Cc:     hkallweit1@...il.com, steved424@...il.com, gogen@...root.org,
        netdev@...r.kernel.org, linux@...lessm.com
Subject: Re: Experimental fix for MSI-X issue on r8169

From: Jian-Hong Pan <jian-hong@...lessm.com>
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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ