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]

Date:	Thu, 27 Mar 2008 16:53:55 -0700
From:	"Kok, Auke" <auke-jan.h.kok@...el.com>
To:	Jeff Garzik <jeff@...zik.org>
CC:	"Brandeburg, Jesse" <jesse.brandeburg@...el.com>,
	David Miller <davem@...emloft.net>,
	e1000-devel@...ts.sourceforge.net, netdev@...r.kernel.org
Subject: Re: [PATCH] e1000e: test MSI interrupts

Jeff Garzik wrote:
> Brandeburg, Jesse wrote:
>> I get your point, but this seems a maintainance problem due to not being
>> able to "future proof" the solution.  I know what is (IDs) available
>> now, but I don't know how many systems in the future IBM will release
>> with a similar bridge but a different device ID that causes the same
>> issue.
> 
> Future-proofing in that way is a pipe dream.
> 
> You hope to predict what _errata_, what out-of-spec behavior future
> hardware will have.  Trying to code for such N^M possible futures will
> lead to code bloat, depression, and eventually madness.
> 
> 
>> Should we take on the maintenance of continually having to add
>> every new bridge device that has this issue to our driver?  Users just
>> want this stuff to work when they plug it in.
> 
> As David noted, we touch quirks.c all the time for various platform
> eccentricities.  Adding a new id is easy and takes two seconds.  The
> same ease of change applies to any driver-local list of ids, too.
> 
> Anyway, I think a better question to ask is:  should we bloat up every
> driver testing for platform quirks found on a minority of platforms?
> 
> Moreover, "it doesn't work" type errata is typically fixed in future
> chip generations -- making any such generic test /less/ valuable,
> because of the lower likelihood that IBM will continue to release this
> buggy hardware for decades.
> 
> We have an existing "this bridge and MSI don't get along" list.  Adding
> an id is a one-line patch.

well it's just slightly more complex than just that... the bridge works OK with
MSI for every device except 82571

so 82572, 82573 e1000's work fine as well as all the newer pci-e e1000's, or any
of the non-e1000 hardware that uses MSI interrupts.

so disabling MSI entirely for that chipset by quirking it is not what we want to
do in the first place.

hence the test :)

the only alternative I see is that we have a quirk in the e1000 driver that acts
when the combination of an 82571 and this particular chipset is found, but I have
no information ATM on the chipset id's yet and on how to identify this configuration.

Auke
--
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