ioatdma Self-test copy timeout

ioatdma Self-test copy timeout

[Tomas Hlavacek]

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) {


My lspci:
00:00.0 Host bridge: Intel Corporation 5000P Chipset Memory Controller 
Hub (rev b1)
00:02.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI Express x8 
Port 2-3 (rev b1)
00:04.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI Express x8 
Port 4-5 (rev b1)
00:06.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI Express x8 
Port 6-7 (rev b1)
00:08.0 System peripheral: Intel Corporation 5000 Series Chipset DMA 
Engine (rev b1)
00:10.0 Host bridge: Intel Corporation 5000 Series Chipset FSB Registers 
(rev b1)
00:10.1 Host bridge: Intel Corporation 5000 Series Chipset FSB Registers 
(rev b1)
00:10.2 Host bridge: Intel Corporation 5000 Series Chipset FSB Registers 
(rev b1)
00:11.0 Host bridge: Intel Corporation 5000 Series Chipset Reserved 
Registers (rev b1)
00:13.0 Host bridge: Intel Corporation 5000 Series Chipset Reserved 
Registers (rev b1)
00:15.0 Host bridge: Intel Corporation 5000 Series Chipset FBD Registers 
(rev b1)
00:16.0 Host bridge: Intel Corporation 5000 Series Chipset FBD Registers 
(rev b1)
00:1d.0 USB Controller: Intel Corporation 631xESB/632xESB/3100 Chipset 
UHCI USB Controller #1 (rev 09)
00:1d.1 USB Controller: Intel Corporation 631xESB/632xESB/3100 Chipset 
UHCI USB Controller #2 (rev 09)
00:1d.2 USB Controller: Intel Corporation 631xESB/632xESB/3100 Chipset 
UHCI USB Controller #3 (rev 09)
00:1d.7 USB Controller: Intel Corporation 631xESB/632xESB/3100 Chipset 
EHCI USB2 Controller (rev 09)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev d9)
00:1f.0 ISA bridge: Intel Corporation 631xESB/632xESB/3100 Chipset LPC 
Interface Controller (rev 09)
00:1f.1 IDE interface: Intel Corporation 631xESB/632xESB IDE Controller 
(rev 09)
00:1f.3 SMBus: Intel Corporation 631xESB/632xESB/3100 Chipset SMBus 
Controller (rev 09)
01:00.0 PCI bridge: Intel Corporation 6311ESB/6321ESB PCI Express 
Upstream Port (rev 01)
01:00.3 PCI bridge: Intel Corporation 6311ESB/6321ESB PCI Express to 
PCI-X Bridge (rev 01)
02:00.0 PCI bridge: Intel Corporation 6311ESB/6321ESB PCI Express 
Downstream Port E1 (rev 01)
02:01.0 PCI bridge: Intel Corporation 6311ESB/6321ESB PCI Express 
Downstream Port E2 (rev 01)
02:02.0 PCI bridge: Intel Corporation 6311ESB/6321ESB PCI Express 
Downstream Port E3 (rev 01)
05:00.0 Ethernet controller: Intel Corporation 80003ES2LAN Gigabit 
Ethernet Controller (Copper) (rev 01)
05:00.1 Ethernet controller: Intel Corporation 80003ES2LAN Gigabit 
Ethernet Controller (Copper) (rev 01)
07:00.0 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet 
Controller (rev 06)
07:00.1 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet 
Controller (rev 06)
09:01.0 VGA compatible controller: ATI Technologies Inc ES1000 (rev 02)

I placed my full dmesg output here: 
http://manwe.elfove.cz/~brill/tmp/dmesg-2.6.25-rc2

-- 
Tomas Hlavacek <brill@elfove.cz>

RE: ioatdma Self-test copy timeout

[Nelson, Shannon]

>-----Original Message-----
>From: Tomas Hlavacek [mailto:brill@elfove.cz] 
>Sent: Sunday, February 17, 2008 6:22 PM
>To: Nelson, Shannon; linux-kernel@vger.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