sata_sil.c, 3512 and SIL_QUIRK_MOD15WRITE

sata_sil.c, 3512 and SIL_QUIRK_MOD15WRITE

[Jon Kåre Hellan]

My Shuttle SN85G4V2 with Silicon Image 3512 SATA controller has been locking up
frequently for a while. Console message:

ata1: command 0x35 timeout, stat 0x58 host_stat 0x61
ata1: status=0x58 { DriveReady SeekComplete DataRequest }
sd 0:0:0:0: SCSI error: return code = 0x8000002
sda: Current: sense key: Aborted Command
    Additional sense: Scsi parity error
end_request: I/O error, dev sda, sector 57582833
Buffer I/O error on device sda6, logical block 3097255
lost page write due to I/O error on sda6
ATA: abnormal status 0x58 on port 0xF8802087
ATA: abnormal status 0x58 on port 0xF8802087

I have a Seagate ST3200822AS disk, which is on the blacklist in sata_sil.
In sil_pci_tbl in drivers/sata/sata_sil.c, I changed 3512 from sil_3112 to
sil_3112_m15w, enabling SIL_QUIRK_MOD15WRITE for my controller. With this, the
lockups are gone.

Looks like MOD15WRITE was turned off for the 3512 between 2.6.13 and 2.6.14.
This may have been a mistake, or else my system is unusually flaky. 

See also my Debian bug report
 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=353790

(I wrote there that I saw the lockups in the 2.6.8 kernel as well. Back then,
the blacklist affected my controller, but my disk drive didn't get on the
blacklist until 2.6.11).

Regards

Jon

Re: sata_sil.c, 3512 and SIL_QUIRK_MOD15WRITE

[Tejun Heo]

Jon Kåre Hellan wrote:
> My Shuttle SN85G4V2 with Silicon Image 3512 SATA controller has been locking up
> frequently for a while. Console message:
> 
> ata1: command 0x35 timeout, stat 0x58 host_stat 0x61
> ata1: status=0x58 { DriveReady SeekComplete DataRequest }
> sd 0:0:0:0: SCSI error: return code = 0x8000002
> sda: Current: sense key: Aborted Command
>     Additional sense: Scsi parity error
> end_request: I/O error, dev sda, sector 57582833
> Buffer I/O error on device sda6, logical block 3097255
> lost page write due to I/O error on sda6
> ATA: abnormal status 0x58 on port 0xF8802087
> ATA: abnormal status 0x58 on port 0xF8802087
> 
> I have a Seagate ST3200822AS disk, which is on the blacklist in sata_sil.
> In sil_pci_tbl in drivers/sata/sata_sil.c, I changed 3512 from sil_3112 to
> sil_3112_m15w, enabling SIL_QUIRK_MOD15WRITE for my controller. With this, the
> lockups are gone.
> 
> Looks like MOD15WRITE was turned off for the 3512 between 2.6.13 and 2.6.14.
> This may have been a mistake, or else my system is unusually flaky. 
> 

Hello, Jon Kåre.

The m15w workaround is an extreme solution and tends to hide whatever 
bug/errata whether the problem actually is m15w or not. Unfortunately, 
in the past, we didn't have enough errata information and thus the m15w 
blacklist kept growing (oh... something wrong with Seagate drives? It 
must be m15w!).

Recently, Silicon Image has opened all the erratas and we're in the 
process of getting things done correctly. New errata workarounds are 
being implemented and devices not really affected by m15w are delisted, 
etc... And, unfortunately, due to insufficient information, turning off 
m15w for 3512 and 3114 was done before addind other needed workarounds 
causing problems for 3512 and 3114 users.

According to the errata information from Silicon Image, SiI3512 does not 
have m15w bug, neither does ST3200822AS. So, this must be something else 
and you're not an isolated case. One of my friends reported the same 
problem but I currently can't test it as he sold his motherboard 
*really* fast. :-( So, it would be very nice if you can test fixes we'll 
be able to come up with.

Carlos (Hi!), 3512 + some 7200.7 hangs. Can you think of any related errata?

Thanks.

-- 
tejun

Re: sata_sil.c, 3512 and SIL_QUIRK_MOD15WRITE

[Jeff Garzik]

Tejun Heo wrote:
> According to the errata information from Silicon Image, SiI3512 does not 
> have m15w bug, neither does ST3200822AS. So, this must be something else 
> and you're not an isolated case. One of my friends reported the same 
> problem but I currently can't test it as he sold his motherboard 
> *really* fast. :-( So, it would be very nice if you can test fixes we'll 
> be able to come up with.
> 
> Carlos (Hi!), 3512 + some 7200.7 hangs. Can you think of any related 
> errata?


I think I'm going to start patching sata_sil.c with a todo list, just to 
keep track of things.

In particular, in ADDITION to errata recently sent by SiI, sata_sil 
could do better with reset, it needs to handle watchdog timer interrupt, 
and it desperately wants the irq-pio branch merged.

	Jeff

Re: sata_sil.c, 3512 and SIL_QUIRK_MOD15WRITE

[Tejun Heo]

Jeff Garzik 쓴 글:
> Tejun Heo wrote:
>> According to the errata information from Silicon Image, SiI3512 does 
>> not have m15w bug, neither does ST3200822AS. So, this must be 
>> something else and you're not an isolated case. One of my friends 
>> reported the same problem but I currently can't test it as he sold his 
>> motherboard *really* fast. :-( So, it would be very nice if you can 
>> test fixes we'll be able to come up with.
>>
>> Carlos (Hi!), 3512 + some 7200.7 hangs. Can you think of any related 
>> errata?
> 
> 
> I think I'm going to start patching sata_sil.c with a todo list, just to 
> keep track of things.
> 
> In particular, in ADDITION to errata recently sent by SiI, sata_sil 
> could do better with reset, it needs to handle watchdog timer interrupt, 
> and it desperately wants the irq-pio branch merged.
> 

We also need to delist some drives from m15w list according to SIMG's 
blacklist. Is there any reason why sata_sil wants irq-pio desparately 
compared to other drivers? Actually it seems that all sata_sil 
controllers seem to be capable of performing PIO using DMA which makes 
PIO support unncessary.

-- 
tejun

Re: sata_sil.c, 3512 and SIL_QUIRK_MOD15WRITE

[Jeff Garzik]

Tejun Heo wrote:
> We also need to delist some drives from m15w list according to SIMG's 
> blacklist. Is there any reason why sata_sil wants irq-pio desparately 
> compared to other drivers? Actually it seems that all sata_sil 

I presume the root cause is that SiI hardware is more like sata_vsc, 
hardware that _really_ wants to deliver an interrupt upon completion, 
even if interrupts are ostensibly disabled.

There are many reports in the field of a "lockup" (really screaming 
interrupts) that is solved by irq-pio or 'irqpoll' option.


> controllers seem to be capable of performing PIO using DMA which makes 
> PIO support unncessary.

This isn't supported because its a pain in the ass.  You must set up a 
new DMA transfer for each DRQ block in the PIO transfer.

If you want to write the code the support this... great!  That's 
definitely the best way to go long-term.

	Jeff

Re: sata_sil.c, 3512 and SIL_QUIRK_MOD15WRITE

[Jon K Hellan]

On Thu, 2006-02-23 at 11:07 +0900, Tejun Heo wrote:
> According to the errata information from Silicon Image, SiI3512 does not 
> have m15w bug, neither does ST3200822AS. So, this must be something else 
> and you're not an isolated case.

Glad to hear it.

In that case, you'd probably like to hear about the other disk as well.
Originally, I suspected the disk was about to fail, and bought another
one - a Samsung SP2504C. I never succeeded in copying the data off the
Seagate onto the Samsung. The farthest I got was about 2 gigs. The error
messages would be from sdb (the Samsung):

Feb 21 20:08:31 parus kernel: ata2: command 0x35 timeout, stat 0xd1 host_stat 0x61
Feb 21 20:08:31 parus kernel: ata2: translated ATA stat/err 0xd1/00 to
SCSI SK/ASC/ASCQ 0xb/47/00
Feb 21 20:08:31 parus kernel: ata2: status=0xd1 { Busy }
Feb 21 20:08:31 parus kernel: sd 1:0:0:0: SCSI error: return code =
0x8000002
Feb 21 20:08:31 parus kernel: sdb: Current: sense key: Aborted Command
Feb 21 20:08:31 parus kernel:     Additional sense: Scsi parity error
Feb 21 20:08:31 parus kernel: end_request: I/O error, dev sdb, sector
15657695
Feb 21 20:08:31 parus kernel: Buffer I/O error on device sdb1, logical
block 1957204
Feb 21 20:08:31 parus kernel: lost page write due to I/O error on sdb1
Feb 21 20:08:31 parus kernel: ATA: abnormal status 0xD1 on port
0xF88020C7

I didn't bring this up originally, since it looked like the Seagate
problem was a known bug, while Google didn't turn up anything on
Samsung. After reading linux-ide through gmane, I've seen similar issues
about Samsung. You guys should get an archive which Google knows
about :-)

> So, it would be very nice if you can test fixes we'll be able to come up with.

Certainly.

Regards

Jon

Re: sata_sil.c, 3512 and SIL_QUIRK_MOD15WRITE

[Tejun Heo]

On Thu, Feb 23, 2006 at 07:59:47AM +0100, Jon K Hellan wrote:
> On Thu, 2006-02-23 at 11:07 +0900, Tejun Heo wrote:
> > According to the errata information from Silicon Image, SiI3512 does not 
> > have m15w bug, neither does ST3200822AS. So, this must be something else 
> > and you're not an isolated case.
> 
> Glad to hear it.
> 
> In that case, you'd probably like to hear about the other disk as well.
> Originally, I suspected the disk was about to fail, and bought another
> one - a Samsung SP2504C. I never succeeded in copying the data off the
> Seagate onto the Samsung. The farthest I got was about 2 gigs. The error
> messages would be from sdb (the Samsung):
> 
> Feb 21 20:08:31 parus kernel: ata2: command 0x35 timeout, stat 0xd1 host_stat 0x61
> Feb 21 20:08:31 parus kernel: ata2: translated ATA stat/err 0xd1/00 to
> SCSI SK/ASC/ASCQ 0xb/47/00
> Feb 21 20:08:31 parus kernel: ata2: status=0xd1 { Busy }
> Feb 21 20:08:31 parus kernel: sd 1:0:0:0: SCSI error: return code =
> 0x8000002
> Feb 21 20:08:31 parus kernel: sdb: Current: sense key: Aborted Command
> Feb 21 20:08:31 parus kernel:     Additional sense: Scsi parity error
> Feb 21 20:08:31 parus kernel: end_request: I/O error, dev sdb, sector
> 15657695
> Feb 21 20:08:31 parus kernel: Buffer I/O error on device sdb1, logical
> block 1957204
> Feb 21 20:08:31 parus kernel: lost page write due to I/O error on sdb1
> Feb 21 20:08:31 parus kernel: ATA: abnormal status 0xD1 on port
> 0xF88020C7
> 
> I didn't bring this up originally, since it looked like the Seagate
> problem was a known bug, while Google didn't turn up anything on
> Samsung. After reading linux-ide through gmane, I've seen similar issues
> about Samsung. You guys should get an archive which Google knows
> about :-)

Well, I'm happy with gmane/marc for the time being.  :-)

> 
> > So, it would be very nice if you can test fixes we'll be able to come up with.
> 

Can you try the following patch?  It's a kind of long shot.  I just
want to make sure.  And even if it doesn't work, it wouldn't do any
harm.

diff --git a/drivers/scsi/sata_sil.c b/drivers/scsi/sata_sil.c
index e14ed4e..2f71924 100644
--- a/drivers/scsi/sata_sil.c
+++ b/drivers/scsi/sata_sil.c
@@ -215,12 +215,13 @@ static const struct {
 	unsigned long scr;	/* SATA control register block */
 	unsigned long sien;	/* SATA Interrupt Enable register */
 	unsigned long xfer_mode;/* data transfer mode register */
+	unsigned long sfis_cfg;	/* SATA FIS reception config register */
 } sil_port[] = {
 	/* port 0 ... */
-	{ 0x80, 0x8A, 0x00, 0x100, 0x148, 0xb4 },
-	{ 0xC0, 0xCA, 0x08, 0x180, 0x1c8, 0xf4 },
-	{ 0x280, 0x28A, 0x200, 0x300, 0x348, 0x2b4 },
-	{ 0x2C0, 0x2CA, 0x208, 0x380, 0x3c8, 0x2f4 },
+	{ 0x80, 0x8A, 0x00, 0x100, 0x148, 0xb4, 0x14c },
+	{ 0xC0, 0xCA, 0x08, 0x180, 0x1c8, 0xf4, 0x1cc },
+	{ 0x280, 0x28A, 0x200, 0x300, 0x348, 0x2b4, 0x34c },
+	{ 0x2C0, 0x2CA, 0x208, 0x380, 0x3c8, 0x2f4, 0x3cc },
 	/* ... port 3 */
 };
 
@@ -372,7 +373,7 @@ static int sil_init_one (struct pci_dev 
 	unsigned long base;
 	void __iomem *mmio_base;
 	int rc;
-	unsigned int i;
+	unsigned int i, cnt;
 	int pci_dev_busy = 0;
 	u32 tmp, irq_mask;
 	u8 cls;
@@ -466,11 +467,23 @@ static int sil_init_one (struct pci_dev 
 		if ((tmp & SIL_INTR_STEERING) == 0)
 			writel(tmp | SIL_INTR_STEERING,
 			       mmio_base + SIL_IDE2_BMDMA);
-
 	} else {
 		irq_mask = SIL_MASK_2PORT;
 	}
 
+	/* R_ERR on DMA activate FIS errata workaround */
+	for (i = 0, cnt = 0; i < probe_ent->n_ports; i++) {
+		tmp = readl(mmio_base + sil_port[i].sfis_cfg);
+		if ((tmp & 0x3) != 0x01)
+			continue;
+		if (!cnt)
+			dev_printk(KERN_INFO, &pdev->dev,
+				   "Applying R_ERR on DMA activate "
+				   "FIS errata fix\n");
+		writel(tmp & ~0x3, mmio_base + sil_port[i].sfis_cfg);
+		cnt++;
+	}
+
 	/* make sure IDE0/1/2/3 interrupts are not masked */
 	tmp = readl(mmio_base + SIL_SYSCFG);
 	if (tmp & irq_mask) {

Re: sata_sil.c, 3512 and SIL_QUIRK_MOD15WRITE

[Jon K Hellan]

On Thu, 2006-02-23 at 16:19 +0900, Tejun Heo wrote:

> Can you try the following patch?  It's a kind of long shot.

Long shot? Seems to work. I didn't see any lockups during the 12 hours I
tested. The bug normally shows up in less than 1 hour. Out of curiosity,
what does the patch do?

Regards

Jon
>   I just
> want to make sure.  And even if it doesn't work, it wouldn't do any
> harm.
> 
> diff --git a/drivers/scsi/sata_sil.c b/drivers/scsi/sata_sil.c
> index e14ed4e..2f71924 100644
> --- a/drivers/scsi/sata_sil.c
> +++ b/drivers/scsi/sata_sil.c
> @@ -215,12 +215,13 @@ static const struct {
>  	unsigned long scr;	/* SATA control register block */
>  	unsigned long sien;	/* SATA Interrupt Enable register */
>  	unsigned long xfer_mode;/* data transfer mode register */
> +	unsigned long sfis_cfg;	/* SATA FIS reception config register */
>  } sil_port[] = {
>  	/* port 0 ... */
> -	{ 0x80, 0x8A, 0x00, 0x100, 0x148, 0xb4 },
> -	{ 0xC0, 0xCA, 0x08, 0x180, 0x1c8, 0xf4 },
> -	{ 0x280, 0x28A, 0x200, 0x300, 0x348, 0x2b4 },
> -	{ 0x2C0, 0x2CA, 0x208, 0x380, 0x3c8, 0x2f4 },
> +	{ 0x80, 0x8A, 0x00, 0x100, 0x148, 0xb4, 0x14c },
> +	{ 0xC0, 0xCA, 0x08, 0x180, 0x1c8, 0xf4, 0x1cc },
> +	{ 0x280, 0x28A, 0x200, 0x300, 0x348, 0x2b4, 0x34c },
> +	{ 0x2C0, 0x2CA, 0x208, 0x380, 0x3c8, 0x2f4, 0x3cc },
>  	/* ... port 3 */
>  };
>  
> @@ -372,7 +373,7 @@ static int sil_init_one (struct pci_dev 
>  	unsigned long base;
>  	void __iomem *mmio_base;
>  	int rc;
> -	unsigned int i;
> +	unsigned int i, cnt;
>  	int pci_dev_busy = 0;
>  	u32 tmp, irq_mask;
>  	u8 cls;
> @@ -466,11 +467,23 @@ static int sil_init_one (struct pci_dev 
>  		if ((tmp & SIL_INTR_STEERING) == 0)
>  			writel(tmp | SIL_INTR_STEERING,
>  			       mmio_base + SIL_IDE2_BMDMA);
> -
>  	} else {
>  		irq_mask = SIL_MASK_2PORT;
>  	}
>  
> +	/* R_ERR on DMA activate FIS errata workaround */
> +	for (i = 0, cnt = 0; i < probe_ent->n_ports; i++) {
> +		tmp = readl(mmio_base + sil_port[i].sfis_cfg);
> +		if ((tmp & 0x3) != 0x01)
> +			continue;
> +		if (!cnt)
> +			dev_printk(KERN_INFO, &pdev->dev,
> +				   "Applying R_ERR on DMA activate "
> +				   "FIS errata fix\n");
> +		writel(tmp & ~0x3, mmio_base + sil_port[i].sfis_cfg);
> +		cnt++;
> +	}
> +
>  	/* make sure IDE0/1/2/3 interrupts are not masked */
>  	tmp = readl(mmio_base + SIL_SYSCFG);
>  	if (tmp & irq_mask) {

Re: sata_sil.c, 3512 and SIL_QUIRK_MOD15WRITE

[Tejun Heo]

Jon K Hellan wrote:
> On Thu, 2006-02-23 at 16:19 +0900, Tejun Heo wrote:
> 
> 
>>Can you try the following patch?  It's a kind of long shot.
> 
> 
> Long shot? Seems to work. I didn't see any lockups during the 12 hours I
> tested. The bug normally shows up in less than 1 hour. Out of curiosity,
> what does the patch do?
> 

Hello, Jon.

Hmmm... it's a pending workaround for 3114's R_ERR on DMA activate FIS
errata, which goes like...

 *  3. SiI 3114 R_ERR on DMA activate FIS errta workaround
 *
 *  Errata:
 *    During DMA write operations with a data length greater than 8
 *    Kbytes, a PRD entry fetch that occurs at the same time that a
 *    DMA Activate FIS is received may cause the SiI3114 to falsely
 *    indicate that the DMA Activate FIS has an illegal FIS Type.
 *    This may cause the Sil3114 to send an R_EER in response to the
 *    DMA Active FIS.
 *
 *  Workaround:
 *    By configuring bit[1:0] of the SFISCfg register to accept FIS
 *    types other than the standard SATA defined FIS types, the
 *    SiI3114 is prevented from falsely setting the illegal FIS Type
 *    indicator, thus preventing the improper RERR response.  The
 *    default value of the SFISCfg register is 0x1040_1555.  To
 *    implement this workaround, the SFISCfg register should be set to
 *    a value of 0x1040_1554.
 *
 *    This workaround is applied during controller initialization in
 *    sil_init_one().
 *

So, you're confirming that this workaround fixes your lockup on 3152 for
both ST3200822AS and SP2504C, right?

Carlos, can you confirm this? It seems like 3512 shares this errata with
3114.

Thanks.

-- 
tejun

Re: sata_sil.c, 3512 and SIL_QUIRK_MOD15WRITE

[Tejun Heo]

Tejun Heo wrote:
> Jon K Hellan wrote:
> 
>>On Thu, 2006-02-23 at 16:19 +0900, Tejun Heo wrote:
>>
>>
>>
>>>Can you try the following patch?  It's a kind of long shot.
>>
>>
>>Long shot? Seems to work. I didn't see any lockups during the 12 hours I
>>tested. The bug normally shows up in less than 1 hour. Out of curiosity,
>>what does the patch do?
>>
> 
> 
> Hello, Jon.
> 
> Hmmm... it's a pending workaround for 3114's R_ERR on DMA activate FIS
> errata, which goes like...
> 
>  *  3. SiI 3114 R_ERR on DMA activate FIS errta workaround
>  *
>  *  Errata:
>  *    During DMA write operations with a data length greater than 8
>  *    Kbytes, a PRD entry fetch that occurs at the same time that a
>  *    DMA Activate FIS is received may cause the SiI3114 to falsely
>  *    indicate that the DMA Activate FIS has an illegal FIS Type.
>  *    This may cause the Sil3114 to send an R_EER in response to the
>  *    DMA Active FIS.
>  *
>  *  Workaround:
>  *    By configuring bit[1:0] of the SFISCfg register to accept FIS
>  *    types other than the standard SATA defined FIS types, the
>  *    SiI3114 is prevented from falsely setting the illegal FIS Type
>  *    indicator, thus preventing the improper RERR response.  The
>  *    default value of the SFISCfg register is 0x1040_1555.  To
>  *    implement this workaround, the SFISCfg register should be set to
>  *    a value of 0x1040_1554.
>  *
>  *    This workaround is applied during controller initialization in
>  *    sil_init_one().
>  *
> 
> So, you're confirming that this workaround fixes your lockup on 3152 for
> both ST3200822AS and SP2504C, right?
> 
> Carlos, can you confirm this? It seems like 3512 shares this errata with
> 3114.
> 

Jeff, once Carlos confirms this. I think this should go into 2.6.16.
3114/3512 lock up is certainly a bothering regression. I'll redo the
patch after Carlos's confirmation.

Thanks.

-- 
tejun

Re: sata_sil.c, 3512 and SIL_QUIRK_MOD15WRITE

[Jon Kåre Hellan]

Tejun Heo <htejun <at> gmail.com> writes:

> So, you're confirming that this workaround fixes your lockup on 3152 for
> both ST3200822AS and SP2504C, right?

I'm confirming for the Seagate ST3200822AS. Haven't tested the Samsung SP2504C 
yet.

Regards

Jon

Re: sata_sil.c, 3512 and SIL_QUIRK_MOD15WRITE

[Jon K Hellan]

On Fri, 2006-02-24 at 16:21 +0900, Tejun Heo wrote:

> So, you're confirming that this workaround fixes your lockup on 3152 for
> both ST3200822AS and SP2504C, right?

I've now tested both disks, and can confirm that lockups are fixed for
both. Thanks.

Jon