weird port status w/ sata_mv

weird port status w/ sata_mv

[Andres Salomon]

Hi,

I have 4 separate machines that have the following card in each of them:
0000:03:03.0 0104: 11ab:6041 (rev 09)
(that is, "RAID bus controller: Marvell Technology Group Ltd. MV88SX6041
4-port SATA II PCI-X Controller")

Most of the time when I boot the machine using an sata drive plugged
into the controller (as JBOD), it boots just fine.  However, every once
in a while, the sata_mv driver will fail to detect the drive that's
plugged in.  When that happens, no matter how many times I reboot, I
cannot get it to find the drive.  If I leave the machine turned off for
a while, and then turn it back on, sata_mv will typically then find the
drive.

Using 2.6.18-rc5 (it happens w/ old kernels as well), a successful
bootup will typically show the following:



sata_mv 0000:03:03.0: version 0.7
ACPI: PCI Interrupt 0000:03:03.0[A] -> GSI 42 (level, low) -> IRQ 169
sata_mv 0000:03:03.0: 32 slots 4 ports unknown mode IRQ via INTx
ata1: SATA max UDMA/133 cmd 0x0 ctl 0xF88A2120 bmdma 0x0 irq 169
ata2: SATA max UDMA/133 cmd 0x0 ctl 0xF88A4120 bmdma 0x0 irq 169
ata3: SATA max UDMA/133 cmd 0x0 ctl 0xF88A6120 bmdma 0x0 irq 169
ata4: SATA max UDMA/133 cmd 0x0 ctl 0xF88A8120 bmdma 0x0 irq 169
scsi0 : sata_mv
ata1: no device found (phy stat 00000000)
scsi1 : sata_mv
ata2.00: ATA-7, max UDMA/133, 488397168 sectors: LBA48
ata2.00: ata2: dev 0 multi count 0
ata2.00: configured for UDMA/133
scsi2 : sata_mv
ata3: no device found (phy stat 00000000)
scsi3 : sata_mv
ata4: no device found (phy stat 00000000)
  Vendor: ATA       Model: WDC WD2500JS-22M  Rev: 02.0
  Type:   Direct-Access                      ANSI SCSI revision: 05


As you can see, the drive is attached to ata2.  When the driver fails to
detect the drive, what happens is the driver spits out:

ata2: no device found (phy stat 00000224)

Looking through the driver, ata_port_online() is failing because it
expects the SCR_STATUS to be 0x3 instead of 0x4.  Unfortunately, I don't
see it documented anywhere what 0x3 actually means (nor what 0x4 means).
I've tried having the driver ignore 0x4, but it gets angry when
attempting to probe the drive.

What does 0x4 in the SCR_STATUS register actually mean?  Is there
something that can be initialized or reset to coax the port to a normal
status/state?

Re: weird port status w/ sata_mv

[Andres Salomon]

On Thu, 2006-09-07 at 02:59 -0400, Andres Salomon wrote:
[...]
> 
> What does 0x4 in the SCR_STATUS register actually mean?  Is there
> something that can be initialized or reset to coax the port to a normal
> status/state?
> 
> 

Ok, so to answer my own question: according to
<http://www.monkey.org/openbsd/archive/misc/0408/msg01454.html>, it
would appear that 0x4 means the PHY is in offline mode.  So the question
is, why is it offline, and what can be done to reset it?

Re: weird port status w/ sata_mv

[Andres Salomon]

[-- Attachment #1: Type: text/plain, Size: 864 bytes --]

On Thu, 2006-09-07 at 03:22 -0400, Andres Salomon wrote:
> On Thu, 2006-09-07 at 02:59 -0400, Andres Salomon wrote:
> [...]
> > 
> > What does 0x4 in the SCR_STATUS register actually mean?  Is there
> > something that can be initialized or reset to coax the port to a normal
> > status/state?
> > 
> > 
> 
> Ok, so to answer my own question: according to
> <http://www.monkey.org/openbsd/archive/misc/0408/msg01454.html>, it
> would appear that 0x4 means the PHY is in offline mode.  So the question
> is, why is it offline, and what can be done to reset it?


I've attached a patch that fixes a bug w/ the sstatus variable in
mv_phy_reset().  This patch should definitely be applied; even if it's
not fixing the bug I'm seeing, it could be affecting others.

I _think_ it fixes my bug, but I won't be certain for a little while
(since it's hard to reproduce).




[-- Attachment #2: 0002-sata_mv.patch --]
[-- Type: text/x-patch, Size: 1122 bytes --]

>From 8961af7328fc9a31f18e734a3aa4c6d2eaaa56a9 Mon Sep 17 00:00:00 2001
From: Andres Salomon <dilinger@debian.org>
Date: Sat, 9 Sep 2006 05:21:35 +0000
Subject: [PATCH] sata_mv: errata check buglet fix
Fix a buglet; the errata check below this code is assuming the value in
the sstatus variable is what was pulled out of the SCR_STATUS register.
However, the status checks in the timeout loop clobber everything but the
first 4 bits of sstatus, so the errata checks are invalid.

This patch changes it to not clobber sstatus.

Signed-off-by: Andres Salomon <dilinger@debian.org>
---
 drivers/scsi/sata_mv.c |    3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/sata_mv.c b/drivers/scsi/sata_mv.c
index 65c9ce6..404b4d3 100644
--- a/drivers/scsi/sata_mv.c
+++ b/drivers/scsi/sata_mv.c
@@ -1961,8 +1961,7 @@ comreset_retry:
 	timeout = jiffies + msecs_to_jiffies(200);
 	do {
 		sata_scr_read(ap, SCR_STATUS, &sstatus);
-		sstatus &= 0x3;
-		if ((sstatus == 3) || (sstatus == 0))
+		if (((sstatus & 0x3) == 3) || ((sstatus & 0x3) == 0))
 			break;
 
 		__msleep(1, can_sleep);
-- 
1.4.1.1