[lkml]   [2010]   [May]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: New MSI support in sata_sil24 still broken in 2.6.33-rc3
    My advance apologies if this email gets badly MIME-mangled...

    On 2010/01/06 20:59, "Robert Hancock" <> 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.)

    I've got this custom board that uses the sata_sil24 driver (off a P2020
    processor). My current kernel is a slightly patched 2.6.32 kernel
    (including the sata_sil24 enable-MSI patch).

    Unfortunately when I turn MSI on, I get the exact same hang described here,
    boot log included as dmesg1.txt.

    With this patch applied, it seems to get a little further (dmesg2.txt), but
    still dies miserably.

    I'm relatively sure that MSI works on this chipset as I also have an e1000e
    controller off an adjacent PCI-E bus which works correctly with MSI.

    It's relatively critical for me to get MSI working, because the legacy-PCI
    INTx interrupt for that PCI-E port happens to share an IRQ line with a
    device that is very unfriendly to shared IRQs (it has no internal IRQ
    disable register). I'd rather not have to go in there with a soldering iron
    and some scraps of wire to make it work. :-D

    Kyle Moffett

    [unhandled content-type:application/octet-stream][unhandled content-type:application/octet-stream]
     \ /
      Last update: 2010-05-29 03:23    [W:0.038 / U:1.864 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site