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, 29 Mar 2007 10:10:41 -0400
From:	lsorense@...lub.uwaterloo.ca (Lennart Sorensen)
To:	David Acker <dacker@...net.com>
Cc:	"Kok, Auke" <auke-jan.h.kok@...el.com>,
	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

On Thu, Mar 29, 2007 at 01:17:38AM -0400, David Acker wrote:
> 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.

Which PCI host controller are you using with the PXA255?  We tried using
a PXA255 based system with a PCI controller a couple of years ago and
have to change to a different cpu in the end due to the PCI controller
simply not being valid PCI.  The PXA255 wasn't designed for PCI, and I
get the impression that non of the PCI companion chips for it do a good
enough job to actually add it correctly.

--
Len Sorensen
-
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ