linux-kernel - RE: ioatdma Self-test copy timeout

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]

Date:	Tue, 19 Feb 2008 10:59:09 -0800
From:	"Nelson, Shannon" <shannon.nelson@...el.com>
To:	"Tomas Hlavacek" <brill@...ove.cz>, <linux-kernel@...r.kernel.org>,
	"Sosnowski, Maciej" <maciej.sosnowski@...el.com>
Subject: RE: ioatdma Self-test copy timeout

>-----Original Message-----
>From: Tomas Hlavacek [mailto:brill@...ove.cz] 
>Sent: Sunday, February 17, 2008 6:22 PM
>To: Nelson, Shannon; linux-kernel@...r.kernel.org
>Subject: ioatdma Self-test copy timeout
>
>Short description: In 2.6.25-rc2 ioatdma driver fails to 
>initialize due 
>to Self-test timeout when the ioatdma is linked into the kernel.
>
>
>Long descr: When I select to compile ioatdma into the kernel I get:
>
>ACPI: PCI Interrupt 0000:00:08.0[A] -> GSI 16 (level, low) -> IRQ 16
>PCI: Setting latency timer of device 0000:00:08.0 to 64
>ioatdma 0000:00:08.0: Intel(R) I/OAT DMA Engine found, 4 channels, 
>device version 0x12, driver version 2.04
>ioatdma: ioat_dma_test_callback(0000000000008086)
>ioatdma 0000:00:08.0: Self-test copy timed out, disabling
>ioatdma 0000:00:08.0: Intel(R) I/OAT DMA Engine initialization failed
>ACPI: PCI interrupt for device 0000:00:08.0 disabled
>
>As a kernel module ioatdma initializes just fine with the same 
>kernel on 
>the same HW without any other changes than selecting it to be 
>a module. 
>And it also succeeded to initialize when i tried to do this:
>
>--- a/drivers/dma/ioat_dma.c    2008-02-17 01:52:19.000000000 +0100
>+++ b/drivers/dma/ioat_dma.c    2008-02-18 02:47:27.000000000 +0100
>@@ -1089,7 +1089,7 @@
>                goto free_resources;
>        }
>        device->common.device_issue_pending(dma_chan);
>-       msleep(1);
>+       msleep(100);
> 
>        if (device->common.device_is_tx_complete(dma_chan, 
>cookie, NULL, 
>NULL)
>                                        != DMA_SUCCESS) {

Hmmm - interesting.  I'm not good enough with the kernel startup
sequence to know what it might be waiting for.  I don't see any problem
with a longer wait other than perhaps delaying the kernel startup.  We
left it a module and never really worked with it linked into the kernel,
primarily because its performance can be dependant on the work load, and
some folks will want the flexibility that a module gives.  We didn't let
it autoload at boot time for a similar reason.

If you want it to autoload at boot, you might want to add a modprobe
command to an init script.

sln
--
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/