Re: BUG in drivers/dma/ioat/dma_v2.c:314

From: Dan Williams
Date: Tue Jun 29 2010 - 19:57:52 EST

On 6/29/2010 4:20 PM, Chris Li wrote:
On Mon, Jun 28, 2010 at 5:45 PM, Dan Williams<dan.j.williams@xxxxxxxxx> wrote:
Looks like that dev_err() did not make it to the console. The attached
patch should get us some more debug information. This will stop the driver
from making forward progress (applies to current -git). I suspect this may
be triggering from the driver self test, but to be safe you should set

OK, with the patch it does not kernel panic any more.

Here is the prink from ioatdma.


0000:00:0f.0: ioat2_timer_event: Channel halted (10)

This says that we got an invalid chain address error when trying to start the engine. If there was a driver problem with init I would have expected to see reports from other systems. The attached patch will print out what chain address we are setting. The hardware expects a 64-byte aligned address which should be guaranteed by the use of pci_pool_alloc().

However, if you are up for another experiment, I'd like to see what happens if you disable VT-d. Maybe it is a misconfigured iommu table that is blocking the engine's access to memory?

I attach the full dmesg in case you need it. Is it possible that
the Mac Pro is MSI only and ioatdma is not happy about that?

Not really, MSI is the preferred mode of operation, and as I said earlier if something like this were broken I would expect reports from other platforms??

diff --git a/drivers/dma/ioat/dma_v2.h b/drivers/dma/ioat/dma_v2.h
index a2c413b..47ab35e 100644
--- a/drivers/dma/ioat/dma_v2.h
+++ b/drivers/dma/ioat/dma_v2.h
@@ -149,6 +149,8 @@ static inline void ioat2_set_chainaddr(struct ioat2_dma_chan *ioat, u64 addr)
struct ioat_chan_common *chan = &ioat->base;

+ dev_info(to_dev(chan), "%s: chainaddr: %llx\n", __func__,
+ (unsigned long long) addr);
writel(addr & 0x00000000FFFFFFFF,
chan->reg_base + IOAT2_CHAINADDR_OFFSET_LOW);
writel(addr >> 32,