Re: Attansic L1 page corruption (was: 2.6.22-rc5: pdflush oops under heavy disk load)
On 6/25/07, Jay L. T. Cornwall <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Attansic L1 page corruption
Jay L. T. Cornwall 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. If there's any other patches you'd like me to test or traces to capture, I'm happy to help out. Otherwise I'll run with this one for now since it does the job! Okay Jay, thanks. Luca, would you please submit your patch to Jeff Garzik and netdev? Jay - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Attansic L1 page corruption (was: 2.6.22-rc5: pdflush oops under heavy disk load)
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. If there's any other patches you'd like me to test or traces to capture, I'm happy to help out. Otherwise I'll run with this one for now since it does the job! Thanks. -- Jay L. T. Cornwall, http://www.esuna.co.uk/~jay/ PhD Student Imperial College London - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Attansic L1 page corruption (was: 2.6.22-rc5: pdflush oops under heavy disk load)
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. If there's any other patches you'd like me to test or traces to capture, I'm happy to help out. Otherwise I'll run with this one for now since it does the job! Thanks. -- Jay L. T. Cornwall, http://www.esuna.co.uk/~jay/ PhD Student Imperial College London - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Attansic L1 page corruption
Jay L. T. Cornwall 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. If there's any other patches you'd like me to test or traces to capture, I'm happy to help out. Otherwise I'll run with this one for now since it does the job! Okay Jay, thanks. Luca, would you please submit your patch to Jeff Garzik and netdev? Jay - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Attansic L1 page corruption (was: 2.6.22-rc5: pdflush oops under heavy disk load)
On 6/25/07, Jay L. T. Cornwall [EMAIL PROTECTED] 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
