netdev - RE: [PATCH] e1000e: test MSI interrupts

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: <36D9DB17C6DE9E40B059440DB8D95F5204BF07F7@orsmsx418.amr.corp.intel.com>
Date:	Thu, 27 Mar 2008 10:53:43 -0700
From:	"Brandeburg, Jesse" <jesse.brandeburg@...el.com>
To:	"Kok, Auke-jan H" <auke-jan.h.kok@...el.com>,
	"Jeff Garzik" <jeff@...zik.org>
Cc:	<e1000-devel@...ts.sourceforge.net>, <netdev@...r.kernel.org>
Subject: RE: [PATCH] e1000e: test MSI interrupts

Kok, Auke wrote:
> Jeff Garzik wrote:
>> Auke Kok wrote:
>>> From: Jesse Brandeburg <jesse.brandeburg@...el.com>
>>> 
>>> Test the MSI interrupt physically once before assuming that it
>>> actually works. Several platforms have already come across that
>>> have non-functional MSI interrupts and this code will attempt
>>> to detect those safely. Once the test succeeds MSI interrupts
>>> will be enabled.
>>> 
>>> Signed-off-by: Jesse Brandeburg <jesse.brandeburg@...el.com>
>>> Signed-off-by: Auke Kok <auke-jan.h.kok@...el.com>

>> Ah, the perennial add-same-test-to-every-driver conundrum.
>> 
>> I think we are far enough along with MSI to _not_ do this anymore in
>> drivers. 

Actually, I'm hoping you'll allow this Jeff, we have a production system
(see below) we know about that doesn't like the way 82571 formats MSI
interrupt messages.  All other systems seem to be okay with this format
of MSI messages, but this system implemented a stricter interpretation
of the spec, and so even though that system doesn't need a quirk for MSI
because MSI works in general, we still MUST test the MSI vector to make
sure it works *for us*  In this case it comes down to being an errata
workaround.

Since there is no way to "test" generation of an interrupt from any
specific hardware device without internal knowledge of said device,
there isn't a way for us to help the kernel by writing a generic "test
MSI" routine.

I would prefer this "generic test" code be in the driver rather than
having to identify all the chipsets that fail and have the driver do
*specific chipset* detection ala bnx2.c's 8132 bridge workaround.

>> The platforms with MSI problems should be discovered, made public,
>> and worked around. 

This is our workaround, it is our fault, the incompatible chipset is in
an x3850 IBM system.

>> Otherwise you hide the same problem, just for someone else to
>> discover with another component of the machine.

We had avoided this test in the past based on your recommendation but in
this case I don't see a way around it, do you?  I'm open to other
suggestions but we need to solve the problem somehow in an *automated*
way.  IBM requested we do it this way.

Jesse
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html