linux-kernel - 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: <460B4BF2.1070803@roinet.com>
Date:	Thu, 29 Mar 2007 01:17:38 -0400
From:	David Acker <dacker@...net.com>
To:	"Kok, Auke" <auke-jan.h.kok@...el.com>
CC:	Lennert Buytenhek <buytenh@...tstofly.org>,
	Jeff Garzik <jeff@...zik.org>,
	Netdev List <netdev@...r.kernel.org>,
	Linux Kernel <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...l.org>,
	Russell King <rmk+lkml@....linux.org.uk>
Subject: Re: [RFT] e100 driver on ARM

Kok, Auke wrote:
> Lennert Buytenhek wrote:
>> On Mon, Sep 04, 2006 at 06:39:29AM -0400, Jeff Garzik wrote:
>>
>>> 1) Does e100 driver work on ARM?
>>
>> FWIW, e100 seems to work okay for me on an intel ixp2400 (xscale based)
>> board, an ixp2850 (xscale based) board and an ixp2350 (xscale3 based)
>> board.  ixp2350 works both with hardware coherency turned on (cpu
>> snoops bus) and turned off (manual dma cache clean/invalidate as usual.)
>>
>> As for the other ARM platforms that I'm interested in / have hardware
>> for / maintain, the at91/ep93xx/pxa270 don't have PCI, and the other
>> two (iop32x/iop33x) I can't test because I don't have such systems with
>> e100 NICs, but I expect those would work, since they're both xscale
>> based like the ixp2400, and the ixp2400 works.
> 
> I just got an iop342 board dropped on my lap. Once it's running, I'll 
> make sure to make this the first thing to test.
> 

I have a pxa255 based system with PCI added to it.  The e100 would have 
memory corruption in its receive buffers detected by slab debugging 
unless I put in the patch to use the S-bit.

Here is a link to the patch posting:
http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20-rc3/2.6.20-rc3-mm1/broken-out/git-netdev-all.patch
Search for e100.c.

http://www-gatago.com/linux/kernel/15457063.html - This discussion seems 
to hit the issue.

There appears to be a race on the cache line where the EL bit and the 
next packet info live. In my case the hardware appeared to write to a 
free packet.  The S-bit seems to make the hardware stop and spin on the 
bit, while the EL bit seems to let the hardware try to use that packet.

This race would occur less often when the receive buffer chain is always 
refilled before the hardware can use them up.  On our 400 Mhz Xscale, we 
can use up all 256 buffers if the PCI bus has another busy device on it. 
  In our case it is an 802.11g miniPCI card and our software was routing 
all ethernet packets to the wireless interface and vice versa while TCP 
streams were running accross these connections.
-Ack
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/