mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Torsten Kaiser <just.for.lkml@googlemail.com>
To: Robert Hancock <hancockrwd@gmail.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Vivek Mahajan <vivek.mahajan@freescale.com>,
	Jeff Garzik <jgarzik@pobox.com>,
	linux-ide@vger.kernel.org
Subject: Re: New MSI support in sata_sil24 still broken in 2.6.33-rc3
Date: Thu, 7 Jan 2010 03:27:15 +0100	[thread overview]
Message-ID: <64bb37e1001061827i64ead7f9m3dbe1b7b707c79eb@mail.gmail.com> (raw)
In-Reply-To: <4B4531F9.3060108@gmail.com>

On Thu, Jan 7, 2010 at 1:59 AM, Robert Hancock <hancockrwd@gmail.com> wrote:
> On 01/06/2010 03:37 AM, Torsten Kaiser wrote:
>>
>> After activating the MSI support by adding sata_sil24.msi=1 to the
>> kernel command line, the first write to a drive attached to the SiI
>> 3132 controller results in the following errors:
>>
>> [  138.950074] ata2.00: exception Emask 0x0 SAct 0xf SErr 0x0 action 0x6
>> frozen
>> [  138.961023] ata2.00: failed command: WRITE FPDMA QUEUED
>> [  138.970034] ata2.00: cmd 61/00:00:a5:95:4a/04:00:01:00:00/40 tag 0
>> ncq 524288 out
>> [  138.970037]          res 40/00:00:00:00:00/00:00:00:00:00/00 Emask
>> 0x4 (timeout)
>
> Looking at the code in sata_sil24 and the SiI3132 datasheet, there's a
> control bit which doesn't seem to be handled in the driver, global control
> register bit 30: "MSI Acknowledge (W). Writing a one to this bit
> acknowledges a Message Signaled Interrupt and permits generation of another
> MSI. This bit is cleared immediately after the acknowledgement is recognized
> by the control logic, hence the bit will always be read as a zero. If all
> interrupt conditions are removed subsequent to an MSI, it is not necessary
> to assert this Acknowledge; another MSI will be generated when an interrupt
> condition occurs."
>
> The way the interrupt handler for this driver works is that we check the
> global IRQ status register, and then based on what ports indicated an
> interrupt in that register, we check the individual port command completion
> registers. The issue would seem to be that if a port got an interrupt
> condition in between these two operations, we'd miss it, and the MSI logic
> described above then wouldn't generate any more interrupts since we didn't
> remove all interrupt conditions.
>
> Can you try this patch and see if it helps? (Might be whitespace damaged but
> hopefully you can apply manually in that case.)

Tried it, but writing still fails:
[   53.467694] XFS mounting filesystem sdb2
[  141.010058] ata2.00: exception Emask 0x0 SAct 0xf SErr 0x0 action 0x6 frozen
[  141.020361] ata2.00: failed command: WRITE FPDMA QUEUED
[  141.028718] ata2.00: cmd 61/00:00:5d:cd:48/04:00:01:00:00/40 tag 0
ncq 524288 out
[  141.028721]          res 40/00:00:00:00:00/00:00:00:00:00/00 Emask
0x4 (timeout)
[  141.049895] ata2.00: status: { DRDY }
[  141.056715] ata2.00: failed command: WRITE FPDMA QUEUED
[  141.065133] ata2.00: cmd 61/00:08:5d:c5:48/04:00:01:00:00/40 tag 1
ncq 524288 out
[  141.065135]          res 40/00:00:00:00:00/00:00:00:00:00/00 Emask
0x4 (timeout)
[  141.086492] ata2.00: status: { DRDY }
[  141.093313] ata2.00: failed command: WRITE FPDMA QUEUED
[  141.101679] ata2.00: cmd 61/00:10:5d:c9:48/04:00:01:00:00/40 tag 2
ncq 524288 out
[  141.101682]          res 40/00:00:00:00:00/00:00:00:00:00/00 Emask
0x4 (timeout)
[  141.122813] ata2.00: status: { DRDY }
[  141.129522] ata2.00: failed command: WRITE FPDMA QUEUED
[  141.137769] ata2.00: cmd 61/00:18:5d:d1:48/04:00:01:00:00/40 tag 3
ncq 524288 out
[  141.137771]          res 40/00:00:00:00:00/00:00:00:00:00/00 Emask
0x4 (timeout)
[  141.158660] ata2.00: status: { DRDY }
[  141.165313] ata2: hard resetting link
[  143.370049] ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 0)
[  148.370031] ata2.00: qc timeout (cmd 0xec)
[  148.377198] ata2.00: failed to IDENTIFY (I/O error, err_mask=0x4)
[  148.386450] ata2.00: revalidation failed (errno=-5)
[  148.394504] ata2: hard resetting link
[  150.600064] ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 0)
[  160.600038] ata2.00: qc timeout (cmd 0xec)
[  160.607451] ata2.00: failed to IDENTIFY (I/O error, err_mask=0x4)
[  160.616913] ata2.00: revalidation failed (errno=-5)
[  160.625181] ata2: limiting SATA link speed to 1.5 Gbps
[  160.633746] ata2: hard resetting link
[  162.830049] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 10)
...

Please note, that in my first report I also mentioned that I get the
same behavior with sata_nv. If I use sata_nv.msi=1 writing to the
drives attached to the MCP55 fail. The sata_nv problem is not new,
that never worked for me, but I only retried it with 2.6.33-rc1.
Other drivers can use MSI successfull (tg3, hda-intel, radeon).

> diff --git a/drivers/ata/sata_sil24.c b/drivers/ata/sata_sil24.c
> index 1370df6..d3d8dec 100644
> --- a/drivers/ata/sata_sil24.c
> +++ b/drivers/ata/sata_sil24.c
> @@ -102,6 +102,7 @@ enum {
>        HOST_CTRL_STOP          = (1 << 18), /* latched PCI STOP */
>        HOST_CTRL_DEVSEL        = (1 << 19), /* latched PCI DEVSEL */
>        HOST_CTRL_REQ64         = (1 << 20), /* latched PCI REQ64 */
> +       HOST_CTRL_MSIACK        = (1 << 30), /* MSI acknowledge */
>        HOST_CTRL_GLOBAL_RST    = (1 << 31), /* global reset */
>
>        /*
> @@ -1168,6 +1169,7 @@ static irqreturn_t sil24_interrupt(int irq, void
> *dev_instance)
>                                       ": interrupt from disabled port %d\n",
> i);
>                }
>
> +       writel(IRQ_STAT_4PORTS | HOST_CTRL_MSIACK, host_base + HOST_CTRL);
>        spin_unlock(&host->lock);
>  out:
>        return IRQ_RETVAL(handled);
>

  reply	other threads:[~2010-01-07  2:27 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-06  9:37 Torsten Kaiser
2010-01-07  0:59 ` Robert Hancock
2010-01-07  2:27   ` Torsten Kaiser [this message]
2010-01-07  3:05     ` Robert Hancock
2010-01-07  3:28       ` Torsten Kaiser
2010-01-07  6:33         ` Yinghai Lu
2010-05-29  0:05   ` Moffett, Kyle D
2011-03-09 23:44     ` Leon Woestenberg
2011-03-17 18:07 Tobias Karnat

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=64bb37e1001061827i64ead7f9m3dbe1b7b707c79eb@mail.gmail.com \
    --to=just.for.lkml@googlemail.com \
    --cc=hancockrwd@gmail.com \
    --cc=jgarzik@pobox.com \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=vivek.mahajan@freescale.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®