Messages in this thread | | | Date | Mon, 25 Jun 2007 14:58:14 +0200 | From | Luca <> | Subject | Re: Attansic L1 page corruption (was: 2.6.22-rc5: pdflush oops under heavy disk load) |
| |
On 6/25/07, Jay L. T. Cornwall <jay@esuna.co.uk> wrote: > Jay Cliburn wrote: > > > For reasons not yet clear to me, it appears the L1 driver has a bug or > > the device itself has trouble with DMA in high memory. This patch, > > drafted by Luca Tettamanti, is being explored as a workaround. I'd be > > interested to know if it fixes your problem. > > Yes, it certainly seems to. Now running with this patch and 4GB active, > I've transferred about 15GB with no problem so far. It usually oopses > after a GB or two. > > I guess it's not an ideal solution, architecturally speaking, but it's a > good deal better than an unstable driver.
It may cause a "bounce" (i.e. data is copied to another buffer in lower memory) when a skb is allocated in high memory. Furthermore - at least on AMD systems - it should be possible to use the IOMMU to remap the memory to a bus address < 4GB.
Xiong can you comment on this issue? To recap: users are seeing hard locks when L1 driver does a DMA to/from a high memory area (physical address > 4GB). Limiting DMA to the lower 4GB with:
pci_set_dma_mask(pdev, DMA_32BIT_MASK);
cures the issue. Does L1 have any know problem decoding 64 addresses?
Luca - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |