Hello Kyle,

I'm also using SIL3234 (sil24 driver) on P2020 and encountering
problems. Instead of starting my own investigation first I used google
powers to find this old email thread.

Have you found a more recent working solution to your problem?

Regards,

Leon.


On Sat, May 29, 2010 at 2:05 AM, Moffett, Kyle D
[off-list ref] wrote:

My advance apologies if this email gets badly MIME-mangled...

On 2010/01/06 20:59, "Robert Hancock" [off-list ref] wrote:

quoted

On 01/06/2010 03:37 AM, Torsten Kaiser wrote:

quoted

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

Cheers,
Kyle Moffett

-- 
Leon