[RFC] ata/core: don't enable the interrupt while activating the host

[RFC] ata/core: don't enable the interrupt while activating the host

[Sebastian Andrzej Siewior]

I just migrated from ide_platform to pata_platform on my Swarm/Mips
board. This resulted in "nobody cared" during request_irq().
The only difference I noticed between ATA and IDE before registering the
interrupt handler is that IDE does not enable the interrupt.
After removing the flag it looks like the controller is working with the
ATA layer.

If I flip the polarity of the interrupt, I see the "nobody cared"
message shortly after seeing ata_sff_softreset() during boot. So I tried
to perform the software reset with ATA_SRST before requesting the
interrupt hoping that it makes interrupt go away. It did not so.

Does anyone have an idea what might go wrong here?

Signed-off-by: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
---
 drivers/ata/libata-core.c |    7 +++++++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 6728328..8484223 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -6274,6 +6274,13 @@ int ata_host_activate(struct ata_host *host, int irq,
 		return ata_host_register(host, sht);
 	}
 
+	for (i = 0; i < host->n_ports; i++) {
+		struct ata_port *ap;
+
+		ap = host->ports[i];
+		iowrite8(ap->ctl & ~ATA_NIEN, ap->ioaddr.ctl_addr);
+	}
+
 	rc = devm_request_irq(host->dev, irq, irq_handler, irq_flags,
 			      dev_driver_string(host->dev), host);
 	if (rc)
-- 
1.6.6

Re: [RFC] ata/core: don't enable the interrupt while activating the host

[Tejun Heo]

Hello,

On 03/12/2010 07:04 AM, Sebastian Andrzej Siewior wrote:
> I just migrated from ide_platform to pata_platform on my Swarm/Mips
> board. This resulted in "nobody cared" during request_irq().
> The only difference I noticed between ATA and IDE before registering the
> interrupt handler is that IDE does not enable the interrupt.
> After removing the flag it looks like the controller is working with the
> ATA layer.
> 
> If I flip the polarity of the interrupt, I see the "nobody cared"
> message shortly after seeing ata_sff_softreset() during boot. So I tried
> to perform the software reset with ATA_SRST before requesting the
> interrupt hoping that it makes interrupt go away. It did not so.
> 
> Does anyone have an idea what might go wrong here?

ata_host_start() calls ata_eh_freeze_port() on each port which is
supposed to block the IRQs.  For pata_platform, the callback is
libata-sff.c::ata_sff_freeze() which does all that's necessary.  Can
you please play with ata_sff_freeze() and find out why it's not
working?

Thanks.

-- 
tejun

Re: [RFC] ata/core: don't enable the interrupt while activating the host

[Sebastian Andrzej Siewior]

* Tejun Heo | 2010-03-25 09:30:25 [+0900]:

>ata_host_start() calls ata_eh_freeze_port() on each port which is
>supposed to block the IRQs.  For pata_platform, the callback is
>libata-sff.c::ata_sff_freeze() which does all that's necessary.  Can
>you please play with ata_sff_freeze() and find out why it's not
>working?
I've been there. I've moved the functions around and nothing changed.
After removing the ATA_NIEN bit it started working. So it looks like
->sff_check_status() & ->sff_irq_clear() are not clearing the interrupt
for what reason ever.
Right now I belive that the firmware is doing something with the chip.
Is it possible to reset the chip to its power-on state?
ata_bus_softreset() did not help. Maybe I find something when I dig
through the firmware code....

>Thanks.

Sebastian

Re: [RFC] ata/core: don't enable the interrupt while activating the host

[Tejun Heo]

Hello,

On 03/26/2010 07:04 AM, Sebastian Andrzej Siewior wrote:
>> Can you please play with ata_sff_freeze() and find out why it's not
>> working?
> I've been there. I've moved the functions around and nothing changed.
> After removing the ATA_NIEN bit it started working. So it looks like
> ->sff_check_status() & ->sff_irq_clear() are not clearing the interrupt
> for what reason ever.

What happens if you remove everything else from the function and just
set ATA_NIEN?

Thanks.

-- 
tejun

Re: [RFC] ata/core: don't enable the interrupt while activating the host

[Sebastian Andrzej Siewior]

* Tejun Heo | 2010-03-26 08:54:54 [+0900]:

>Hello,
Hello,

sorry for the delay.

>On 03/26/2010 07:04 AM, Sebastian Andrzej Siewior wrote:
>>> Can you please play with ata_sff_freeze() and find out why it's not
>>> working?
>> I've been there. I've moved the functions around and nothing changed.
>> After removing the ATA_NIEN bit it started working. So it looks like
>> ->sff_check_status() & ->sff_irq_clear() are not clearing the interrupt
>> for what reason ever.
>
>What happens if you remove everything else from the function and just
>set ATA_NIEN?

removing everything from ata_sff_freeze() makes the interrupt storm go
away.
Leaving
- ap->ctl |= ATA_NIEN;
  => seems to work
- the upper and "ap->last_ctl = ap->ctl;"
  => seems to work
- the upper and "iowrite8(ap->ctl, ioaddr->ctl_addr);"
  => irq storm on request irq.

ata_sff_check_status() does not report ATA_DRQ set so I don't know why
the interrupt is comming.

>Thanks.
>
Sebastian

Re: [RFC] ata/core: don't enable the interrupt while activating the host

[Sergei Shtylyov]

Hello.

Sebastian Andrzej Siewior wrote:

>> On 03/26/2010 07:04 AM, Sebastian Andrzej Siewior wrote:
>>     
>>>> Can you please play with ata_sff_freeze() and find out why it's not
>>>> working?
>>>>         
>>> I've been there. I've moved the functions around and nothing changed.
>>> After removing the ATA_NIEN bit it started working. So it looks like
>>> ->sff_check_status() & ->sff_irq_clear() are not clearing the interrupt
>>> for what reason ever.
>>>       
>> What happens if you remove everything else from the function and just
>> set ATA_NIEN?
>>     
>
> removing everything from ata_sff_freeze() makes the interrupt storm go
> away.
> Leaving
> - ap->ctl |= ATA_NIEN;
>   => seems to work
> - the upper and "ap->last_ctl = ap->ctl;"
>   => seems to work
> - the upper and "iowrite8(ap->ctl, ioaddr->ctl_addr);"
>   => irq storm on request irq.
>
> ata_sff_check_status() does not report ATA_DRQ set so I don't know why
> the interrupt is comming.
>   

   Perhaps the drive incorrectly triggers interrupt on setting the nIEN 
bit -- some drives are known to do this; there is a blacklist of such 
drives in the IDE core so that it avoids setting nIEN bit for them.

WBR, Sergei

Re: [RFC] ata/core: don't enable the interrupt while activating the host

[Tejun Heo]

On 04/06/2010 07:00 PM, Sergei Shtylyov wrote:
>> ata_sff_check_status() does not report ATA_DRQ set so I don't know why
>> the interrupt is comming.
> 
>   Perhaps the drive incorrectly triggers interrupt on setting the nIEN
> bit -- some drives are known to do this; there is a blacklist of such
> drives in the IDE core so that it avoids setting nIEN bit for them.

Arghh.... that stinks.  Maybe we should port the list over?  What is
the ATA device in question here?

-- 
tejun

Re: [RFC] ata/core: don't enable the interrupt while activating the host

[Sebastian Andrzej Siewior]

* Tejun Heo | 2010-04-07 06:56:10 [+0900]:

>On 04/06/2010 07:00 PM, Sergei Shtylyov wrote:
>>> ata_sff_check_status() does not report ATA_DRQ set so I don't know why
>>> the interrupt is comming.
>> 
>>   Perhaps the drive incorrectly triggers interrupt on setting the nIEN
>> bit -- some drives are known to do this; there is a blacklist of such
>> drives in the IDE core so that it avoids setting nIEN bit for them.
>
>Arghh.... that stinks.  Maybe we should port the list over?  What is
>the ATA device in question here?

[    1.257000] ata1.00: ATA-6: WDC WD1600PB-98FBA0, 15.05R15, max UDMA/100
[    1.264000] ata1.00: 312581808 sectors, multi 0: LBA48
[    1.269000] ata1.01: ATAPI: HL-DT-ST DVDRAM GSA-4081B, A100, max UDMA/33
[    1.335000] scsi 0:0:0:0: Direct-Access     ATA      WDC WD1600PB-98F 15.0 PQ: 0 ANSI: 5
[    1.387000] scsi 0:0:1:0: CD-ROM            HL-DT-ST DVDRAM GSA-4081B A100 PQ: 0 ANSI: 5

I try to unplug them later and see if the problem goes away once there
is no device.
I'm not really convinced that this the fault of the device. I just
booted the kernel that worked yesterday and I ended up in "no body
carred" irq storm. Hard reset, the same kernel and it worked. Two
reboots later and I had the "nobody cared" again. So I guess that the
irq line is active in every case but if the device (or the CPU) is fast
enough then I don't notice it. Later (after the first command or so) it
seems to get normal and issue the interrupt only if required.

Sebastian

Re: [RFC] ata/core: don't enable the interrupt while activating the host

[Sebastian Andrzej Siewior]

* Sebastian Andrzej Siewior | 2010-04-07 09:52:49 [+0200]:

>>>   Perhaps the drive incorrectly triggers interrupt on setting the nIEN
>>> bit -- some drives are known to do this; there is a blacklist of such
>>> drives in the IDE core so that it avoids setting nIEN bit for them.
>>
>>Arghh.... that stinks.  Maybe we should port the list over?  What is
>>the ATA device in question here?
>
>[    1.257000] ata1.00: ATA-6: WDC WD1600PB-98FBA0, 15.05R15, max UDMA/100
>[    1.264000] ata1.00: 312581808 sectors, multi 0: LBA48
>[    1.269000] ata1.01: ATAPI: HL-DT-ST DVDRAM GSA-4081B, A100, max UDMA/33
>[    1.335000] scsi 0:0:0:0: Direct-Access     ATA      WDC WD1600PB-98F 15.0 PQ: 0 ANSI: 5
>[    1.387000] scsi 0:0:1:0: CD-ROM            HL-DT-ST DVDRAM GSA-4081B A100 PQ: 0 ANSI: 5
>
>I try to unplug them later and see if the problem goes away once there
>is no device.
This is odd:
- a different HD & CD-ROM => seems to work
- just this CD-ROM => IRQ storm
- just the HD => 
 [    6.109000] ata1: link is slow to respond, please be patient (ready=0)
 [   11.113000] ata1: device not ready (errno=-16), forcing hardreset
 [   16.319000] ata1: link is slow to respond, please be patient (ready=0)
 [   21.170000] ata1: SRST failed (errno=-16)
 [   26.374000] ata1: link is slow to respond, please be patient (ready=0)
 [   31.174000] ata1: SRST failed (errno=-16)
 [   36.378000] ata1: link is slow to respond, please be patient (ready=0)
- this HD nad other CD-ROM => seems to work

The "odd" HD seems to work on X86 however the boot process gets delayed
by like 30 seconds. The CD-ROM seems not show any side effects.

So I fixed this problem by replacing the HD. Thanks for the pointers :)

Sebastian