SATA DMA problem (sata_uli)

SATA DMA problem (sata_uli)

[David Shirley]

Hi Chaps,

Basically I detected this problem because I added another drive to my
PCI SATA card, and now the system is running dog slow.

I tracked it down to one of the drives being forced into PIO4 mode
rather than UDMA mode; dmesg bits:

sata_nv 0000:00:0b.0: version 2.0
ACPI: PCI Interrupt Link [LSID] enabled at IRQ 11
PCI: setting IRQ 11 as level-triggered
ACPI: PCI Interrupt 0000:00:0b.0[A] -> Link [LSID] -> GSI 11 (level,
low) -> IRQ 11
PCI: Setting latency timer of device 0000:00:0b.0 to 64
ata1: SATA max UDMA/133 cmd 0x9F0 ctl 0xBF2 bmdma 0xE800 irq 11
ata2: SATA max UDMA/133 cmd 0x970 ctl 0xB72 bmdma 0xE808 irq 11
scsi0 : sata_nv
ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata1.00: ATA-7, max UDMA/133, 586072368 sectors: LBA48 NCQ (depth 0/32)
ata1.00: ata1: dev 0 multi count 16
ata1.00: configured for UDMA/133
scsi1 : sata_nv
ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata2.00: ATA-7, max UDMA/133, 586072368 sectors: LBA48 NCQ (depth 0/32)
ata2.00: ata2: dev 0 multi count 16
ata2.00: configured for UDMA/133
scsi 0:0:0:0: Direct-Access     ATA      ST3300831AS      3.06 PQ: 0 ANSI: 5
SCSI device sda: 586072368 512-byte hdwr sectors (300069 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: drive cache: write back
SCSI device sda: 586072368 512-byte hdwr sectors (300069 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: drive cache: write back
 sda: sda1 sda2
sd 0:0:0:0: Attached scsi disk sda
sd 0:0:0:0: Attached scsi generic sg0 type 0
scsi 1:0:0:0: Direct-Access     ATA      ST3300831AS      3.06 PQ: 0 ANSI: 5
SCSI device sdb: 586072368 512-byte hdwr sectors (300069 MB)
sdb: Write Protect is off
sdb: Mode Sense: 00 3a 00 00
SCSI device sdb: drive cache: write back
SCSI device sdb: 586072368 512-byte hdwr sectors (300069 MB)
sdb: Write Protect is off
sdb: Mode Sense: 00 3a 00 00
SCSI device sdb: drive cache: write back
 sdb: sdb1 sdb2
sd 1:0:0:0: Attached scsi disk sdb
sd 1:0:0:0: Attached scsi generic sg1 type 0
sata_uli 0000:01:06.0: version 1.0
ACPI: PCI Interrupt 0000:01:06.0[A] -> Link [LNK3] -> GSI 10 (level,
low) -> IRQ 10
ata3: SATA max UDMA/133 cmd 0x7000 ctl 0x7402 bmdma 0x8000 irq 10
ata4: SATA max UDMA/133 cmd 0x7800 ctl 0x7C02 bmdma 0x8008 irq 10
scsi2 : sata_uli
ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata3.00: ATA-7, max UDMA/133, 625142448 sectors: LBA48 NCQ (depth 0/32)
ata3.00: ata3: dev 0 multi count 16
ata3.00: configured for UDMA/133
scsi3 : sata_uli
ata4: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata4.00: ATA-7, max UDMA/133, 586072368 sectors: LBA48 NCQ (depth 0/32)
ata4.00: ata4: dev 0 multi count 16
ata4.00: simplex DMA is claimed by other device, disabling DMA
ata4.00: configured for PIO4
scsi 2:0:0:0: Direct-Access     ATA      ST3320620AS      3.AA PQ: 0 ANSI: 5
SCSI device sdc: 625142448 512-byte hdwr sectors (320073 MB)
sdc: Write Protect is off
sdc: Mode Sense: 00 3a 00 00
SCSI device sdc: drive cache: write back
SCSI device sdc: 625142448 512-byte hdwr sectors (320073 MB)
sdc: Write Protect is off
sdc: Mode Sense: 00 3a 00 00
SCSI device sdc: drive cache: write back
 sdc: sdc1 sdc2
sd 2:0:0:0: Attached scsi disk sdc
sd 2:0:0:0: Attached scsi generic sg2 type 0
scsi 3:0:0:0: Direct-Access     ATA      ST3300831AS      3.06 PQ: 0 ANSI: 5
SCSI device sdd: 586072368 512-byte hdwr sectors (300069 MB)
sdd: Write Protect is off
sdd: Mode Sense: 00 3a 00 00
SCSI device sdd: drive cache: write back
SCSI device sdd: 586072368 512-byte hdwr sectors (300069 MB)
sdd: Write Protect is off
sdd: Mode Sense: 00 3a 00 00
SCSI device sdd: drive cache: write back
 sdd: sdd1 sdd2
sd 3:0:0:0: Attached scsi disk sdd
sd 3:0:0:0: Attached scsi generic sg3 type 0

Why is ata4 reporting "simplex DMA is claimed by another device" and
how can I get it to work correctly?

Please let me know if you need more information.

Cheers
David

Re: SATA DMA problem (sata_uli)

[Alan]

> I tracked it down to one of the drives being forced into PIO4 mode
> rather than UDMA mode; dmesg bits:
> ata4.00: ATA-7, max UDMA/133, 586072368 sectors: LBA48 NCQ (depth 0/32)
> ata4.00: ata4: dev 0 multi count 16
> ata4.00: simplex DMA is claimed by other device, disabling DMA

Your ULi controller is reporting that it supports UDMA upon only one
channel at a time. The kernel is honouring this information. The older
ULi (was ALi) PATA devices report simplex but let you turn it off so see 
if the following does the trick. Test carefully as always with disk driver
changes.

(Jeff probably best to check the docs before merging this but I believe
it is sane)

Signed-off-by: Alan Cox <alan@redhat.com>

--- drivers/ata/sata_uli.c~	2006-12-13 10:53:58.848881256 +0000
+++ drivers/ata/sata_uli.c	2006-12-13 10:53:58.848881256 +0000
@@ -211,6 +211,8 @@
 	if (rc)
 		goto err_out_regions;
 
+	ata_pci_clear_simplex(pdev);
+
 	ppi[0] = ppi[1] = &uli_port_info;
 	probe_ent = ata_pci_init_native_mode(pdev, ppi, ATA_PORT_PRIMARY | ATA_PORT_SECONDARY);
 	if (!probe_ent) {

Re: SATA DMA problem (sata_uli)

[Jeff Garzik]

Alan wrote:
>> I tracked it down to one of the drives being forced into PIO4 mode
>> rather than UDMA mode; dmesg bits:
>> ata4.00: ATA-7, max UDMA/133, 586072368 sectors: LBA48 NCQ (depth 0/32)
>> ata4.00: ata4: dev 0 multi count 16
>> ata4.00: simplex DMA is claimed by other device, disabling DMA
> 
> Your ULi controller is reporting that it supports UDMA upon only one
> channel at a time. The kernel is honouring this information. The older
> ULi (was ALi) PATA devices report simplex but let you turn it off so see 
> if the following does the trick. Test carefully as always with disk driver
> changes.
> 
> (Jeff probably best to check the docs before merging this but I believe
> it is sane)
> 
> Signed-off-by: Alan Cox <alan@redhat.com>

My Uli SATA docs do not appear to cover the bmdma registers :(  Only the 
PCI config registers.

But regardless, I think the better fix is to never set ATA_HOST_SIMPLEX 
if ATA_FLAG_NO_LEGACY is set.

None of the SATA controllers I've ever encountered has been simplex.

	Jeff

Re: SATA DMA problem (sata_uli)

[Tejun Heo]

Jeff Garzik wrote:
> Alan wrote:
>>> I tracked it down to one of the drives being forced into PIO4 mode
>>> rather than UDMA mode; dmesg bits:
>>> ata4.00: ATA-7, max UDMA/133, 586072368 sectors: LBA48 NCQ (depth 0/32)
>>> ata4.00: ata4: dev 0 multi count 16
>>> ata4.00: simplex DMA is claimed by other device, disabling DMA
>>
>> Your ULi controller is reporting that it supports UDMA upon only one
>> channel at a time. The kernel is honouring this information. The older
>> ULi (was ALi) PATA devices report simplex but let you turn it off so
>> see if the following does the trick. Test carefully as always with
>> disk driver
>> changes.
>>
>> (Jeff probably best to check the docs before merging this but I believe
>> it is sane)
>>
>> Signed-off-by: Alan Cox <alan@redhat.com>
> 
> My Uli SATA docs do not appear to cover the bmdma registers :(  Only the
> PCI config registers.
> 
> But regardless, I think the better fix is to never set ATA_HOST_SIMPLEX
> if ATA_FLAG_NO_LEGACY is set.
> 
> None of the SATA controllers I've ever encountered has been simplex.

Just another data point.  The same problem is reported by bug #7590.

http://bugzilla.kernel.org/show_bug.cgi?id=7590

Is somebody brewing a patch?

-- 
tejun

Re: SATA DMA problem (sata_uli)

[Jeff Garzik]

Tejun Heo wrote:
> Jeff Garzik wrote:
>> Alan wrote:
>>>> I tracked it down to one of the drives being forced into PIO4 mode
>>>> rather than UDMA mode; dmesg bits:
>>>> ata4.00: ATA-7, max UDMA/133, 586072368 sectors: LBA48 NCQ (depth 0/32)
>>>> ata4.00: ata4: dev 0 multi count 16
>>>> ata4.00: simplex DMA is claimed by other device, disabling DMA
>>> Your ULi controller is reporting that it supports UDMA upon only one
>>> channel at a time. The kernel is honouring this information. The older
>>> ULi (was ALi) PATA devices report simplex but let you turn it off so
>>> see if the following does the trick. Test carefully as always with
>>> disk driver
>>> changes.
>>>
>>> (Jeff probably best to check the docs before merging this but I believe
>>> it is sane)
>>>
>>> Signed-off-by: Alan Cox <alan@redhat.com>
>> My Uli SATA docs do not appear to cover the bmdma registers :(  Only the
>> PCI config registers.
>>
>> But regardless, I think the better fix is to never set ATA_HOST_SIMPLEX
>> if ATA_FLAG_NO_LEGACY is set.
>>
>> None of the SATA controllers I've ever encountered has been simplex.
> 
> Just another data point.  The same problem is reported by bug #7590.
> 
> http://bugzilla.kernel.org/show_bug.cgi?id=7590
> 
> Is somebody brewing a patch?

Not to my knowledge.  Did you just volunteer?  ;-)

/me runs...

	Jeff

Re: SATA DMA problem (sata_uli)

[Tejun Heo]

Jeff Garzik wrote:
> Tejun Heo wrote:
>> Jeff Garzik wrote:
>>> Alan wrote:
>>>>> I tracked it down to one of the drives being forced into PIO4 mode
>>>>> rather than UDMA mode; dmesg bits:
>>>>> ata4.00: ATA-7, max UDMA/133, 586072368 sectors: LBA48 NCQ (depth
>>>>> 0/32)
>>>>> ata4.00: ata4: dev 0 multi count 16
>>>>> ata4.00: simplex DMA is claimed by other device, disabling DMA
>>>> Your ULi controller is reporting that it supports UDMA upon only one
>>>> channel at a time. The kernel is honouring this information. The older
>>>> ULi (was ALi) PATA devices report simplex but let you turn it off so
>>>> see if the following does the trick. Test carefully as always with
>>>> disk driver
>>>> changes.
>>>>
>>>> (Jeff probably best to check the docs before merging this but I believe
>>>> it is sane)
>>>>
>>>> Signed-off-by: Alan Cox <alan@redhat.com>
>>> My Uli SATA docs do not appear to cover the bmdma registers :(  Only the
>>> PCI config registers.
>>>
>>> But regardless, I think the better fix is to never set ATA_HOST_SIMPLEX
>>> if ATA_FLAG_NO_LEGACY is set.
>>>
>>> None of the SATA controllers I've ever encountered has been simplex.
>>
>> Just another data point.  The same problem is reported by bug #7590.
>>
>> http://bugzilla.kernel.org/show_bug.cgi?id=7590
>>
>> Is somebody brewing a patch?
> 
> Not to my knowledge.  Did you just volunteer?  ;-)
> 
> /me runs...

I'm just gonna ack Alan's patch.

* ATA_FLAG_NO_LEGACY is not really used widely (and thus LLDs don't set
it rigorously).  I think it should be removed once we get initialization
model right.

* I'm really reluctant to add more LLD-specific knowledge into libata
core.  We're already carrying too much due to the current init model
(libata should initialize host according to probe_ent, so many
weirdities should be represented in probe_ent in a form libata core
understands).

* The idea of clearing simplex for unknown controllers scares the hell
out of me.  where's mummy...

So, I'll ask bug reporter of #7590 to test it.

-- 
tejun

Re: SATA DMA problem (sata_uli)

[Tejun Heo]

Tejun Heo wrote:
> I'm just gonna ack Alan's patch.
> 
> * ATA_FLAG_NO_LEGACY is not really used widely (and thus LLDs don't set
> it rigorously).  I think it should be removed once we get initialization
> model right.
> 
> * I'm really reluctant to add more LLD-specific knowledge into libata
> core.  We're already carrying too much due to the current init model
> (libata should initialize host according to probe_ent, so many
> weirdities should be represented in probe_ent in a form libata core
> understands).
> 
> * The idea of clearing simplex for unknown controllers scares the hell
> out of me.  where's mummy...
> 
> So, I'll ask bug reporter of #7590 to test it.

Aieee... uli sata controller doesn't allow simplex bit to be cleared.

http://bugzilla.kernel.org/show_bug.cgi?id=7590#c31

I'll post ATA_FLAG_IGN_SIMPLEX patch soon.

-- 
tejun