Re: sata_mv: hard resetting port

[Mark Lord <liml@rtr.ca>]

Tomasz Chmielewski wrote:
>
> And today kernel (2.6.23.1) in the same machine have spoken to 
> not-mere-mortals again:
> 
> ata6: exception Emask 0x10 SAct 0x0 SErr 0x0 action 0x6 frozen
> ata6: edma_err 0x00000020
..

Here, the messages fail us.  The edma_err value says that there
should be a non-zero value in the SErr value.  Except the messages
show zero there, meaning the registers were probably read in the
wrong sequence (some bits clear automatically on reads).

In any event, the messages that follow don't say anything about
I/O failing in any way, so again this is nothing to be concerned about
unless it happens frequently.

At this point, I would unplug/replug all of the SATA cables,
to ensure they have good connections.


> ata6: hard resetting port
> ata6: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
> ata6.00: configured for UDMA/133
> ata6: EH complete
> sd 5:0:0:0: [sde] 781422768 512-byte hardware sectors (400088 MB)
> sd 5:0:0:0: [sde] Write Protect is off
> sd 5:0:0:0: [sde] Mode Sense: 00 3a 00 00
> sd 5:0:0:0: [sde] Write cache: enabled, read cache: enabled, doesn't 
> support DPO or FUA
> 
> 
> As I understand it now, your previous translation would fit here (or 
> not, as SErr differs?):
> 
>  > Translation:
>  > "libata reset the link, and everything appeared okay,
>  > so it reissued the failed command and continued.
>  > No data loss."
> 
> But why was the port reseted? There was no CRC error as before, was there?
..

I think the error-handling code is a bit heavy handed,
in that the port reset was not actually needed in the prior case either.

But this way it is simple, consistent, and does work.
It just prints too many messages.

> What worries me is that it always happens for the same drive.
..

Twiddle with the cabling for that drive, and it will probably behave.