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 netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
