Re: New MSI support in sata_sil24 still broken in 2.6.33-rc3

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Jan 7, 2010 at 1:59 AM, Robert Hancock <hancockrwd@xxxxxxxxx> 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-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Filesystems]     [Linux SCSI]     [Linux RAID]     [Git]     [Kernel Newbies]     [Linux Newbie]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Samba]     [Device Mapper]

  Powered by Linux