lkml.org 
[lkml]   [2010]   [Jan]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
SubjectRe: New MSI support in sata_sil24 still broken in 2.6.33-rc3
From
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);
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2010-01-07 03:29    [W:0.086 / U:0.240 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site