WD Blue | hard resetting link
Résolu
ryko1820
Messages postés
1677
Date d'inscription
Statut
Membre
Dernière intervention
-
ryko1820 Messages postés 1677 Date d'inscription Statut Membre Dernière intervention -
ryko1820 Messages postés 1677 Date d'inscription Statut Membre Dernière intervention -
Bonjour,
Je profite de la présence d'un pro. des disques WD pour exposer mon souci ...
Je rencontre des problèmes récurrents de micro-déconnexions assez inquiétantes du disque système de mon serveur (Dell Inc. OptiPlex 740 Enhanced/0YP806, BIOS 2.1.6 05/04/2008).
Dernièrement je rencontrais un problème légèrement similaire avec un Seagate de 2To que j'ai fini par remplacer car le système était au bord du crash total (Problème exposé dans un post précédent).
Le disque dur a été remplacé, les câbles ont été remplacé par des câbles neufs ou récents (avec verrous) et je pensais avoir résolu le problème mais cela n'a duré qu'un jour ou deux ...
Il n'y a plus au total que 10 To de HDD (WD) sur cette machine (depuis remplacement du 2 To du système), 6 To en XFS et 3 To en NTFS en plus du 1 To saucissoné entre Windows et Linux. 8Go de RAM ...
lsblk --output NAME,FSTYPE,SIZE,MODEL,HCTL
Cette machine
Elle devrait tourner 24/7 mais est parfois éteinte.
Il y a également un Windows 7 pour test sur cette machine, mais qui n'est jamais mis en route, et de toutes façons je ne pense pas que des problèmes aussi subtils soient facilement identifiés par Windows avant qu'il ne soit trop tard et qu'un disque soit vraiment HS (? je me trompe peut être ?), néanmoins, je peux éventuellement installer des logiciels de tests sur Windows, bien que les problèmes apparaissent à l'usage et que je n'ai aucune utilité sur une telle machine de Windows.
——————————————————————————————————————————
dmesg :
——————————————————————————————————————————
smartctl -l /dev/sda
Dans ce rapport SMART on retrouve bien les erreur de déconnexions et je crains que cela ne finisse par générer de vrais problèmes d'écriture avant crash ... Pour l'instant le disque à l'air propre mais le Seagate qui a fini par lâcher (pas violemment mais problèmes écriture/lecture) la semaine dernière a bien fonctionné sur cette machine pendant quelques temps ...
Alors est-ce à votre avis, encore un problème de disque, de câbles, de kernel, de BIOS, de gestion de l'énergie, de contrôleur SATA (donc de CM), je préférerais clairement consacrer mon temps au développement qu'a l'administration du système permettant de faire une partie de ces développements ;-)
Je profite de la présence d'un pro. des disques WD pour exposer mon souci ...
Je rencontre des problèmes récurrents de micro-déconnexions assez inquiétantes du disque système de mon serveur (Dell Inc. OptiPlex 740 Enhanced/0YP806, BIOS 2.1.6 05/04/2008).
Dernièrement je rencontrais un problème légèrement similaire avec un Seagate de 2To que j'ai fini par remplacer car le système était au bord du crash total (Problème exposé dans un post précédent).
Le disque dur a été remplacé, les câbles ont été remplacé par des câbles neufs ou récents (avec verrous) et je pensais avoir résolu le problème mais cela n'a duré qu'un jour ou deux ...
Il n'y a plus au total que 10 To de HDD (WD) sur cette machine (depuis remplacement du 2 To du système), 6 To en XFS et 3 To en NTFS en plus du 1 To saucissoné entre Windows et Linux. 8Go de RAM ...
lsblk --output NAME,FSTYPE,SIZE,MODEL,HCTL
NAME FSTYPE SIZE MODEL HCTL
sda 931,5G WDC WD10TPVT-65H 0:0:0:0
├─sda1 ntfs-3g 100M
├─sda2 ntfs-3g 300G
├─sda3 1K
├─sda5 ext2 128M
├─sda6 swap 4G
└─sda7 ext4 627,3G
sdb 2,7T WDC WD30EFRX-68A 1:0:0:0
└─sdb1 xfs 2,7T
sdc 2,7T WDC WD30EZRZ-00Z 2:0:0:0
├─sdc1 128M
└─sdc2 ntfs-3g 2,7T
sdd 2,7T WDC WD30EFRX-68A 3:0:0:0
└─sdd1 xfs 2,7T
Cette machine
Linux athlon 4.4.26-gentoo #3 SMP Fri Dec 16 13:56:52 CET 2016 x86_64 AMD Athlon(tm) 64 X2 Dual Core Processor 4800+ AuthenticAMD GNU/Linuxme sert essentiellement de NAS, de serveur de streaming domestique DLNA (Serviio) et serveur de base (MongoDB / mySQL) Apache PHP, et lance plusieurs bots de collectes de données récupérant et traitant quelques Go chaque 24h + de machine de développement Python.
Elle devrait tourner 24/7 mais est parfois éteinte.
Il y a également un Windows 7 pour test sur cette machine, mais qui n'est jamais mis en route, et de toutes façons je ne pense pas que des problèmes aussi subtils soient facilement identifiés par Windows avant qu'il ne soit trop tard et qu'un disque soit vraiment HS (? je me trompe peut être ?), néanmoins, je peux éventuellement installer des logiciels de tests sur Windows, bien que les problèmes apparaissent à l'usage et que je n'ai aucune utilité sur une telle machine de Windows.
——————————————————————————————————————————
dmesg :
[244890.722072] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
[244890.722082] ata1.00: failed command: SMART
[244890.722089] ata1.00: cmd b0/da:00:00:4f:c2/00:00:00:00:00/00 tag 18
res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
[244890.722092] ata1.00: status: { DRDY }
[244890.722101] ata1: hard resetting link
[244890.722103] ata1: nv: skipping hardreset on occupied port
[244891.176080] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[244891.179234] ata1.00: failed to IDENTIFY (INIT_DEV_PARAMS failed, err_mask=0x80)
[244891.179238] ata1.00: revalidation failed (errno=-5)
[244896.176046] ata1: hard resetting link
[244896.176055] ata1: nv: skipping hardreset on occupied port
[244896.630073] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[244896.636374] ata1.00: configured for UDMA/133
[244896.636429] ata1: EH complete
[248483.100258] ata1: drained 512 bytes to clear DRQ
[248483.100273] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6
[248483.100278] ata1.00: failed command: SMART
[248483.100285] ata1.00: cmd b0/d1:01:00:4f:c2/00:00:00:00:00/00 tag 24 pio 512 in
res 51/84:01:00:4f:c2/00:00:00:00:00/00 Emask 0x10 (ATA bus error)
[248483.100288] ata1.00: status: { DRDY ERR }
[248483.100290] ata1.00: error: { ICRC ABRT }
[248483.100298] ata1: hard resetting link
[248483.100301] ata1: nv: skipping hardreset on occupied port
[248483.554053] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[248483.563191] ata1.00: configured for UDMA/133
[248483.563225] ata1: EH complete
——————————————————————————————————————————
smartctl -l /dev/sda
smartctl 6.4 2015-06-04 r4109 [x86_64-linux-4.4.26-gentoo] (local build)
Copyright (C) 2002-15, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF INFORMATION SECTION ===
Model Family: Western Digital Scorpio Blue Serial ATA (AF)
Device Model: WDC WD10TPVT-65HT5T0
Serial Number: WD-WXK1AA033706
LU WWN Device Id: 5 0014ee 2afe25d57
Firmware Version: 01.01A01
User Capacity: 1 000 204 886 016 bytes [1,00 TB]
Sector Sizes: 512 bytes logical, 4096 bytes physical
Rotation Rate: 5200 rpm
Device is: In smartctl database [for details use: -P show]
ATA Version is: ATA8-ACS (minor revision not indicated)
SATA Version is: SATA 2.6, 3.0 Gb/s
Local Time is: Mon Dec 19 11:29:58 2016 CET
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
General SMART Values:
Offline data collection status: (0x00) Offline data collection activity
was never started.
Auto Offline Data Collection: Disabled.
Self-test execution status: ( 0) The previous self-test routine completed
without error or no self-test has ever
been run.
Total time to complete Offline
data collection: (25200) seconds.
Offline data collection
capabilities: (0x7b) SMART execute Offline immediate.
Auto Offline data collection on/off support.
Suspend Offline collection upon new
command.
Offline surface scan supported.
Self-test supported.
Conveyance Self-test supported.
Selective Self-test supported.
SMART capabilities: (0x0003) Saves SMART data before entering
power-saving mode.
Supports SMART auto save timer.
Error logging capability: (0x01) Error logging supported.
General Purpose Logging supported.
Short self-test routine
recommended polling time: ( 2) minutes.
Extended self-test routine
recommended polling time: ( 289) minutes.
Conveyance self-test routine
recommended polling time: ( 5) minutes.
SCT capabilities: (0x7031) SCT Status supported.
SCT Feature Control supported.
SCT Data Table supported.
SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x002f 200 200 051 Pre-fail Always - 0
3 Spin_Up_Time 0x0027 203 188 021 Pre-fail Always - 2816
4 Start_Stop_Count 0x0032 096 096 000 Old_age Always - 4156
5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail Always - 0
7 Seek_Error_Rate 0x002e 200 200 000 Old_age Always - 0
9 Power_On_Hours 0x0032 055 055 000 Old_age Always - 32906
10 Spin_Retry_Count 0x0032 100 100 000 Old_age Always - 0
11 Calibration_Retry_Count 0x0032 100 100 000 Old_age Always - 0
12 Power_Cycle_Count 0x0032 096 096 000 Old_age Always - 4103
192 Power-Off_Retract_Count 0x0032 198 198 000 Old_age Always - 2227
193 Load_Cycle_Count 0x0032 027 027 000 Old_age Always - 520464
194 Temperature_Celsius 0x0022 113 084 000 Old_age Always - 37
196 Reallocated_Event_Count 0x0032 200 200 000 Old_age Always - 0
197 Current_Pending_Sector 0x0032 200 200 000 Old_age Always - 0
198 Offline_Uncorrectable 0x0030 100 253 000 Old_age Offline - 0
199 UDMA_CRC_Error_Count 0x0032 200 200 000 Old_age Always - 0
200 Multi_Zone_Error_Rate 0x0008 100 253 000 Old_age Offline - 0
SMART Error Log Version: 1
No Errors Logged
SMART Self-test log structure revision number 1
Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error
# 1 Short offline Completed without error 00% 31100 -
# 2 Short offline Completed without error 00% 30804 -
# 3 Short offline Completed without error 00% 30797 -
# 4 Short offline Completed without error 00% 30794 -
# 5 Short offline Completed without error 00% 30744 -
# 6 Short offline Completed without error 00% 30743 -
# 7 Short offline Completed without error 00% 30628 -
# 8 Short offline Completed without error 00% 30575 -
# 9 Short offline Completed without error 00% 30568 -
#10 Short offline Completed without error 00% 30560 -
#11 Short offline Completed without error 00% 30475 -
#12 Short offline Completed without error 00% 30408 -
#13 Short offline Completed without error 00% 30403 -
#14 Short offline Completed without error 00% 30395 -
#15 Short offline Completed without error 00% 30377 -
#16 Short offline Completed without error 00% 30261 -
#17 Short offline Completed without error 00% 30244 -
#18 Short offline Completed without error 00% 30237 -
#19 Short offline Completed without error 00% 30166 -
SMART Selective self-test log data structure revision number 1
SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS
1 0 0 Not_testing
2 0 0 Not_testing
3 0 0 Not_testing
4 0 0 Not_testing
5 0 0 Not_testing
Selective self-test flags (0x0):
After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.
Dans ce rapport SMART on retrouve bien les erreur de déconnexions et je crains que cela ne finisse par générer de vrais problèmes d'écriture avant crash ... Pour l'instant le disque à l'air propre mais le Seagate qui a fini par lâcher (pas violemment mais problèmes écriture/lecture) la semaine dernière a bien fonctionné sur cette machine pendant quelques temps ...
Alors est-ce à votre avis, encore un problème de disque, de câbles, de kernel, de BIOS, de gestion de l'énergie, de contrôleur SATA (donc de CM), je préférerais clairement consacrer mon temps au développement qu'a l'administration du système permettant de faire une partie de ces développements ;-)
A voir également:
- Ata hard resetting link
- Hard discount - Guide
- Hard reset pc - Guide
- Hard disk sentinel - Télécharger - Divers Utilitaires
- Family link localisation - Télécharger - Guide protection
- Hard reset android - Guide
6 réponses
Hello,
Bon je cherche,
Quand on imprime le dmesg avec des heures human readable, je trouve qu'il y a une certaine récurrence dans les heures auxquels apparaissent les problèmes.
dmesg -T |grep frozen
——————————————————————————————————————
Les autres HDD de la machine ont une gestion de l'énergie qui est intégrée au disque, et c'est tant mieux :
sudo hdparm -B /dev/sdd
Par contre le sda
Set the Advanced Power Management feature. Possible values are between 1 and 255, low values mean more aggressive power management and higher values mean better performance. Values from 1 to 127 permit spin-down, whereas values from 128 to 254 do not. A value of 255 completely disables the feature.
Je positionne en 255 et je vais bien voir ...
Là, j'ai pas envie d'aller voir dans le BIOS mais je sais qu'il est possible de sélectionner différents modes de fonctionnement pour le SATA dans le BIOS (très basique) DELL
- Make me a sandwich.
- What? Make it yourself.
- Sudo make me a sandwich.
- Okay
Bon je cherche,
Quand on imprime le dmesg avec des heures human readable, je trouve qu'il y a une certaine récurrence dans les heures auxquels apparaissent les problèmes.
dmesg -T |grep frozen
[ven. déc. 16 20:35:45 2016] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
[sam. déc. 17 08:35:45 2016] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
[sam. déc. 17 16:15:45 2016] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
[sam. déc. 17 20:45:45 2016] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
[dim. déc. 18 03:45:45 2016] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
[dim. déc. 18 13:55:45 2016] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
[lun. déc. 19 02:35:45 2016] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
[lun. déc. 19 02:55:45 2016] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
[lun. déc. 19 03:45:45 2016] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
[lun. déc. 19 10:25:45 2016] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
——————————————————————————————————————
Les autres HDD de la machine ont une gestion de l'énergie qui est intégrée au disque, et c'est tant mieux :
sudo hdparm -B /dev/sdd
/dev/sdd:
APM_level = not supported
Par contre le sda
hdparm -B /dev/sdadonne une valeur de 128, Ce qui semblerait indiquer si j'en crois la doc de hdparm que le spin-down est inhibé (par BIOS, config OS / Kernel, réglage usine HDD ?) mais pas l'apm.
Set the Advanced Power Management feature. Possible values are between 1 and 255, low values mean more aggressive power management and higher values mean better performance. Values from 1 to 127 permit spin-down, whereas values from 128 to 254 do not. A value of 255 completely disables the feature.
Je positionne en 255 et je vais bien voir ...
hdparm -B255 /dev/sda
/dev/sda:
setting Advanced Power Management level to disabled
APM_level = off
Là, j'ai pas envie d'aller voir dans le BIOS mais je sais qu'il est possible de sélectionner différents modes de fonctionnement pour le SATA dans le BIOS (très basique) DELL
- Make me a sandwich.
- What? Make it yourself.
- Sudo make me a sandwich.
- Okay
Bon, j'y ai cru pendant quelques heures mais finalement j'ai eu :
Sinon la régularité du truc est "troublante" et j'ai rien dans une crontab qui pourrait expliquer ça ...
dmesg -T | grep resetting
Comme ça ressemble à un bug libatasmart avec les SSD (même si pour moi ce n'est pas un SSD) de la 14.10 d'Ubuntu je vais me pencher sur la littérature sur le sujet, voir si je peux comprendre le correctif ou chercher du coté de Gentoo et de cette lib maintenant que je sais un peu plus autour de quoi ça tourne, mais mes recherches précédentes n'avaient rien donné de probant. Éventuellement essayer d'upgrader le kernel ou la lib.
L'aspect potentiellement destructeur est confirmé dans ces posts et je l'ai déjà testé.
C'est plus un problème Linux que hdd.
[lun. déc. 19 20:25:38 2016] ata1: drained 510 bytes to clear DRQ
[lun. déc. 19 20:25:38 2016] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6
[lun. déc. 19 20:25:38 2016] ata1.00: failed command: SMART
[lun. déc. 19 20:25:38 2016] ata1.00: cmd b0/d1:01:00:4f:c2/00:00:00:00:00/00 tag 2 pio 512 in
res 51/84:01:00:4f:c2/00:00:00:00:00/00 Emask 0x10 (ATA bus error)
[lun. déc. 19 20:25:38 2016] ata1.00: status: { DRDY ERR }
[lun. déc. 19 20:25:38 2016] ata1.00: error: { ICRC ABRT }
[lun. déc. 19 20:25:38 2016] ata1: hard resetting link
[lun. déc. 19 20:25:38 2016] ata1: nv: skipping hardreset on occupied port
[lun. déc. 19 20:25:38 2016] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[lun. déc. 19 20:25:38 2016] ata1.00: configured for UDMA/133
[lun. déc. 19 20:25:38 2016] ata1: EH complete
Sinon la régularité du truc est "troublante" et j'ai rien dans une crontab qui pourrait expliquer ça ...
dmesg -T | grep resetting
[ven. déc. 16 20:35:45 2016] ata1: hard resetting link
[sam. déc. 17 06:15:38 2016] ata1: hard resetting link
[sam. déc. 17 08:35:45 2016] ata1: hard resetting link
[sam. déc. 17 16:15:45 2016] ata1: hard resetting link
[sam. déc. 17 16:15:51 2016] ata1: hard resetting link
[sam. déc. 17 18:45:38 2016] ata1: hard resetting link
[sam. déc. 17 20:45:45 2016] ata1: hard resetting link
[sam. déc. 17 20:45:51 2016] ata1: hard resetting link
[dim. déc. 18 03:45:45 2016] ata1: hard resetting link
[dim. déc. 18 03:45:51 2016] ata1: hard resetting link
[dim. déc. 18 10:25:38 2016] ata1: hard resetting link
[dim. déc. 18 10:35:38 2016] ata1: hard resetting link
[dim. déc. 18 13:55:45 2016] ata1: hard resetting link
[dim. déc. 18 13:55:51 2016] ata1: hard resetting link
[lun. déc. 19 01:15:38 2016] ata1: hard resetting link
[lun. déc. 19 02:35:45 2016] ata1: hard resetting link
[lun. déc. 19 02:35:51 2016] ata1: hard resetting link
[lun. déc. 19 02:55:45 2016] ata1: hard resetting link
[lun. déc. 19 03:45:45 2016] ata1: hard resetting link
[lun. déc. 19 04:25:38 2016] ata1: hard resetting link
[lun. déc. 19 10:25:45 2016] ata1: hard resetting link
[lun. déc. 19 10:25:51 2016] ata1: hard resetting link
[lun. déc. 19 11:25:38 2016] ata1: hard resetting link
[lun. déc. 19 20:25:38 2016] ata1: hard resetting link
Comme ça ressemble à un bug libatasmart avec les SSD (même si pour moi ce n'est pas un SSD) de la 14.10 d'Ubuntu je vais me pencher sur la littérature sur le sujet, voir si je peux comprendre le correctif ou chercher du coté de Gentoo et de cette lib maintenant que je sais un peu plus autour de quoi ça tourne, mais mes recherches précédentes n'avaient rien donné de probant. Éventuellement essayer d'upgrader le kernel ou la lib.
L'aspect potentiellement destructeur est confirmé dans ces posts et je l'ai déjà testé.
C'est plus un problème Linux que hdd.
LO,
J'ai essayé pas mal de chose, dans le Kernel, le BIOS, avec le matériel, j'ai même été voir les sources de sata_nv et je crois avoir résolu le problème en désactivant dans le BIOS l'activation de tous les ports SATA sauf celui de boot. L'OS se chargeant d'initialiser seul les disques.
Bon je n'aurais confirmation de l'efficacité de la correction que si aucun nouvel incident ne se produit, ce qui peut prendre longtemps. En tout cas la machine a tourné ainsi plus de 12h sans aucun problème.
Apparemment le AHCI n'est pas activé, le contrôleur SATA ne semblant pas en disposer, le BIOS ne proposant aucune option le concernant et l'OS ne semble pas pouvoir corriger ce manque ... Pourtant le contrôleur semble initialisé en SWNCQ, est-ce possible ?
Quoi que je fasse, mon disque le plus récent (acheté le mois dernier et formaté en NTFS) ne tourne qu'a 1,5Gbps. J'ai eu beau le changer d'emplacement, changer le câble, le faire tourner sans autres disques, rien n'y a fait ... Peut être est-ce du à l'absence du AHCI ...
Je vais creuser ça et voir ...
- Make me a sandwich.
- What? Make it yourself.
- Sudo make me a sandwich.
- Okay
J'ai essayé pas mal de chose, dans le Kernel, le BIOS, avec le matériel, j'ai même été voir les sources de sata_nv et je crois avoir résolu le problème en désactivant dans le BIOS l'activation de tous les ports SATA sauf celui de boot. L'OS se chargeant d'initialiser seul les disques.
Bon je n'aurais confirmation de l'efficacité de la correction que si aucun nouvel incident ne se produit, ce qui peut prendre longtemps. En tout cas la machine a tourné ainsi plus de 12h sans aucun problème.
Apparemment le AHCI n'est pas activé, le contrôleur SATA ne semblant pas en disposer, le BIOS ne proposant aucune option le concernant et l'OS ne semble pas pouvoir corriger ce manque ... Pourtant le contrôleur semble initialisé en SWNCQ, est-ce possible ?
00:0e.0 IDE interface [0101]: NVIDIA Corporation MCP51 Serial ATA Controller [10de:0266] (rev a1)
00:0f.0 IDE interface [0101]: NVIDIA Corporation MCP51 Serial ATA Controller [10de:0267] (rev a1)
Quoi que je fasse, mon disque le plus récent (acheté le mois dernier et formaté en NTFS) ne tourne qu'a 1,5Gbps. J'ai eu beau le changer d'emplacement, changer le câble, le faire tourner sans autres disques, rien n'y a fait ... Peut être est-ce du à l'absence du AHCI ...
ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
Je vais creuser ça et voir ...
libata version 3.00 loaded.
sata_nv 0000:00:0e.0: version 3.5
sata_nv 0000:00:0e.0: Using SWNCQ mode
scsi host0: sata_nv
scsi host1: sata_nv
ata1: SATA max UDMA/133 cmd 0x9f0 ctl 0xbf0 bmdma 0xe000 irq 21
ata2: SATA max UDMA/133 cmd 0x970 ctl 0xb70 bmdma 0xe008 irq 21
sata_nv 0000:00:0f.0: Using SWNCQ mode
scsi host2: sata_nv
scsi host3: sata_nv
ata3: SATA max UDMA/133 cmd 0x9e0 ctl 0xbe0 bmdma 0xcc00 irq 20
ata4: SATA max UDMA/133 cmd 0x960 ctl 0xb60 bmdma 0xcc08 irq 20
ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata3.00: ATA-9: WDC WD30EZRZ-00Z5HB0, 80.00A80, max UDMA/133
ata3.00: 5860533168 sectors, multi 0: LBA48 NCQ (depth 31/32)
ata3.00: configured for UDMA/133
ata1.00: ATA-8: WDC WD10TPVT-65HT5T0, 01.01A01, max UDMA/133
ata1.00: 1953525168 sectors, multi 16: LBA48 NCQ (depth 31/32)
ata1.00: configured for UDMA/133
ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata2.00: ATA-9: WDC WD30EFRX-68AX9N0, 80.00A80, max UDMA/133
ata2.00: 5860533168 sectors, multi 0: LBA48 NCQ (depth 31/32)
ata2.00: configured for UDMA/133
ata4: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata4.00: ATA-9: WDC WD30EFRX-68AX9N0, 80.00A80, max UDMA/133
ata4.00: 5860533168 sectors, multi 0: LBA48 NCQ (depth 31/32)
ata4.00: configured for UDMA/133
- Make me a sandwich.
- What? Make it yourself.
- Sudo make me a sandwich.
- Okay
Apparemment, même, si mon workaround fonctionne, je viens de trouver dans le WIKI d'ata :
MCP51 (some nForce 4xx) and MCP55 (nForce 5xx) chipsets support NCQ (but no 64-bit DMA) using the chipset's SWNCQ interface. This support is now enabled by default. It can be disabled using the swncq=0 module option to sata_nv. The MCP61 chipset also has SWNCQ support, but apparently it can't be used with this chipset due to hardware bugs.
NOTE: Newer NVIDIA chipsets are AHCI, and use the ahci driver rather than the sata_nv driver
Donc je continue de creuser je vais voir à mon prochain reboot ...
MCP51 (some nForce 4xx) and MCP55 (nForce 5xx) chipsets support NCQ (but no 64-bit DMA) using the chipset's SWNCQ interface. This support is now enabled by default. It can be disabled using the swncq=0 module option to sata_nv. The MCP61 chipset also has SWNCQ support, but apparently it can't be used with this chipset due to hardware bugs.
NOTE: Newer NVIDIA chipsets are AHCI, and use the ahci driver rather than the sata_nv driver
Donc je continue de creuser je vais voir à mon prochain reboot ...
Comme je pense avoir résolu le problème en retirant du BIOS tous les disques (ports SATA éteints) sauf le disque de boot, puis en transmettant
dmesg -t | grep BOOT_IMAGE
Plus de problème de freeze du disque après un hard reset, qui est la méthode d’interrogation du driver sata_nv mais qui est inappropriée avec des disques fonctionnant sur un contrôleur nVidia MCP51. Plus de problème de "sector mismatch" apparaissant sur tel ou tel disque aléatoirement au boot et correspondant à une mauvaise reconnaissance des disques pas le BIOS.
Restreindre le travail du BIOS à l'identification du seul disque de boot permets de contourner le problème. L'OS, disposant d'un peu plus d'outils qu'un BIOS, plus tard dans le boot,pour identifier et initialiser correctement contrôleurs et disques.
sata_nv semble déléguer davantage la gestion du contrôleur à sata_core en passant l'option swncq=0 au module sata_nv ...
Seul souci mais vraiment mineur par rapport aux problèmes initiaux, le WDC WD30EZRZ qui refuse de fonctionner à 3.0 Gbps, mais je n'ai fait aucun tests de vitesse de transferts avec les autres disques, les débits affichés par les autres disques sont donc purement théoriques. Du NCQ mais pas d'AHCI.
dmesg -t (extraits)
- Make me a sandwich.
- What? Make it yourself.
- Sudo make me a sandwich.
- Okay
sata_nv.swncq=0au module sata du kernel, je vais passer la question en résolue.
dmesg -t | grep BOOT_IMAGE
Command line: BOOT_IMAGE=/vmlinuz-4.4.26-gentoo root=/dev/sda7 ro sata_nv.swncq=0 raid=noautodetect
Plus de problème de freeze du disque après un hard reset, qui est la méthode d’interrogation du driver sata_nv mais qui est inappropriée avec des disques fonctionnant sur un contrôleur nVidia MCP51. Plus de problème de "sector mismatch" apparaissant sur tel ou tel disque aléatoirement au boot et correspondant à une mauvaise reconnaissance des disques pas le BIOS.
Restreindre le travail du BIOS à l'identification du seul disque de boot permets de contourner le problème. L'OS, disposant d'un peu plus d'outils qu'un BIOS, plus tard dans le boot,pour identifier et initialiser correctement contrôleurs et disques.
sata_nv semble déléguer davantage la gestion du contrôleur à sata_core en passant l'option swncq=0 au module sata_nv ...
Seul souci mais vraiment mineur par rapport aux problèmes initiaux, le WDC WD30EZRZ qui refuse de fonctionner à 3.0 Gbps, mais je n'ai fait aucun tests de vitesse de transferts avec les autres disques, les débits affichés par les autres disques sont donc purement théoriques. Du NCQ mais pas d'AHCI.
dmesg -t (extraits)
SCSI subsystem initialized
libata version 3.00 loaded.
sata_nv 0000:00:0e.0: version 3.5
scsi host0: sata_nv
scsi host1: sata_nv
ata1: SATA max UDMA/133 cmd 0x9f0 ctl 0xbf0 bmdma 0xe000 irq 21
ata2: SATA max UDMA/133 cmd 0x970 ctl 0xb70 bmdma 0xe008 irq 21
ACPI: PCI Interrupt Link [APSJ] enabled at IRQ 20
scsi host2: sata_nv
scsi host3: sata_nv
ata3: SATA max UDMA/133 cmd 0x9e0 ctl 0xbe0 bmdma 0xcc00 irq 20
ata4: SATA max UDMA/133 cmd 0x960 ctl 0xb60 bmdma 0xcc08 irq 20
ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata1.00: ATA-8: WDC WD10TPVT-65HT5T0, 01.01A01, max UDMA/133
ata1.00: 1953525168 sectors, multi 16: LBA48 NCQ (depth 0/32)
ata3.00: ATA-9: WDC WD30EZRZ-00Z5HB0, 80.00A80, max UDMA/133
ata3.00: 5860533168 sectors, multi 0: LBA48 NCQ (depth 0/32)
ata1.00: configured for UDMA/133
scsi 0:0:0:0: Direct-Access ATA WDC WD10TPVT-65H 1A01 PQ: 0 ANSI: 5
sd 0:0:0:0: [sda] 1953525168 512-byte logical blocks: (1.00 TB/932 GiB)
sd 0:0:0:0: [sda] 4096-byte physical blocks
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
sd 0:0:0:0: Attached scsi generic sg0 type 0
ata3.00: configured for UDMA/133
sda: sda1 sda2 sda3 < sda5 sda6 sda7 >
ata2.00: ATA-9: WDC WD30EFRX-68AX9N0, 80.00A80, max UDMA/133
ata2.00: 5860533168 sectors, multi 0: LBA48 NCQ (depth 0/32)
ata2.00: configured for UDMA/133
scsi 1:0:0:0: Direct-Access ATA WDC WD30EFRX-68A 0A80 PQ: 0 ANSI: 5
sd 1:0:0:0: [sdb] 5860533168 512-byte logical blocks: (3.00 TB/2.73 TiB)
sd 1:0:0:0: [sdb] 4096-byte physical blocks
sd 1:0:0:0: [sdb] Write Protect is off
sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00
sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
sd 1:0:0:0: Attached scsi generic sg1 type 0
scsi 2:0:0:0: Direct-Access ATA WDC WD30EZRZ-00Z 0A80 PQ: 0 ANSI: 5
sd 2:0:0:0: [sdc] 5860533168 512-byte logical blocks: (3.00 TB/2.73 TiB)
sd 2:0:0:0: [sdc] 4096-byte physical blocks
sd 2:0:0:0: [sdc] Write Protect is off
sd 2:0:0:0: [sdc] Mode Sense: 00 3a 00 00
sd 2:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
sd 2:0:0:0: Attached scsi generic sg2 type 0
sdb: sdb1
sd 1:0:0:0: [sdb] Attached SCSI disk
usb 2-6: new low-speed USB device number 3 using ohci-pci
ata4: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata4.00: ATA-9: WDC WD30EFRX-68AX9N0, 80.00A80, max UDMA/133
ata4.00: 5860533168 sectors, multi 0: LBA48 NCQ (depth 0/32)
ata4.00: configured for UDMA/133
scsi 3:0:0:0: Direct-Access ATA WDC WD30EFRX-68A 0A80 PQ: 0 ANSI: 5
sd 3:0:0:0: Attached scsi generic sg3 type 0
sd 3:0:0:0: [sdd] 5860533168 512-byte logical blocks: (3.00 TB/2.73 TiB)
sd 3:0:0:0: [sdd] 4096-byte physical blocks
sd 3:0:0:0: [sdd] Write Protect is off
sd 3:0:0:0: [sdd] Mode Sense: 00 3a 00 00
sd 3:0:0:0: [sdd] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
sdc: sdc1 sdc2
sd 2:0:0:0: [sdc] Attached SCSI disk
sdd: sdd1
sd 3:0:0:0: [sdd] Attached SCSI disk
- Make me a sandwich.
- What? Make it yourself.
- Sudo make me a sandwich.
- Okay
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
Hello et bonne année à toutes et tous,
j'ai continué à travailler sur ce problème, à changer des choses dans le BIOS, dans le kernel, à passer des paramètres à libata, à lire la doc du kernel, d'ATA, les spécifications des normes et l'apparition du problème de hard reset, suivi d'un freeze le plus souvent non-bloquant survient de plus en plus rarement, voir ces dernières 36 heures, plus du tout ...
Comme il n'est pas possible de retirer le disque de boot du BIOS, ce qui a solutionné les problème de "sector mismatch" aléatoire apparaissant sur les disques avant qu'ils ne soient plus déclaré dans le BIOS, le BIOS étant apparemment dépassé par les capacités disques. J'ai finalement rajouté à la ligne lançant le kernel dans grub :
Suspectant le problème majeur d'être principalement lié à une histoire de gestion de l'énergie (régularité dans le temps des pannes), j'ai également les options :
Effet de bord à la suite de l'ajout de ces options, le message :
Il faudra que je trouve quelle option est réellement décisive de façon à supprimer les autres, et potentiellement celle provocant l'apparition de ces messages, car Cool'N'Quiet est bien activé dans le BIOS et je suis certains que c'est apparu suite à l'ajout d'une de ces options.
J'ai également conservé :
plus un zeste de
Ma ligne complète de boot, qui se modifie dans le fichier
Les options
Ce qui donne :
Voilà, si ça peut en aider certains ...
Avec ces options, plus, peut être, certains choix de compilation du kernel, le système ne semble plus présenter de dysfonctionnement lié au disque de boot.
Comme parfois, entre 2 modifications, le problème mets plus de 24h à réapparaître et que je ne veux plus du tout de ce message d'erreur et surtout de ses possibles conséquences (blocage système), je continue de surveiller et garde encore quelques cartes dans ma manche pour lui tordre le cou au cas ou ...
- Make me a sandwich.
- What? Make it yourself.
- Sudo make me a sandwich.
- Okay
j'ai continué à travailler sur ce problème, à changer des choses dans le BIOS, dans le kernel, à passer des paramètres à libata, à lire la doc du kernel, d'ATA, les spécifications des normes et l'apparition du problème de hard reset, suivi d'un freeze le plus souvent non-bloquant survient de plus en plus rarement, voir ces dernières 36 heures, plus du tout ...
Comme il n'est pas possible de retirer le disque de boot du BIOS, ce qui a solutionné les problème de "sector mismatch" aléatoire apparaissant sur les disques avant qu'ils ne soient plus déclaré dans le BIOS, le BIOS étant apparemment dépassé par les capacités disques. J'ai finalement rajouté à la ligne lançant le kernel dans grub :
libata.ignore_hpa=1. Peut être pourrais rajouter les disques dans le BIOS maintenant, mais vu que cela fonctionne sans, peu m'importe.
Suspectant le problème majeur d'être principalement lié à une histoire de gestion de l'énergie (régularité dans le temps des pannes), j'ai également les options :
noapic acpi=offet
libata.noacpi=1...
Effet de bord à la suite de l'ajout de ces options, le message :
powernow_k8: [Firmware Bug]: No compatible ACPI _PSS objects found.
[Firmware Bug]: First, make sure Cool'N'Quiet is enabled in the BIOS.
[Firmware Bug]: If that doesn't help, try upgrading your BIOS.
powernow_k8: Found 1 AMD Athlon(tm) 64 X2 Dual Core Processor 4800+ (2 cpu cores) (version 2.20.00)
Il faudra que je trouve quelle option est réellement décisive de façon à supprimer les autres, et potentiellement celle provocant l'apparition de ces messages, car Cool'N'Quiet est bien activé dans le BIOS et je suis certains que c'est apparu suite à l'ajout d'une de ces options.
J'ai également conservé :
hdparm -B255 /dev/sda
/dev/sda:
setting Advanced Power Management level to disabled
APM_level = off
plus un zeste de
sata_nv.swncq=0pour mon contrôleur SATA nVidia MCP51
Ma ligne complète de boot, qui se modifie dans le fichier
/etc/default/grubdans un système Linux Gentoo, avant de lancer l'update de grub
grub-mkconfig -o /boot/grub/grub.cfg(après avoir testé dans le menu de grub en "édition volatile" que ça ne provoquait pas d'erreur) est donc :
GRUB_CMDLINE_LINUX_DEFAULT="sata_nv.swncq=0 raid=noautodetect rootfstype=ext4 panic=15 noapic acpi=off hpet=force pci=usepirqmask libata.ignore_hpa=1 libata.noacpi=1"
Les options
raid=noautodetectétant relatives à d'autres problèmes, permettant de désactiver ou d'activer des options bas niveau, de supprimer des messages inutiles, ou de permettre (comme panic=15) le reboot auto du système au bout de 15sec. en cas de crash du kernel.
rootfstype=ext4
panic=15
hpet=force
pci=usepirqmask
Ce qui donne :
# cat /proc/cmdline
BOOT_IMAGE=/vmlinuz-4.4.26-gentoo root=/dev/sda7 ro sata_nv.swncq=0 raid=noautodetect rootfstype=ext4 panic=15 noapic acpi=off hpet=force pci=usepirqmask libata.ignore_hpa=1 libata.noacpi=1
Voilà, si ça peut en aider certains ...
Avec ces options, plus, peut être, certains choix de compilation du kernel, le système ne semble plus présenter de dysfonctionnement lié au disque de boot.
Comme parfois, entre 2 modifications, le problème mets plus de 24h à réapparaître et que je ne veux plus du tout de ce message d'erreur et surtout de ses possibles conséquences (blocage système), je continue de surveiller et garde encore quelques cartes dans ma manche pour lui tordre le cou au cas ou ...
- Make me a sandwich.
- What? Make it yourself.
- Sudo make me a sandwich.
- Okay
Hello,
suite et fin, j'espère. Malgré toute ces corrections, j'ai continué d'avoir ces problèmes de :
N'ayant pas de carte vidéo pour cette nouvelle machine j'ai récupéré celle du serveur qui avait ces problèmes de disque avec pour conséquence qu' X ne démarre plus dessus (je ne l'ai pas reconfigurée pour l'instant, n'ayant de toutes façon pas d'écran pour elle et X n'y étant pas indispensable), depuis, incidemment je n'ai plus non plus, un seul message d'erreur après une semaine d'uptime (Pourvu que ça dure cette fois) ... A priori soit X, soit une interaction entre la CG et la CM provoquait ce problème ... Étrange ...
Du coup je me retrouve maintenant avec 2 bécanes qui fonctionnent parfaitement.
Après tout, tant mieux, je voulais tester de la réplications master/master, du cluster et d'autres choses sur plusieurs types de SGBD et centraliser des versions pour pouvoir faire tourner des versions équivalentes de mes progs sur toutes mes machines.
- Make me a sandwich.
- What? Make it yourself.
- Sudo make me a sandwich.
- Okay
suite et fin, j'espère. Malgré toute ces corrections, j'ai continué d'avoir ces problèmes de :
ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozenà raison de 1 ou 2 fois par jour, mais qui finissaient par freezer le système et nécessitaient un reboot. Tant et si bien que j'ai racheté une autre machine (un Intel(R) Pentium(R) CPU G850 @ 2.90GHz ).
N'ayant pas de carte vidéo pour cette nouvelle machine j'ai récupéré celle du serveur qui avait ces problèmes de disque avec pour conséquence qu' X ne démarre plus dessus (je ne l'ai pas reconfigurée pour l'instant, n'ayant de toutes façon pas d'écran pour elle et X n'y étant pas indispensable), depuis, incidemment je n'ai plus non plus, un seul message d'erreur après une semaine d'uptime (Pourvu que ça dure cette fois) ... A priori soit X, soit une interaction entre la CG et la CM provoquait ce problème ... Étrange ...
Du coup je me retrouve maintenant avec 2 bécanes qui fonctionnent parfaitement.
Après tout, tant mieux, je voulais tester de la réplications master/master, du cluster et d'autres choses sur plusieurs types de SGBD et centraliser des versions pour pouvoir faire tourner des versions équivalentes de mes progs sur toutes mes machines.
- Make me a sandwich.
- What? Make it yourself.
- Sudo make me a sandwich.
- Okay
non ça c'est pour la partie "data mining", quelques Go par jours ça fait vite du To ...
Une grosse partie des données mériteraient sans doute la poubelle, mais faire le tri dans des To demanderait des semaines d'un boulot pas marrant ...
En fait ce système tournait depuis plusieurs années sur une autre machine avec les mêmes finalités, et en moins d'un an 2 serveurs (des PC qui avaient 15 ans et jamais fait de problèmes) m'ont lâché successivement.
Des fois je m'y colle et je gagne quelques centaine de Go ...
Sinon oui j'ai des trucs qui testent pour éviter les redondances dans la récupération, mais en même temps la qualité des données évolue, je dois donc faire évoluer les critères de sélection ... Enfin, voilà, je m'occupe :-)
Pour ma part, la *dernière fois* que j'ai eu des symptômes similaire et où j'ai eu 2 HDD qui ont crashés en moins de 3 mois, "sans raison" ... et successivement, j'ai fini par fouiller plus loin, puisque j'avais déjà changé les câbles SATA data, mais pas SATA power... au final, ça venait de l'alimentation qui pour une raison que j'ignore avait un souci sur le câble de "sata power" que j'utilisais pour ce disque là... j'ai plus jamais utilisé ce câble là, plus eu de souci... J'ai re-testé avec un disque neuf une fois, même problème, donc... le tour a été fait, puisque c'était lui en tord, j'ai fini par changer l'alimentation.
en fait j'ai du changer de câble d'alim. le disque car je suis passé d'un 3"1/2 à un 2"1/2 et que sur les machines DELL c'est super intégré. J'ai donc récupéré le tiroir de l'ancien disque système (et l'alim qui tombait juste en face) pour un disque de données qui ne s'en plaint pas et le nouveau disque système se promène calé entre 3 paquets de clops vides là ou il y eut sans doute un lecteur de DVD il y a longtemps mais avec un autre câble d'alim.
Sinon il consomme probablement moins que l'ancien (mais j'ai pas vérifié) et puis la régularité de l'apparition du problème m'incite de plus en plus à pencher pour un problème soft, bien que j'ai lu que certains semblent avoir détruit des grappes raid avec des bugs similaires. Je vais essayer d'upgrader le kernel ou de changer des libs, aller lire les doc de sata_nv, les sources dans le kernel ...
Avec Gentoo on peut faire pas mal de chose. Ce qui m'inquiète le plus, c'est de trouver personne d'autres avec le même problème, mais bon c'est pas la première fois, Linux c'est pas non plus des milliards d'utilisateurs ...