netdev - Re: [RFT] e100 driver on ARM

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: <4630C7D0.8030901@intel.com>
Date:	Thu, 26 Apr 2007 08:40:00 -0700
From:	"Kok, Auke" <auke-jan.h.kok@...el.com>
To:	Jeff Garzik <jeff@...zik.org>, Andrew Morton <akpm@...l.org>,
	Jesse Brandeburg <jesse.brandeburg@...el.com>
CC:	Lennert Buytenhek <buytenh@...tstofly.org>,
	David Acker <dacker@...net.com>,
	Lennart Sorensen <lsorense@...lub.uwaterloo.ca>,
	"Kok, Auke" <auke-jan.h.kok@...el.com>,
	Netdev List <netdev@...r.kernel.org>,
	Linux Kernel <linux-kernel@...r.kernel.org>,
	Russell King <rmk+lkml@....linux.org.uk>
Subject: Re: [RFT] e100 driver on ARM

Jeff Garzik wrote:
> Lennert Buytenhek wrote:
>> This is all a while ago now, but wasn't the e100 S-bit patch originally
>> written by Intel people in response to the very same quote by Russell
>> King that you've quoted above?
> 
> Correct.
> 
> I just wanted to make sure it didn't kill any boxes.

Neither did we. On top of that we didn't have the equipment to test on ARM on 
until recently, and the system that I got recently will not even load the kernel 
with an e100 NIC in the PCI slot (way way way before e100.ko loads, e1000 works 
just fine). that doesn't help either.

Meanwhile we've not sat still and jesse wrote a patch to have e100 use IO 
optionally for plagued platforms which seems to fix some of these issues, and 
Jeff Kirsher has been actively tracking a e100 IPMI issue on a very specific 
platform.

Jeff, I think I should just push the IO patch and the sbit code to Andrew and 
have it sit there. That is a vastly larger test resource than we currently can 
generate for this. If needed we just let is sit there for a whole release cycle 
before moving it to #upstream.

seems like a good idea, right?

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