linux-kernel - Re: 2.6.32-rc2: Intel(R) I/OAT DMA Engine init failed

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <e9c3a7c20910121848u69e0a225t1eb03c43e011ebb2@mail.gmail.com>
Date:	Mon, 12 Oct 2009 18:48:34 -0700
From:	Dan Williams <dan.j.williams@...el.com>
To:	Alexander Beregalov <a.beregalov@...il.com>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	"Sosnowski, Maciej" <maciej.sosnowski@...el.com>
Subject: Re: 2.6.32-rc2: Intel(R) I/OAT DMA Engine init failed

On Tue, Oct 6, 2009 at 3:54 AM, Alexander Beregalov
<a.beregalov@...il.com> wrote:
> but when I commented DEBUG definition, it failed again:
>
> ioatdma: Intel(R) QuickData Technology Driver 4.00
> ioatdma 0000:00:08.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
> ioatdma 0000:00:08.0: setting latency timer to 64
>  alloc irq_desc for 33 on node -1
>  alloc kstat_irqs on node -1
> ioatdma 0000:00:08.0: irq 33 for MSI/MSI-X
> ioatdma 0000:00:08.0: Self-test copy timed out, disabling 0:0
> ioatdma 0000:00:08.0: Intel(R) I/OAT DMA Engine init failed
> ioatdma 0000:00:08.0: PCI INT A disabled

Odd, it looks like neither a dma channel interrupt nor the timer fired
while this operation was in flight.  However, when you turn on debug
we see timer events firing as expected (ioat1_timer_event).  The
operation completes successfully ( dma->device_is_tx_complete returns
DMA_SUCCESS), but its not clear what is causing us to violate the
timeout.  Before bisecting can you try commit 1f6672d4?  This is the
state of the aysnc_tx.git tree before it was merged for 2.6.32.  If
that fails then a full bisect is the only recourse I can see to get
closer to root cause.

Thanks,
Dan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/