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  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, 29 Mar 2007 01:17:38 -0400
From:	David Acker <>
To:	"Kok, Auke" <>
CC:	Lennert Buytenhek <>,
	Jeff Garzik <>,
	Netdev List <>,
	Linux Kernel <>,
	Andrew Morton <>,
	Russell King <>
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:
Search for e100.c. - 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.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists