[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4C2A8879.8010000@intel.com>
Date: Tue, 29 Jun 2010 16:57:45 -0700
From: Dan Williams <dan.j.williams@...el.com>
To: Chris Li <lkml@...isli.org>
CC: linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: BUG in drivers/dma/ioat/dma_v2.c:314
On 6/29/2010 4:20 PM, Chris Li wrote:
> On Mon, Jun 28, 2010 at 5:45 PM, Dan Williams<dan.j.williams@...el.com> 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
>> CONFIG_NET_DMA=n and CONFIG_ASYNC_TX_DMA=n.
>
> OK, with the patch it does not kernel panic any more.
>
> Here is the prink from ioatdma.
>
Thanks.
[..]
> 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??
--
Dan
View attachment "report-chainaddr.patch" of type "text/plain" (516 bytes)
Powered by blists - more mailing lists