Hello,
James Clark wrote:
> I have an Adaptec 1220SA which I originally thought was just a re-badged
> Sil3132 design. Externally it appears that way (the stamp on the chip
> reads 3132), however it identifies as a Silicon Image type 0x0242
> according to lspci. sata_sil24 does not attach.
>
> I made the trivial addition to sata_sil24 device id table and it appears
> to work. Performance is about the same as I get with the same drives on
> the onboard sata_via (about 78MB/s sequential read, 72MB/s write) and
> md mirror resyncing reflects this.
I'll ask SIMG about it.
> This is on a FC6 system (2.6.19-1.2911.fc6 SMP x86_64).
> I compared with 2.6.20 sources and sata_sil24 seems to have some
> cosmetic changes, but nothing that would help this it seems.
>
> When the patched module loads I see a 'failed to IDENTIFY' and spurious
> interrupt message. These do not seem to recur during use. Anything to
> worry about?
> I note that lspci reports a subvendor of Adaptec, type 0x242. Is it
> correct to just patch (like below) where one vendor appears to have
> 'cloaked' a generic board?
Yeap, the patch looks fine.
> 04:00.0 RAID bus controller: Silicon Image, Inc. Unknown device 0242
> (rev 01) (prog-if 01)
> Subsystem: Adaptec Unknown device 0242
> Flags: bus master, fast devsel, latency 0, IRQ 32
> Memory at dc004000 (64-bit, non-prefetchable) [size=128]
> Memory at dc000000 (64-bit, non-prefetchable) [size=16K]
> I/O ports at 9000 [size=128]
> Expansion ROM at db000000 [disabled] [size=512K]
> Capabilities: [54] Power Management version 2
> Capabilities: [5c] Message Signalled Interrupts: 64bit+ Queue=0/0
> Enable-
> Capabilities: [70] Express Legacy Endpoint IRQ 0
> Capabilities: [100] Advanced Error Reporting
>
> ---
>
> --- drivers/ata/sata_sil24.c.orig 2006-11-30 05:57:37.000000000 +0800
> +++ drivers/ata/sata_sil24.c 2007-02-28 19:08:18.000000000 +0800
> @@ -347,6 +347,7 @@
> { PCI_VDEVICE(CMD, 0x3124), BID_SIL3124 },
> { PCI_VDEVICE(INTEL, 0x3124), BID_SIL3124 },
> { PCI_VDEVICE(CMD, 0x3132), BID_SIL3132 },
> + { PCI_VDEVICE(CMD, 0x0242), BID_SIL3132 },
> { PCI_VDEVICE(CMD, 0x3131), BID_SIL3131 },
> { PCI_VDEVICE(CMD, 0x3531), BID_SIL3131 },
>
> ---
>
> sata_sil24 0000:04:00.0: version 0.3
> ACPI: PCI Interrupt 0000:04:00.0[A] -> GSI 32 (level, low) -> IRQ 32
> PCI: Setting latency timer of device 0000:04:00.0 to 64
> ata3: SATA max UDMA/100 cmd 0xFFFFC20012378000 ctl 0x0 bmdma 0x0 irq 32
> ata4: SATA max UDMA/100 cmd 0xFFFFC2001237A000 ctl 0x0 bmdma 0x0 irq 32
> scsi2 : sata_sil24
> ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
> ata3.00: failed to IDENTIFY (INIT_DEV_PARAMS failed, err_mask=0x80)
> ata3: spurious interrupt (slot_stat 0x0 active_tag -84148995 sactive 0x0)
But this is weird. libata somehow thought the drive is a really old one
and tried to do INIT_DEV_PARAMS on it. Does this always happen? Can
you give a shot at 2.6.20 with your patch applied?
Thanks.
--
tejun
-
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
