
Tengo un disco Seagate St2000dm001 2TB Barracuda Sata3 que produce errores similares a este:
[Tue Jun 14 10:02:06 2022] ata2.00: exception Emask 0x0 SAct 0x1 SErr 0x0 action 0x6 frozen
[Tue Jun 14 10:02:06 2022] ata2.00: failed command: WRITE FPDMA QUEUED
[Tue Jun 14 10:02:06 2022] ata2.00: cmd 61/00:00:00:48:9f/02:00:b2:00:00/40 tag 0 ncq 262144 out
[Tue Jun 14 10:02:06 2022] res 40/00:01:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
[Tue Jun 14 10:02:06 2022] ata2.00: status: { DRDY }
[Tue Jun 14 10:02:06 2022] ata2: hard resetting link
[Tue Jun 14 10:02:16 2022] ata2: softreset failed (1st FIS failed)
[Tue Jun 14 10:02:16 2022] ata2: hard resetting link
[Tue Jun 14 10:02:26 2022] ata2: softreset failed (1st FIS failed)
[Tue Jun 14 10:02:26 2022] ata2: hard resetting link
[Tue Jun 14 10:02:42 2022] ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[Tue Jun 14 10:02:42 2022] ata2.00: configured for UDMA/133
[Tue Jun 14 10:02:42 2022] ata2.00: device reported invalid CHS sector 0
[Tue Jun 14 10:02:42 2022] ata2: EH complete
Probé el disco con diferentes cables y en diferentes máquinas y los errores persisten. Parece un caso claro de disco roto, pero hay un giro. Recuperar los errores mientras se realiza un proceso muy prolongado mkfs.ext4 -c -c
proporciona un patrón periódico para los errores:
[Mon Jun 13 10:47:02 2022] ata2.00: failed command: WRITE FPDMA QUEUED
[Mon Jun 13 11:51:08 2022] ata2.00: failed command: WRITE FPDMA QUEUED
[Mon Jun 13 12:55:14 2022] ata2.00: failed command: WRITE FPDMA QUEUED
[Mon Jun 13 14:01:21 2022] ata2.00: failed command: READ FPDMA QUEUED
[Mon Jun 13 15:08:27 2022] ata2.00: failed command: READ FPDMA QUEUED
[Mon Jun 13 16:15:33 2022] ata2.00: failed command: READ FPDMA QUEUED
[Mon Jun 13 17:22:39 2022] ata2.00: failed command: WRITE FPDMA QUEUED
[Mon Jun 13 18:29:43 2022] ata2.00: failed command: WRITE FPDMA QUEUED
[Mon Jun 13 19:36:49 2022] ata2.00: failed command: WRITE FPDMA QUEUED
[Mon Jun 13 20:43:55 2022] ata2.00: failed command: WRITE FPDMA QUEUED
[Mon Jun 13 21:50:02 2022] ata2.00: failed command: READ FPDMA QUEUED
[Mon Jun 13 22:57:08 2022] ata2.00: failed command: READ FPDMA QUEUED
[Tue Jun 14 00:04:14 2022] ata2.00: failed command: READ FPDMA QUEUED
[Tue Jun 14 01:11:17 2022] ata2.00: failed command: WRITE FPDMA QUEUED
[Tue Jun 14 02:15:24 2022] ata2.00: failed command: WRITE FPDMA QUEUED
[Tue Jun 14 03:19:30 2022] ata2.00: failed command: WRITE FPDMA QUEUED
[Tue Jun 14 04:26:36 2022] ata2.00: failed command: READ FPDMA QUEUED
[Tue Jun 14 05:33:42 2022] ata2.00: failed command: READ FPDMA QUEUED
[Tue Jun 14 06:40:48 2022] ata2.00: failed command: READ FPDMA QUEUED
[Tue Jun 14 07:47:54 2022] ata2.00: failed command: WRITE FPDMA QUEUED
[Tue Jun 14 08:55:00 2022] ata2.00: failed command: WRITE FPDMA QUEUED
[Tue Jun 14 10:02:06 2022] ata2.00: failed command: WRITE FPDMA QUEUED
Es casi exactamente cada 1 hora y 7 minutos. Pensé que podría estar relacionado con smartd
, pero smartd
no se estaba ejecutando. Entonces, estoy atascado: ¿qué tipo de falla de hardware daría un error periódico con un período de 1 hora y 7 minutos? Cualquier idea sería muy apreciada.
Atentamente,
nicolás
Respuesta1
Eso es casi exactamente 4000 segundos, dentro de la precisión de un oscilador barato.
Esto significa que probablemente algo en el firmware de la unidad SATA o del controlador SATA hace esto automáticamente.
La razón de esto podría ser cualquier cosa, básicamente. Por ejemplo, el firmware de la unidad se reinicia cada 4000 segundos cuando falla alguna subrutina de verificación de componentes. El firmware del controlador SATA se reinicia cada 4000 cuando intenta renegociar un enlace y eso falla, o cualquier otra cosa, en realidad (estos dos ejemplos no son más probables que cualquier otra cosa).
Lo único que sugiere el momento es que es el software el que decide hacer eso, ya sea que se ejecute como sistema operativo, como controlador o como firmware de unidad. Y eso podría ser un error de software o una detección real de un error de hardware.
Entonces, es realmente difícil diagnosticar esto. Si el controlador y la unidad ya cuentan con sus revisiones de firmware recientes ( fwupdmgr get-updates
es tu amigo, para ambos), bueno.