T550 mit 850 Pro: mkfs.ext4 meldet failed command

feklee

Member
Registriert
22 März 2013
Beiträge
313
Heute morgen habe ich eine Samsung 850 Pro 256GB in einen T550 eingebaut. Jetzt wollte ich Arch installieren, vom aktuellen CD-Image archlinux-2015.04.01-dual.iso. Die Formatierung der zweiten Partition dauerte einige Minuten, und dabei kam es zu Fehlermeldungen. Die ersten Zeilen habe ich abgetippt:

Code:
root@archiso ~ # mkfs.ext4 /dev/sda2
mke2fs 1.42.12 (29-Aug-2014)
Discarding device blocks: ^@[ 1227.636537] ata1.00: exception Emask 0x0 SAct 0x2 SErr 0x0 action 0x6 frozen
[ 1227.640017] ata1.00: failed command: SEND FPDMA QUEUED
[ 1227.643537] ata1.00: cmd 64/01:08:00:00:00/00:00:00:00:00/a0 tag 1 ncq 512 out
[ 1227.643537]          res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)

Es folgen weitere Fehlermeldungen ähnlicher Art. Bildschirmfoto:

P1040196_pt.JPG

Eine Wiederholung des Befehls ging in Sekundenschnelle und ohne Fehlermeldung.

Was tun? Ignorieren? Platte prüfen? Anschlusskabel prüfen?

Ein Firmware-Update für die 850 Pro gibt es offenbar nicht mehr - nachdem das letzte in die Hose gegangen ist.

PS: Es ist ein Albtraum, das Gehäuse aufzumachen, und es ist unglaublich viel ungenutzter Platz innen. Wenn man den auch noch für Akkus nutzt, dann wäre vielleicht noch ein weiterer Tag Laufzeit möglich. :eek:
 
Zuletzt bearbeitet:
Im BIOS resp. UEFI gibt es eine HDD Testroutine.

EDITH fragt: ist ein HDD Passwort aktiviert? Full Disk Encryption hat bei früheren ThinkPad Generationen mit Samsung SSD verschiedentlich für Vergnügen gesorgt...
 
Zuletzt bearbeitet:
Im BIOS resp. UEFI gibt es eine HDD Testroutine.
Danke für den Hinweis! Lasse gerade den ausführlichen SMART-Test laufen:
Code:
$ smartctl -t long /dev/sda
Der dauert angeblich noch mehr als zwei Stunden. Also vielleicht breche ich den Test ab und wiederhole ihn über Nacht. Alternativ könnte ich die Platte in ein Windows-Gerät einbauen und dort mit Samsung Magician ansehen. Das Tool zeigt aber vermutlich auch nur die SMART-Werte an.

ist ein HDD Passwort aktiviert?
Nein.
 
M.E. handelt es sich hier geht es um Verständigungsschwierigkeiten zwischen SATA-Controller und SSD.
 
M.E. handelt es sich hier geht es um Verständigungsschwierigkeiten zwischen SATA-Controller und SSD.
lspci sagt: 00:1f.2 SATA controller: Intel Corporation Wildcat Point-LP SATA Controller [AHCI Mode] (rev 3)

Auf die Schnelle kann ich im Web keine Information finden, die besagt, dass es Probleme im Zusammenspiel mit dem Controller und der 850 Pro gibt.

Der SMART-Schnelltest hat übrigens maximal ein paar Minuten gedauert, und nicht die angezeigten 136 Minuten. Ergebnis: Completed without error

Storage test über das BIOS lief auch ohne Probleme. Ergebnisse sind alle PASSED bis auf den Drive self-test. Der ist NOT APPLICABLE.
 
Zuletzt bearbeitet:
Die Kombination aus 850Pro und T550 läuft bei mir ohne Probleme, allerdings auch nur unter Windows 8.1...
 
Wenn es am NCQ liegt, das kannst auch abschalten, da es bei SSD's nicht mehr ganz so wichtig ist.
PHP:
echo 1 > /sys/block/sdX/device/queue_depth
Unter Fedora geht es dauerhaft mittels:
/etc/tmpfiles.d/KeinNCQ.conf
PHP:
w /sys/block/sdX/device/queue_depth - - - - 1
Wobei sdX durch deine Platte zu ersetzen ist.
 
Denn NCQ ist eher bei rotierenden Speichern von belangen.
 
Aber da gilt es denn für alle Ports, interessant wäre wenn man da den denn mit angeben könnte.
 
Aber da gilt es denn für alle Ports, interessant wäre wenn man da den denn mit angeben könnte.
Danke für den Hinweis! Doch das Gerät hat nur eine interne SSD, zumindest momentan: Man könnte mindestens eine weitere über M.2 hinzufügen.
 
Nachtrag:
Das geht sogar laut der Kernel Doku
PHP:
libata.force=    [LIBATA] Force configurations.  The format is comma
            separated list of "[ID:]VAL" where ID is
            PORT[.DEVICE].  PORT and DEVICE are decimal numbers
            matching port, link or device.  Basically, it matches
            the ATA ID string printed on console by libata.  If
            the whole ID part is omitted, the last PORT and DEVICE
            values are used.  If ID hasn't been specified yet, the
            configuration applies to all ports, links and devices.

            If only DEVICE is omitted, the parameter applies to
            the port and all links and devices behind it.  DEVICE
            number of 0 either selects the first device or the
            first fan-out link behind PMP device.  It does not
            select the host link.  DEVICE number of 15 selects the
            host link and device attached to it.

            The VAL specifies the configuration to force.  As long
            as there's no ambiguity shortcut notation is allowed.
            For example, both 1.5 and 1.5G would work for 1.5Gbps.
            The following configurations can be forced.

            * Cable type: 40c, 80c, short40c, unk, ign or sata.
              Any ID with matching PORT is used.

            * SATA link speed limit: 1.5Gbps or 3.0Gbps.

            * Transfer mode: pio[0-7], mwdma[0-4] and udma[0-7].
              udma[/][16,25,33,44,66,100,133] notation is also
              allowed.

            * [no]ncq: Turn on or off NCQ.

            * nohrst, nosrst, norst: suppress hard, soft
                          and both resets.

            * rstonce: only attempt one reset during
              hot-unplug link recovery

            * dump_id: dump IDENTIFY data.

            * atapi_dmadir: Enable ATAPI DMADIR bridge support

            * disable: Disable this device.

            If there are multiple matching configurations changing
            the same attribute, the last one is used.
libata.force=1:noncq
wenn ich das richtig lese und deine SSD am Port 1 hängt.
 
Nachtrag:
Das geht sogar laut der Kernel Doku
Sehr gut. Ich habe gleich mal das Wiki ergänzt.

wenn ich das richtig lese und deine SSD am Port 1 hängt.
Vermutlich. Ich habe gerade nur eine VM mit Linux am laufen. dmesg zeigt mir an:
[ 1.354792] ata1.00: ATA-4: VMware Virtual IDE Hard Drive, 00000001, max UDMA/33
Ich gehe davon aus, dass in diesem Fall der Port 1 und das Gerät 00 ist.
 
Wenn ich mir die Blacklist in git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/ata/libata-core.c anschaue, dann scheinen ja querbeet ziemlich viele neuere SSD-Modelle der grossen Anbieter betroffen zu sein. Fehlt eigentlich nur noch die SanDisk Extreme Pro, wie ich leider derzeit selbst erfahren musste. Bin auf der Suche nach einer Problemlösung erst auf diesen Thread hier gestossen.

Hatte mir vor kurzem zwecks Kapazitätsaufstockung für den Frankenpad trotz des vergleichsweise höheren Preises eine SanDisk Extreme Pro 480G neu besorgt, in der Erwartung, eben nicht mit den bekannten Problemen vergleichbarer Samsung und Crucial SSD's konfrontiert zu werden. Leider aber habe ich unter Linux am jeweils aktuellsten in Debian verfügbaren Kernel 3.16, 3.18 und 4.0 mit genau denselben Schwierigkeiten wie der TE zu tun.

Unter Windows wird die SSD im SanDisk Dashboard als vollkommen unproblematisch erkannt, während unter Linux die mit smartctl ausgelesenen Werte für Command_Timeout und Media_Wearout_Indicator stetig anstiegen:

Code:
[root]~ # smartctl -a /dev/sda | grep -E 'Command_Timeout|Media_Wearout_Indicator'
188 Command_Timeout         0x0032   100   100   ---    Old_age   Always       -       4883
233 Media_Wearout_Indicator 0x0032   100   100   ---    Old_age   Always       -       1181

Ich habe jetzt auch erstmal NCQ so wie hier beschrieben abgestellt, und jetzt ist erst mal Ruhe.

Ärgerlich ist es trotzdem, denn wenn ich das vorher gewusst hätte, dann hätte ich mir den Kauf erspart. Dann hätte ich mich lieber weiterhin mit der guten alten Samsung 830 mit 256GB begnügt, welche nach wie vor vollkommen unauffällig und fast genauso flott funktioniert.
 
Zuletzt bearbeitet:
  • ok1.de
  • ok2.de
  • thinkstore24.de
  • Preiswerte-IT - Gebrauchte Lenovo Notebooks kaufen

Werbung

Zurück
Oben