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.
-
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
