netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Miller <davem@davemloft.net>
To: Ajit.Khaparde@Emulex.Com
Cc: netdev@vger.kernel.org
Subject: Re: [PATCH net-next] be2net: Ignore spurious UE indication from NIC
Date: Wed, 26 Sep 2012 19:33:06 -0400 (EDT)	[thread overview]
Message-ID: <20120926.193306.1775779573258392844.davem@davemloft.net> (raw)
In-Reply-To: <3BB8C5C6B04A1F4CBE5B241DA98A501E67EC7B@CMEXMB1.ad.emulex.com>

From: "Khaparde, Ajit" <Ajit.Khaparde@Emulex.Com>
Date: Wed, 26 Sep 2012 22:35:14 +0000

>> From: David Miller [davem@davemloft.net]
>> Sent: Friday, September 21, 2012 2:04 PM
>> To: Khaparde, Ajit
>> Cc: netdev@vger.kernel.org
>> Subject: Re: [PATCH net-next] be2net: Ignore spurious UE indication from NIC
>>
>> From: Ajit Khaparde <ajit.khaparde@emulex.com>
>> Date: Fri, 21 Sep 2012 11:36:20 -0500
>>
>>> Ignore spurious UE indication seen on some platforms.
>>> Consider the error as un-recoverable only when the bits
>>> stay high during second sampling.
>>>
>>> Signed-off-by: Ajit Khaparde <ajit.khaparde@emulex.com>
>>
>> Treating uncorrectable errors as spurious seems like an invitation
>> for hard to track down data corruption to me.
>>
>> You'll need to come up with a more sophisticated test for
>> spurious other than "happens more than once" before I'm willing
>> to subject the entire world to this kind of potential problem.
> 
> If the UE is real, then the hardware will stop responding to requests.
> The hardware block goes offline automatically and no traffic will flow.
> After this the hardware will generate a register dump, which can be
> retrived using ethtool.
> 
> A spurious UE or a data corruption will not generate this dump.
> 
> The detection logic is merely to inform the user about the failure
> and also avoid any further access to the NIC.

So it sounds more like the UE test should be removed completely
since you cannot rely upon it, and if a real UE happens the hardware
will stop and you will already report the problem when the hardware
block goes offline.

Furthermore, it also implies that you can test if the hardware block
is offline to validate the UE indication.

All of which says irrefutably that your patch is still the wrong way
to do this.

      reply	other threads:[~2012-09-26 23:33 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-21 16:36 [PATCH net-next] be2net: Ignore spurious UE indication from NIC Ajit Khaparde
2012-09-21 19:04 ` David Miller
2012-09-26 22:35   ` Khaparde, Ajit
2012-09-26 23:33     ` David Miller [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120926.193306.1775779573258392844.davem@davemloft.net \
    --to=davem@davemloft.net \
    --cc=Ajit.Khaparde@Emulex.Com \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).