Re: ata4.00: failedcommand: WRITE DMA EXT
Hallo zusammen,
ich stelle fest das ich seit ein paar Wochen vermutlich nach einem
Kernelupdate und Reboot des Servers. Mein S-ATA BUS zwischen der speed
1,5 und 3Gbps wechselt. Die Controlerhardware kann nur 1.5 Gbps die
Festplatten können mehr.
Wie kann ich mehr Informationen zu meinem s-ata Treiber finden? (welchen
Befehl, gibt eine manpage?)
Ich würde gerne wissen welche options man für diesem Treiber in der
Datei /etc/modules setzen kann?
Wie kann ich solche Infos aus dem System abfagen? Bzw. An welcher stelle
würde man üblicherweise suchen?
Ich möchte gerne per /etc/modules.conf die speed fest auf 1,5Gbps
stellen und dann die Störung weiter beobachten.
Ich habe diesen Treiber:
root# modinfo sata_nv
filename: /lib/modules/2.6.32-5-openvz-amd64/kernel/drivers/ata/sata_nv.ko
version: 3.5
license: GPL
description: low-level driver for NVIDIA nForce SATA controller
author: NVIDIA
srcversion: 25283EFC1165AF480C6FEED
alias: pci:v000010DEd000003F7sv*sd*bc*sc*i*
alias: pci:v000010DEd000003F6sv*sd*bc*sc*i*
alias: pci:v000010DEd000003E7sv*sd*bc*sc*i*
alias: pci:v000010DEd0000037Fsv*sd*bc*sc*i*
alias: pci:v000010DEd0000037Esv*sd*bc*sc*i*
alias: pci:v000010DEd00000267sv*sd*bc*sc*i*
alias: pci:v000010DEd00000266sv*sd*bc*sc*i*
alias: pci:v000010DEd0000003Esv*sd*bc*sc*i*
alias: pci:v000010DEd00000036sv*sd*bc*sc*i*
alias: pci:v000010DEd00000055sv*sd*bc*sc*i*
alias: pci:v000010DEd00000054sv*sd*bc*sc*i*
alias: pci:v000010DEd000000EEsv*sd*bc*sc*i*
alias: pci:v000010DEd000000E3sv*sd*bc*sc*i*
alias: pci:v000010DEd0000008Esv*sd*bc*sc*i*
depends: libata
vermagic: 2.6.32-5-openvz-amd64 SMP mod_unload modversions
parm: adma:Enable use of ADMA (Default: false) (bool)
parm: swncq:Enable use of SWNCQ (Default: true) (bool)
parm: msi:Enable use of MSI (Default: false) (bool)
siehe logs:
kern.log:Jul 29 18:33:41 lvzs102a kernel: [159895.672443] ata1: SATA
link up 3.0 Gbps (SStatus 123 SControl 300)
kern.log:Aug 1 11:02:06 lvzs102a kernel: [392016.017202] ata1: SATA
link up 1.5 Gbps (SStatus 113 SControl 310)
kern.log:Aug 1 20:12:34 lvzs102a kernel: [425044.345079] ata1: SATA
link up 3.0 Gbps (SStatus 123 SControl 300)
kern.log.1:Jul 27 22:00:21 lvzs102a kernel: [1290405.516259] ata3: SATA
link up 3.0 Gbps (SStatus 123 SControl 300)
kern.log.1:Jul 27 22:00:50 lvzs102a kernel: [1290434.564041] ata4: SATA
link up 3.0 Gbps (SStatus 123 SControl 300)
kern.log.1:Jul 27 22:09:01 lvzs102a kernel: [ 1.388029] ata1: SATA
link up 3.0 Gbps (SStatus 123 SControl 300)
kern.log.1:Jul 27 22:09:01 lvzs102a kernel: [ 1.889025] ata2: SATA
link up 3.0 Gbps (SStatus 123 SControl 300)
kern.log.1:Jul 28 17:10:45 lvzs102a kernel: [68514.843465] ata1: SATA
link up 1.5 Gbps (SStatus 113 SControl 310)
ata1: hard resetting link
ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
Am 17.07.2012 08:48, schrieb Paulo Aires:
Hallo zusammen,
vielen Dank für die bisherigen Tips.
Da S-ATA Laufwerke unter Linux wie gewöhnliche SCSI Laufwerke angesprochen werden hätte ich selsbt drauf kommen können, schlißlich habe ich es schon oft genug den SCSI Bus neu gescannt.
Ein SCSI Laufwerk asu dem Device-tree löschen geht wie folgt:
z.b. /dev/sdb
echo "1" > /sys/block/sdb/device/delete
In meinem Fall ist ja aus /dev/sdb ein /dev/sdc geworden deshalb hatte ich gedacht ich könnte mal versuchen beide aus dem System zu löschen und den BUS neu einzuscannen.
echo "1" > /sys/block/sdc/device/delete
Dann den SCSI-BUS (S-ATA BUS) neu einscannen.
Meinem lsscsi Output nach hängt die Festplatte an Controller 3, deshlab scanne ich den scsi controller host3
lsscsi
[2:0:0:0] disk ATA WDC WD7501AALS-7 05.0 /dev/sda
[3:0:0:0] disk ATA WDC WD7501AALS-7 05.0 /dev/sdc
echo "- - -" > /sys/class/scsi_host/host3/scan
Die Festpaltte wurde auch ganz normal wieder erkannt und eingebunden. Leider ist mein Plan nicht aufgegangen weil sich /dev/sdb nicht löschen lies es exitierte bereits nicht mehr. Und nun habe ich eine /dev/sdd.
Nun die Platte in das Software Raid wieder aufgenommen mit:
mdadm -a /dev/md0 /dev/sdd1
mdadm -a /dev/md1 /dev/sdd3
etc.
Die RAID syncronisation läuft normal und ich bezweifle das es wirklich ein Hardware defekt ist. Ich vermute das sich irgend ein falscher Treiber nach dem Kernel-Update eingeschlichen hat. Ich werde mal mit smart Testen und das Ergebnis hier presentieren und bei google weiter wuchen evtl. finde ich ja etwas brauchbares.
Bis Bald
Reply to: