On 12/21/2009 04:11 PM, Michael Buesch wrote: > On Monday 21 December 2009 23:02:39 Larry Finger wrote: >> On 12/21/2009 03:47 PM, Michael Buesch wrote: >>> On Monday 21 December 2009 22:31:10 Larry Finger wrote: >>>> Hi, >>>> >>>> I placed a number of test prints in my system trying to find where a >>>> DMA data error might occur. In doing so, I found that 3 slots in the >>>> DMA header cache cross a page boundary. Such a situation is allowed on >>>> my system, but it might be forbidden on Atom processors. Please try >>>> this really ugly hack to see if it makes any difference. >>> >>> First thing is that the DMA buffers are allowed to cross any boundary (and >>> the header is just a buffer). The boundary requirements only apply to the >>> memory holding the descriptors. >> >> That is what we will test for the Atom. I know it doesn't matter for >> my CPU, but ... > > I'm pretty sure the broadcom DMA engine is not _that_ braindead. > (It is pretty weird, but not _that_ weird). > It would effectively mean that we'd have to bouncebuffer _every_ TX packet.
I'm not that worried about the Broadcom implementation as I am about the support chips on the Netbooks. >>> Second thing is: How does the patch prevent a boundary crossing? >> >> The number of slots is reduced to the point that the header cache fits >> in one page, just as the RX header cache does. As I said, this is >> really ugly. If this fixes the problem, then a more elegant fix will >> be needed. > > But the allocation is not required to be aligned to the page start. > The first header might start at offset 4000 of a page, so you cross > the page border after the first few headers. Here, it was slot 74 that crossed the page boundary. At 110 bytes per every 2 slots, that works out to 4070 bytes for 0 - 73. From that, I infer that the cache starts on a page boundary. Larry _______________________________________________ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
