5
Fehler write fpdma queued
Hallo zusammen,
bei dem Versuch einen Backup-Server unter Linux einzurichten, bin ich auf ein Problem gestossen.
Der Server ist ein Asus-Board M5A97 EVO R2.0 mit aktuellem Bios, darauf ein PCIe Adaptec Raid-Controller 6405E mit aktueller Firmware, daran 2 SATA Platten WD30PURX im Raid1, welches als Datenspeicher dienen soll. Das OS läuft separat auf einer SSD, welche direkt am Mainboard hängt.
Als System läuft ein Host mit Debian 9 stable, und darauf ein Virtualbox-Gast (ein Webserver im Internet mit ebenfalls Debian 9), welcher Daten von anderen Servern zum Backup runterladen soll.
Die ersten Tests unter Last liefen aber extrem träge ab, weshalb ich mal auf dem Host ins Syslog geschaut habe.
Dort fand ich diese feinen Einträge:
Wenn man mal nach dem "WRITE FPDMA QUEUED" googelt, kommt da irgendwas von SATA-Kabel getauscht oder Netzteil getauscht.
Kann ich aber bei mir nicht wirklich nachvollziehen.
Das SATA-Kabel ist so'n Y-Adapter vom Raid-Controller mit Anschlüssen für bis zu 4 Platten, gerade erst neu gekauft. Ich habe die beiden Platten mal an die anderen beiden Anschlüsse angeschlossen - ohne Änderung.
Mich wundert einfach auch ein bisschen, dass das Problem in einem Raid1 auftritt. Wäre das SATA-Kabel einer Platte betroffen, müsste diese ja eigentlich aus dem Raid fliegen, oder?
Das RAID ist aber angeblich in Ordnung.
Und das beide Plattenanschlußkabel den selben Fehler haben? Hm, ich weiss nicht.
Irgendwelche Ratschläge, wie ich den Fehler einkreisen kann?
Vielen Dank vorab!
Gruß,
Colt
bei dem Versuch einen Backup-Server unter Linux einzurichten, bin ich auf ein Problem gestossen.
Der Server ist ein Asus-Board M5A97 EVO R2.0 mit aktuellem Bios, darauf ein PCIe Adaptec Raid-Controller 6405E mit aktueller Firmware, daran 2 SATA Platten WD30PURX im Raid1, welches als Datenspeicher dienen soll. Das OS läuft separat auf einer SSD, welche direkt am Mainboard hängt.
Als System läuft ein Host mit Debian 9 stable, und darauf ein Virtualbox-Gast (ein Webserver im Internet mit ebenfalls Debian 9), welcher Daten von anderen Servern zum Backup runterladen soll.
Die ersten Tests unter Last liefen aber extrem träge ab, weshalb ich mal auf dem Host ins Syslog geschaut habe.
Dort fand ich diese feinen Einträge:
Jan 31 22:27:59 host1 kernel: [10200.424656] ata1.00: exception Emask 0x10 SAct 0x7e003fff SErr 0x400000 action 0x6 frozen
Jan 31 22:27:59 host1 kernel: [10200.424662] ata1.00: irq_stat 0x08000000, interface fatal error
Jan 31 22:27:59 host1 kernel: [10200.424665] ata1: SError: { Handshk }
Jan 31 22:27:59 host1 kernel: [10200.424668] ata1.00: failed command: WRITE FPDMA QUEUED
Jan 31 22:27:59 host1 kernel: [10200.424674] ata1.00: cmd 61/80:00:80:c2:cd/00:00:00:00:00/40 tag 0 ncq dma 65536 out
Jan 31 22:27:59 host1 kernel: [10200.424674] res 40/00:c8:00:b2:cd/00:00:00:00:00/40 Emask 0x10 (ATA bus error)
Jan 31 22:27:59 host1 kernel: [10200.424677] ata1.00: status: { DRDY }
Jan 31 22:27:59 host1 kernel: [10200.424679] ata1.00: failed command: WRITE FPDMA QUEUED
Jan 31 22:27:59 host1 kernel: [10200.424684] ata1.00: cmd 61/80:08:80:c4:cd/00:00:00:00:00/40 tag 1 ncq dma 65536 out
Jan 31 22:27:59 host1 kernel: [10200.424684] res 40/00:c8:00:b2:cd/00:00:00:00:00/40 Emask 0x10 (ATA bus error)
Jan 31 22:27:59 host1 kernel: [10200.424686] ata1.00: status: { DRDY }
...
an 31 22:27:59 host1 kernel: [10200.424850] ata1: hard resetting link
Jan 31 22:27:59 host1 kernel: [10200.900663] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 320)
Jan 31 22:27:59 host1 kernel: [10200.900912] ata1.00: supports DRM functions and may not be fully accessible
Jan 31 22:27:59 host1 kernel: [10200.901609] ata1.00: disabling queued TRIM support
Jan 31 22:27:59 host1 kernel: [10200.902082] ata1.00: supports DRM functions and may not be fully accessible
Jan 31 22:27:59 host1 kernel: [10200.902721] ata1.00: disabling queued TRIM support
Jan 31 22:27:59 host1 kernel: [10200.902920] ata1.00: configured for UDMA/133
Jan 31 22:27:59 host1 kernel: [10200.903001] ata1: EH completeWenn man mal nach dem "WRITE FPDMA QUEUED" googelt, kommt da irgendwas von SATA-Kabel getauscht oder Netzteil getauscht.
Kann ich aber bei mir nicht wirklich nachvollziehen.
Das SATA-Kabel ist so'n Y-Adapter vom Raid-Controller mit Anschlüssen für bis zu 4 Platten, gerade erst neu gekauft. Ich habe die beiden Platten mal an die anderen beiden Anschlüsse angeschlossen - ohne Änderung.
Mich wundert einfach auch ein bisschen, dass das Problem in einem Raid1 auftritt. Wäre das SATA-Kabel einer Platte betroffen, müsste diese ja eigentlich aus dem Raid fliegen, oder?
Das RAID ist aber angeblich in Ordnung.
Und das beide Plattenanschlußkabel den selben Fehler haben? Hm, ich weiss nicht.
Irgendwelche Ratschläge, wie ich den Fehler einkreisen kann?
Vielen Dank vorab!
Gruß,
Colt
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 363114
Url: https://administrator.de/forum/fehler-write-fpdma-queued-363114.html
Ausgedruckt am: 07.04.2025 um 02:04 Uhr
5 Kommentare
Neuester Kommentar
Moin,
ich fasse das mal zusammen. Du betreibst einen Linux-"Server" mit einem Desktop-Board welches Auf Windows 8 optimiert wurde?
Komisch, dass das nicht funktioniert...
Vielleicht hast du aber Glück und es ist tatsächlich nur die Stromversorgung.
Ansonsten mal die Bios-Einstellungen prüfen - wird beim Motherboard sicherlich lustig.
Gruß
ich fasse das mal zusammen. Du betreibst einen Linux-"Server" mit einem Desktop-Board welches Auf Windows 8 optimiert wurde?
Komisch, dass das nicht funktioniert...
Vielleicht hast du aber Glück und es ist tatsächlich nur die Stromversorgung.
Ansonsten mal die Bios-Einstellungen prüfen - wird beim Motherboard sicherlich lustig.
Gruß
Nun ja, es läuft ja nicht mit Windows8-Treibern, sondern mit den Treibern, die Debian stable(!) mitliefert, bzw Adaptec.
Welche Bios-Einstellungen meinst Du? Welche Bios-Einstellungen verursachen diesen Fehler denn?
Welche Bios-Einstellungen meinst Du? Welche Bios-Einstellungen verursachen diesen Fehler denn?
Halloelle,
Und der RAID-Kontroller wird vollumfaenglich unterstuetzt unter Debian 9? Bzw setzt Du auch den Treber des Herstellers dafuer ein?
Da Du ja eh ein Daddelboard benutzt, waere es doch eine Idee die beiden WD30PURX als RAID1 direkt ab Board zu betreiben, oder? Spart etwas Strom am PCIe.
Desweiteren nimm den RAID nochmal auseinander und checke die Gesundheit (SMART-Werte) der Festplatten einzeln.
BFF
Und der RAID-Kontroller wird vollumfaenglich unterstuetzt unter Debian 9? Bzw setzt Du auch den Treber des Herstellers dafuer ein?
Da Du ja eh ein Daddelboard benutzt, waere es doch eine Idee die beiden WD30PURX als RAID1 direkt ab Board zu betreiben, oder? Spart etwas Strom am PCIe.
Desweiteren nimm den RAID nochmal auseinander und checke die Gesundheit (SMART-Werte) der Festplatten einzeln.
BFF
Wenn es nicht die Stromversorgung ist - und ich gehe im Moment davon aus, dass die der Verursacher ist - dann würde ich alles in Richtung CPU und PCI(-E) geht prüfen. Kann ein Timing-Problem sein oder falsch eingestellte Spannungen wegen Overclocking und ähnliches.
Allerdings würde ich bei der Beschreibung nicht einmal mehr anfangen zu suchen (bis auf Netzteil)
Spielzeug
Allerdings würde ich bei der Beschreibung nicht einmal mehr anfangen zu suchen (bis auf Netzteil)
Dual Intelligent Processors 3-Technologie inklusive dem neuen DIGI+ Power Control - Volle Hardware-Kontrolle - Umfassende Leistungssteigerung
Remote GO! - PC-Fernsteuerung und Home-Entertainment
Network iControl - Netzwerkbandbreiten-Kontrolle in Echtzeit
DirectKey – Spezielle Taste für den direkten BIOS-Zugriff
Remote GO! - PC-Fernsteuerung und Home-Entertainment
Network iControl - Netzwerkbandbreiten-Kontrolle in Echtzeit
DirectKey – Spezielle Taste für den direkten BIOS-Zugriff
Spielzeug
Hallo zusammen,
das Problem ist gelöst: es hat tatsächlich am Netzteil gelegen!
Hätte ich nicht gedacht, da das Raid1 ja "gesund" war.
Zu dem Asus-Board möchte ich gerne aber nochmal was anmerken:
Klar haben Desktop-Mainboards auch Features, die Spielzeug sind - keine Frage!
Aber ich verbaue seit 20 Jahren Asus-Boards in Client-PCs, und die Dinger laufen sehr stabil und zuverlässig.
Und ich habe durchaus Kunden, wo die PCs 24/7 laufen - völlig ohne Probleme.
Ob auf den PCs dann nun Word-Dokumente geöffnet werden und im Internet gesurft wird, oder ob ein Cron-Job per SSH Datenbackups durchführt ist dem Mainboard glaub ich egal.
Deshalb kann ich den Schritt nicht nachvollziehen bei Funktionsstörungen erstmal ohne weitere Anhaltspunkte das Mainboard schlecht zu machen.
Sofern man in einer Debian stable version die notwendigen Treiber fürs Board bekommt sehe ich keinen Grund, warum die Kiste nicht stabil laufen sollte.
Und siehe da: daran hat es ja auch gar nicht gelegen.
das Problem ist gelöst: es hat tatsächlich am Netzteil gelegen!
Hätte ich nicht gedacht, da das Raid1 ja "gesund" war.
Zu dem Asus-Board möchte ich gerne aber nochmal was anmerken:
Klar haben Desktop-Mainboards auch Features, die Spielzeug sind - keine Frage!
Aber ich verbaue seit 20 Jahren Asus-Boards in Client-PCs, und die Dinger laufen sehr stabil und zuverlässig.
Und ich habe durchaus Kunden, wo die PCs 24/7 laufen - völlig ohne Probleme.
Ob auf den PCs dann nun Word-Dokumente geöffnet werden und im Internet gesurft wird, oder ob ein Cron-Job per SSH Datenbackups durchführt ist dem Mainboard glaub ich egal.
Deshalb kann ich den Schritt nicht nachvollziehen bei Funktionsstörungen erstmal ohne weitere Anhaltspunkte das Mainboard schlecht zu machen.
Sofern man in einer Debian stable version die notwendigen Treiber fürs Board bekommt sehe ich keinen Grund, warum die Kiste nicht stabil laufen sollte.
Und siehe da: daran hat es ja auch gar nicht gelegen.
