From: "Kok, Auke" <auke-jan.h.kok@intel.com>
To: Andy Gospodarek <andy@greyhouse.net>
Cc: "Brandeburg, Jesse" <jesse.brandeburg@intel.com>,
Jeff Garzik <jeff@garzik.org>,
e1000-devel@lists.sourceforge.net, netdev@vger.kernel.org
Subject: Re: [PATCH] e1000e: test MSI interrupts
Date: Thu, 27 Mar 2008 15:16:41 -0700 [thread overview]
Message-ID: <47EC1CC9.5080305@intel.com> (raw)
In-Reply-To: <20080327220527.GO856@gospo.usersys.redhat.com>
Andy Gospodarek wrote:
> On Thu, Mar 27, 2008 at 10:53:43AM -0700, Brandeburg, Jesse wrote:
>> Kok, Auke wrote:
>>> Jeff Garzik wrote:
>>>> Auke Kok wrote:
>>>>> From: Jesse Brandeburg <jesse.brandeburg@intel.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@intel.com>
>>>>> Signed-off-by: Auke Kok <auke-jan.h.kok@intel.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.
>>
>
> I've seem similar problems on other systems, so this would be a nice bit
> of code to have somewhere. I can see Jeff's argument for having this
> outside of drivers, but to make my life easier I'd like to see this in
> e1000e (and e1000!). :-)
e1000 will soon no longer support PCI Express devices, so this is unneeded.
> I suppose an more general alternative would be to make this code run as
> an ethtool test (current or new one) and then have a module option to
> disable/enable MSI so all could be done in userspace, but something
> automatic like this sure would be great.
a lot of work ...
next prev parent reply other threads:[~2008-03-27 22:16 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-26 18:36 [PATCH] e1000e: test MSI interrupts Auke Kok
2008-03-26 18:42 ` Jeff Garzik
2008-03-26 20:42 ` [E1000-devel] " Kok, Auke
2008-03-27 17:53 ` Brandeburg, Jesse
2008-03-27 19:43 ` Jeff Garzik
2008-03-27 22:05 ` David Miller
2008-03-27 22:55 ` Brandeburg, Jesse
2008-03-27 23:06 ` David Miller
2008-03-27 23:38 ` Jeff Garzik
2008-03-27 23:53 ` Kok, Auke
2008-03-28 0:03 ` David Miller
2008-03-27 21:59 ` David Miller
2008-03-27 22:05 ` Andy Gospodarek
2008-03-27 22:16 ` Kok, Auke [this message]
2008-03-27 22:33 ` Andy Gospodarek
2008-03-27 22:47 ` Kok, Auke
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=47EC1CC9.5080305@intel.com \
--to=auke-jan.h.kok@intel.com \
--cc=andy@greyhouse.net \
--cc=e1000-devel@lists.sourceforge.net \
--cc=jeff@garzik.org \
--cc=jesse.brandeburg@intel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.