ASMedia Aktuelle Externe Gehäuse Chip Firmware für 8TB ++

Vielleicht noch zur Ergänzung soweit noch nicht bekannt:

Die 140509_A1_82_40 ist die SSD Firmware für den ASM-1153E.
Mit dieser werden SSD als SSD und nicht als HDD erkannt und unterstützt UASP und Trim.
Das kann man im Windows Defragmentierer und mit Trimcheck kontrollieren.

G.
 
lanse schrieb:
* Überflüssiges Zitat editiert! *

Hallo, ich danke dir vielmals für deine Antwort :)
Vielen Dank für Ihre Recherche und Ihre Links. Ich bin super glücklich! :)

Um die Aktualisierungen vorzunehmen, müssen sie vom Gerätemanager windows10 installiert werden.
 
Zuletzt bearbeitet von einem Moderator:
Fordteac schrieb:
Vielleicht noch zur Ergänzung soweit noch nicht bekannt:

Die 140509_A1_82_40 ist die SSD Firmware für den ASM-1153E.
Mit dieser werden SSD als SSD und nicht als HDD erkannt und unterstützt UASP und Trim.
Das kann man im Windows Defragmentierer und mit Trimcheck kontrollieren.

G.
Bestätigt, TRIM geht jetzt mit Firmware "140509_A1_82_40" (siehe Absätze+Beleg-Screenshots etw. weiter darunter)

---
Zusatz-Hinweis: Vorsicht bei Partitionierung wegen Alignment.
Der Asmedia ASM1153E Controller hat offensichtlich einen kleinen Bug per USB, bzw. liegt an Linux.
Das hat den Effekt: Das Linux-Partitionierungsprogramm "fdisk" (MBR-Partitionsschema) scheint im Zusammenspiel einer SSD/Festplatte mit Asmedia ASM1153E USB-SATA-Konverter (über USB -NICHT bei SATA/ESATA) als kleinste Sector-Nr. erst ab Sector-Nr. "65535" zu erlauben , was eine ungerade Zahl ist und nicht restlos durch 1 MiByte (1024*1024 Bytes) teilbar ist.
Andere Controller wie JMicron scheinen auch davon betroffen zu sein: Achtung auf Partitions-Ausrichtung, sonst ggf. schlechte SSD-Performance und stärkere Abnutzung als sonst (betrifft fdisk bei Einrichtung während über USB angeschlossen!!
Siehe Internet: Linux SSD partition alignment – problems with external USB-to-SATA controllers – I
(Betriift über USB, NICHT per ESATA)

(65535 Sectors * 512Byte /Sector) / (1024*1024 Bytes)
=33553920 Bytes / (1024*1024 Bytes)
=33553920 Bytes / 1048576 Bytes
=31,99951171875
=> 31 Rest 0,99951171875

65535 -512-Byte-Sectoren sind also nicht restlos durch 1 MebiByte teilbar. (65536 schon)

Wer das Problem umgehen will, schaltet fdisk temporär mit "c" in den DOS-Kompatibilitätsmodus (vom fdisk-Hauptmenu aus (betrifft nur über USB)
Dann lässt sich für die erste Partition auch ab Block-Nr. 2048 einstellen. Danach wenn erste Partition angelegt und ggf. weitere Partitonen dahinter erstellt werden sollen, sofort mit "c" den DOS-Kompatibilitätsmodus wieder zu deaktivieren (vom fdisk-Hauptmenu aus) und weiter ganz normal weiterpartitonieren.
(ntrl. auch Partitionsgrößen sollten dementsprechend durch 1 MiByte teilbar sein), dann passt es automatisch vom Alignment her.
--

Bei "gdisk" (für GPT-Partitonsschema) geht es auch (ohne manuellen Eingriff) trotzdem auch ab Sector 2048 :)
--

Hinweis:
Vielen Dank für den Hinweis, Fordteac, dass ASM1153E-Firmware "140509_A1_82_40" TRIM unterstützt!! :)

Kann ich bestätigen: Das SCSI-Unmap-Kommando (USB) <-> TRIM (SATA/ATA) -Konvertierung des Asmedia ASM1153E funktioniert tatsächlich!! TRIM über USB funzt!!
Bestätigt mit Firmware "140509_A1_82_40" es.
(Mit folgenden anderen Firmwares klappt TRIM per USB nicht:
130925_A0_00_01.bin, 130926_A1_00_00.bin, 140704_A1_00_00_UASP.bin, 140704_A1_A9_02.bin, 141125_21_00_00_ODD, 141126_A1_00_00

(Dann lag ich wohl falsch, dass die andere Firmware "141126_A1_00_00.bin" neuer sei als 140509_A1_82_40 etc.)

Aber mit "140509_A1_82_40" geht TRIM via USB. TRIM klappt sogar über USB 2.0 an meinem alten Intel ICH10 USB-2.0 Ports des Mainbaords. Über USB 2.0 auch als USB-UAS-SCSI-Massenspeichergerät.

Siehe Beleg-Screenshots:
(Jeweils aus drei bzw. zwei Vollbildschirm-Screenshots in ein höheres Gesamtbild zusammengesetzt),
weil nicht alle Programmfenster total in ein Vollbildschirmbild gepasst haben, vor allem wegen der zeitlichen Reihenfolge des Ablaufs "trimcheck-0.7-win64.exe", schlecht realisierbar gleichzeitig auf ein Vollbildschirmbild):

ASM1153E_140509_A1_82_40.bin_Renesas-UPD720202-PCIe-USB_3.0_-Trim-check_Windows_8.1.png ASM1153E_140509_A1_82_40.bin_Renesas-Intel_ICH10-USB_2.0_-Trim-check_Windows_8.1.png
ASM1153E_140509_A1_82_40.bin_Renesas-UPD720202-PCIe-USB_3.0_-Trim-check_Linux.png

-
ASM1153E_140509_A1_82_40.bin_Renesas-UPD720202-PCIe-USB_3.0_-Trim-check_Windows_8.1.png
ASM1153E_140509_A1_82_40.bin_Renesas-UPD720202-PCIe-USB_3.0_-Trim-check_Windows_8.1.png

------------------
ASM1153E_140509_A1_82_40.bin_Renesas-Intel_ICH10-USB_2.0_-Trim-check_Windows_8.1.png
ASM1153E_140509_A1_82_40.bin_Renesas-Intel_ICH10-USB_2.0_-Trim-check_Windows_8.1.png

-----------------------------------

Leider klappt unter Linux mit ASM1153E kein TRIM (betrifft nur USB), also selbst mit Firmware "140509_A1_82_40" nicht, unter Windows 8.1 und 10 hingegen schon)
Liegt es an meiner Linux-Kernel-Konfiguration (kenne mich sowieso nicht ganz so gut aus mit Linux)??

Relativ leichte manuelle TRIM-Test-Methode unter Linux: (hier im Screenshot Anleitung durchgeführt)
Trim your SSD down to size

ASM1153E_140509_A1_82_40.bin_Renesas-UPD720202-PCIe-USB_3.0_-Trim-check_Linux.png
ASM1153E_140509_A1_82_40.bin_Renesas-UPD720202-PCIe-USB_3.0_-Trim-check_Linux.png


-------------------------------
Im Vergleich dazu über SATA/eSATA, TRIM klappt unter Linux.
ASM1153E_140509_A1_82_40.bin_eSATA_Intel_ICH10R_SATAII-3G-SATA_-Trim-check_Linux.png
ASM1153E_140509_A1_82_40.bin_eSATA_Intel_ICH10R_SATAII-3G-SATA_-Trim-check_Linux.png


--
SCSI unmap und TRIM (ATA) Erklärung:
SSD on USB 3.0 3.1 with TRIM support: Windows & Linux
http://salutepc.altervista.org/ssd-on-usb-3-0-3-1-with-trim-support-windows-linux.html
--
Nachtrag: Habe tatsächlich TRIM in Linux mit Asmedia ASM1153e und SSD per USB doch noch zum laufen bekommen!! :)
https://bbs.archlinux.org/viewtopic.php?id=236280
[SOLVED] TRIM in external SSD - USB3 UASP
-
Laut eines Forumsbeitrages dort, gibt es USB Bridges, welche direkt den ATA-Frim-Befehl über USB durchleiten können (ATA-passthrough), was mich zwar etw. stutzig macht, da ich irgendwo las, dass USB eigentlich eher bloß SCSI-Befehle durchleite (über UASP Mode). Naja egal, Blicke da eh nicht so ganz durch.
Laut eines Beitrags, manche USB-SATA-Bridges können den gesendeten ATA-TRIM-Befehl NICHT über USB direkt zur SSD direkt durchschleifen (ATA-passthrough). Dazu zählt wohl der Asmedia ASM1153E, der das wohl nicht macht.
Der ASMEDIA 1153E kann aber wohl das SCSI-Unmap-Kommando verarbeiten und in den ATA-TRIM-Befehl konvertieren. Der Linux-Kernel erkennt das allerdings schlecht automatisch.
Aber man kann in den "udev"-daemon so konfigurieren, dass für den ASM1153E (VID 174c ,PID 55aa) für TRIM nicht das ATA-TRIM-Kommando geschickt wird, statdessen der SCSI-Unmap-Befehl.
Hat tatsächlich geklappt: Siehe Screenshot und Zahlen in Reihefolge: TRIM geht damit dann letztendlich doch:
ASM1153E_140509_A1_82_40.bin_Renesas-UPD720202-PCIe-USB_3.0_-Trim-check_Linux_neu.png


Dazu wäre "udev" etw. zu konfigurieren:
Ggf. Noch gemountete Partitionen über den USB-SATA konverter bitte zuerst unmounten, dann den "udev"-daemon stoppen, und dann USB-Kabel des USB-SATA/Adapters ausstecken.
Folgendes darunter markieren und bis ganz nach rechts scrollen (letztes " ganz am Schluss nicht vergessen mitzumarkieren) - und kopieren:
Code:
ACTION=="add|change", ATTRS{idVendor}=="174c", ATTRS{idProduct}=="55aa", SUBSYSTEM=="scsi_disk", ATTR{provisioning_mode}="unmap"
(für Asmedia 1153E): (Kleinschreibung für die Buchstaben-Ziffern von idVendor und idProduct benutzt, sonst gehts nicht)
eine neue Datei im Verzeichnis "/etc/udev/rules.d/" anlegen mit Editor , z.B. genannt "98-uas-trim-scsi-unmap.rules" und den CODE reinpasten und speichern
Dann den "udev"-Daemon wieder starten
und den SATA-USB-Konverter wieder einstecken.
SSD-ext4 Partition mounten, und TRIM erfolgreich testen.


-
Lunke schrieb:
Da mir hier ja nicht geglaubt wurde hier nochmal der Beweis in Bildform. Ich verzichte auf jegliches Copyright, sodass ihr das Bild gerne in Sozialen Medien etc. verbreiten dürft.

Ich finde dies eine wichtige Information, denn in diesem Thread werden Kaufempfehlungen zu Fantec ausgesprochen und im Haup-Post gibt es eine Liste, welche Chips in welchen Gehäusen drin sein sollen. Dies ist also eine Ergänzung zu der Liste am Anfang und zeigt, dass es fast schon eine Lotterie ist, welchen Chip man dann tatsächlich bekommt.
Anhang anzeigen 695977

Zumindest, wenn ein falsch deklariertes FantecProdukt mit älteren ASM1053 versteckt geliefert würde, kann ntrl. MTechlerin nichts dafür, wenn eine ASM1153e-Firmware versehentlich geflasht wird (allerdings im Vortrauen auf richtige Angaben von Hersteller/Verkäufer-Webseite und Produktpackung).

Allerdings verstehe ich, dass man sich ärgert, wenn man so betrogen wird, wenn eine Firma dafür, egal von wem, danach wür sowas diesbezüglich auch noch in Schutz genommen wird und sich weigert Geld zurück zu zahlen oder nicht gegen richtiges Produkt umzutauschen will (gegen Gesetz), =>Frist setzen.
Geht auch OHNE Beweislast des Kunden, sondern der Verkäufer muss beweisen, dass er ein fehlerfreies und ein so-wie-drauf-steht-Eigenschaften-Produkt geliefert hat.
Nach 1/2 Jahr nach Kauf besteht weiterhin noch ein Rest von 1+1/2 Jahr gesetzliche Gewährleistung. Wer vergessen hat nach 1/2 Jahr zu reklamieren, sollte es problemlos noch beweisen können, siehe Seriennummer-Aufkleber auf Produktpackung und auf der Leiterplatte des Produktes draufgeklebt und dessen Bezeichnung dessen Asmedia-Chips.

Ich hab insgsm 10 Fantec DB-ALU3e-6G gekauft, scheinen alle richtig deklariert zu sein, keine falsche Liefer-charge.

(Davon 8 Stück von Jacob-Computer - aus drei Bestellungen innerhalb 5 Monaten (Q1/Q2 2018),

und 2 weitere von MediaMarkt.at (2 Stück in Österreich während Urlaub, teilweise günstiger als in de - schade leider keine Lieferung nach "de").

Haben "ASM1153E" aufm Chip stehen, zum Glück kein "ASM1051" oder "ASM1053E" als Aufschrift, scheinen sich auch so zu verhalten.



--------------------------------------------------------------
Minimalen Unterschied in "lsusb" Gerätebeschreibung zwischen Debian (Testing Buster) und Knoppix Liv e-Linux-System bemerkt. Liegt doch nicht an neuerer und älterer ASM1153E Firmware-Version, wie zuvor von mir behauptet (falsche Aussage von mir entfernt). Aufm Chip der getesteten Fantec DB-ALU3e-6G steht aber eindeutig ASM1153E, also OK.)

Debian GNU/Linux mit 4.20 Kernel (eigen kompiliert)
Code:
lsusb
Bus 010 Device 004: ID 174c:55aa ASMedia Technology Inc. Name: ASM1051E SATA 6Gb/s bridge, ASM1053E SATA 6Gb/s bridge, ASM1153 SATA 3Gb/s bridge, ASM1153E SATA 6Gb/s bridge
-

Auflistung Knoppix
Code:
lsusb
...ID 174c:55aa ASM1051E SATA 6Gb/s bridge, ASM1053E SATA 6Gb/s bridge, ASM1153 SATA 3Gb/s bridge


Unter Knoppix fehlt also hinter "ASM1153 SATA 3Gb/s bridge" noch "ASM1153E SATA 6Gb/s"in der Auflistung von "lsusb". Auf'm Chip steht aber eindeutig "ASM1153E", also OK. Unter Debian GNU Linux zählt "lsusb" hinter "ASM1153 SATA 3Gb/s bridge" auch "ASM1153E SATA 6Gb/s" noch auf)
 
Zuletzt bearbeitet von einem Moderator:
Hi,
ich such die beste und vor allem sicherste Methode SATA SSDs und HDDs (auch 3,5") über USB 3.0 anzubinden.
Ist dieser ASM Kram quasi das beste was es gibt?
Oder sollte ich mir was anderes zulegen?
Wenn ja, was?
 
Ich würde dir zur Fantec DB-Alu3e-6G raten, weil die zu anderen Gehäusen oft am günstigsten ist und den ASM1153E hat (selbiger Chipsatz wie das vorgeschlagene Produkt im Link von smuper ) und USB 3.0-B-Stecker (weniger empfindlich als diese Micro und USB-C) und auch noch eSATA hat, und zusammengebaut "Made in Germany".
Dem Vorschlag von smuper fehlt eSATA, ist aber trotzdem nicht günstiger.
Neuere Gehäuse mit neuen Chips haben nur USB-C, aber kein eSATA. USB-C und Mikro-USB ist auch aus Erfahrung etw. empfindlich, weil es so klein ist. Weiterhin gibt es ja Adapterkabekl von USB-2.0-B/3.0-B auf USB-C)

Mit Firmware "140509_A1_82_40" geht auch noch SSD-TRIM über USB (bzw. eher SCSI unmap<->TRIM-Konvertierung), was sich auch unter Linux manuell aktivieren lässt. HDDs gehen mit dieser Firmware natürlich auch!
Umfänglicheres ATA-Passthrough mit direkterem TRIM über USB, klappt vllt. mit wenigen JMicron-Chipsätze, bzw. allgemein eher nur mit neueren, glaub mit M.2 auf USB.
Der eSATA kann übrigens SATA6G natürlich, vorrausgesetzt ein eSATA3 Anschluss oder per Adapterkabel SATA-I auf SATA-L-Port 6Gbit/s.

Wenn du natürlich schnell mal eine SSD oder HDD reinschieben können möchtest, ist die Fantec DB-ALU3e-6G vom Gehäuse her hierzu natürlich NICHT die beste Wahl.
Die Orico 6518SUS3 (USB-B 3.0 +eSATA) /6518US3 (USB 3.0-B), welche ich bei amazon gekauft hatte, ist vom Einschub her praktisch, aber dessen Norelys 106X Chip und keiner deren verschiedener Firmwares kann leider kein TRIM per USB.
Hatte dann meine Orico 6518SUS3 Gehäuse umgebaut, Plastik zurechtgedremelt/gefräßt und eine Fantec DB-Alu3e-6G-Platine reingeschraubt, funktioniert gut, Wärmeleitkleber (Silikonbasis) +Kühlkörper wurde noch auf ASM1153E befestigt als Schutz vor Durchbrennen durch Überhitzung des Chips, lief jetzt seit 8 Tagen im Dauer-Loop-Stresstest über USB bei 470 MByte/s ohne kaputtzugehen. Stresstest nun zum Schluss manuell beendet.
Hinweis JMicron-Chips werden sonst ohne Kühlkörper bei hohen Transferraten auch sehr heiß!!:)
Die beiden Kühlkörper auf dem ASM1153E, der 2. auf dem ASM1542 ESATA-USB Signalswitch) werden bei Dauerhöchstbelastung ca. handwarm.
IMG0880A.jpgIMG0878A.jpgIMG0876A.jpgIMG0875A.jpg

Und hier noch auf der Skizze, außenrum um den ASM1153E sicherherithalber (aber nur über den Beinchen drumrum Isolierungsklebeband hingebäppt, als Schutz wegen Kurzschlussgefahr, falls der Kühlkörper dochmal leicht verückt) Und der außen etw überschüssiger Wärmeleitkleber drumrum, nach mehrfachem (vorsichtigen) Draufdrücken während des Trockenvorgangs ist über dem doppelseitigen Klebeband hält den Kühlkörper noch zuästzlich etw. besser) Der Kühlkörper ist 8,8mm unten breit, der ASM1153E-Chip (5,5mm*5,5mm). Band ist nicht über dem Chip , wie man meinen könnte, sondern genauso nur außen um den Chip wie auch auf den Fotos äußerlich nur erkennbar ist )
IMG0860B.jpg

Alle SATA-USB-Controller, EGAL ob von Jmicron, Asmedia oder Norelys, haben ein Problem bezüglich Partitionsalignment über USB. Deshalb ist es nicht nachteilig, wenn du z.B. Asmedia wähltest.
Siehe Post #125 weiter oben und im Link dort, was ich auch erfahren musste.

Unter "fdisk" (MBR) unter Linux muss man manuell im Dos-Kompatibilitätsmodus partitionieren, weil die Auto-Hilfs-Partitions-Funktion von fdisk beim ASM1153E (auch bei anderen SATA-USB-Chipsätzen) über USB nur ab Startsektor 6553(5) und zwischen den Partionen hier (per USB) immer nur 6553(5)-Blöcke-Lücken zulässt. Andere Windows -Partitionierer ggf. auch betroffen, auch bei amazon hatten schon ein Nutzer sich über die ADATA SU900 beklagt, weil er das Partitonsalignment nicht beachtet hat, vrmtl. weil er einen SATA-USB-Controller benutzt hat (egal welcher Chipsatz), der die Partionierer dahingehend durcheinandergebracht hat.

Das führt sonst zum erhöhten Verschleiß von SSDs und Performanceverlust. Lösen lässt sich das über manuelle Partionierung von fdisk im Dos-Kompatiblitätsmodus, ist allerdings zeitaufwändiger (betrifft über USB).
Hinzu kommt, wenn man für Größe binäre Partitonsgrößen +K (1024) oder +M (*1024*1024) oder z.B. +50G (50 *1024*1024*1024) nehmen will, sodass es von den Page-Sizes bzw. Erase-Blocks der SSD (ADATA SU900 Erase Blocke Size =32 MiBytes =32 *1024*1024 Bytes) passte, da hat/hatte fdisk einen Bug mit ASM1153E (andere Chipsätze auch) in Kombination über USB, dass er dann trotzdem nicht den angegeben Binär-Wert für die Größe nimmt, sondern einen leicht daneben, d.h. ein Vielfaches von 65535 Blöcke, was (65535 Sektoren *512 Byte/Sektor =33553920 Bytes =>33553920 Bytes / (1024*1024 Bytes/ MiByte)=31,99951171875 MiBytes) auch nicht durch (1024*1024) und auch nicht durch 1024 restlos teilbar ist.

Zuerst muss der Startoffset jeder Partition (in Sektoren => umgewandelt in Bytes)durch die Page-Size bzw. Erase-Block-Größe (in Bytes) der SSD teilbar sein.
Sind noch erweiterte und logische Partitionen vorhanden, wird es unter Umständen komplizierter.
"fdisk" (MBR-Partitonierung) z.B. lässt/ bzw. ließ immer eine Leeraum von 2048 Blöcken zwischen jeder logischen Partition.
Soll die Partition also z.B. 50 GiBytes groß sein, muss man also hier die Größe 50GiBytes manuell per Hand im DOS-Kompatibilitätsmodusm als Block-Zahl angeben, wenn/weil der Asmedia-Controller über USB dazwischen funkt:
=>104857600 Sectors
<=50* 1024(^3) Bytes /(512Bytes/Sektor)= 53687091200 Bytes *Sector/512 Bytes =104857600 Sectors
Leider muss hier in dem speziellen Fall z.B. in "fdisk" die Partitionsgröße über den Start- und End-Sektor der Partition angeben werden, (weil "fdisk" z.B. im Zusammspiel mit USB-SATA-Controllern die angegegbenen+K / +M / +G Größenpäfixe nicht richtig verarbeitet!)
Der End-Sektor der Partition gibt die Größe an.
Fängt die Partition Nr. 2 z.B. bei Offset 128 MebiBytes an (=128*1024^2 /512 =262144 *512-Byte-Sektoren), und sie soll z.B. 200 GiBytes groß sein, so ist der Startsector bei 262144 (davor 0<->262143), so wird die Größe angegeben über:
262144 -1 + 200 *1024(^3) Bytes/ 512 Bytes
262143Block
+ 419430400 Blöcke
=419692543 (=End-Partionsblock-Offset)
(von 262143 ausgehend, weil 26214(4) mitgezählt wird, alsoeinschließlich 262144 ist und noch die Paritionsgröße 419430400 hinzukommen, was 1 Block zu viel wäre, daher 1 abziehen, und sonst wäre der nächste Start-Block ungerade.
Das darf man dann für jede Partition ggf. manuell per Hand machen und bei logischen noch 2048 Block-Lücken, dann noch beachten dass man ggf. einen Block abziehen bzw. addieren muss (für mich zu kompliziert im Kopf genau mir zu merken)

Da ist leider so kompliziert über USB und ein Ärgernis mit dem SSD-Partitions-Alignment von vielen USB-SATA- Controllern, wenn man nicht aufpasst, weil Asmedia und Jmicron unjd Norelys etc. irgendeinen Mist in ihrer Firmware machen.

Bei "gdisk" hingegen über GPT-Partitonsstil tritt das Problem nicht auf, und der kompliziertere Lösungsweg über USB ist nicht notwendig, hier gehts auch über die "Auto"-hilfs-Partitionsfunktion.

Deshalb ist es gut, wenn das Gehäuse noch eSATA hat, und man kann die SSD damit auch direkt anschließen, wo die Partitionierungs-Hürde über die Auto-Hilfsfunktion nicht auftritt, wenn man nicht weiß, wie man manuell vom Alignment her sauber partitioniert. ;)
(eSATA kann man auch per SATA-I <-> SATA-L -Adapterkabel problemlos direkt an SATA betreiben, erfolgreich getestet an Intel ICH10 Core2 Sockel-775-Chipsätzen und an Ivy Bridge Sockel 1155 Board :)

Es wurde teilweise von Produktfälschungen von DB-ALU3e-6G berichtet von Usern, die bei amazon gekauft hatten.

Ich hab neun Stück davon bei Jacob-Computer gekauft und zwei Stück davon bei MediaMarkt innerhalb letzte 14 Monaten gekauft. Alle gelieferten Exemplare sind OK, (ASM1153E VID 174C, PID 55AA), also KEINE Fälschungen.
Falls die Fantec DB-Alu3e-6G es sein soll. Ich kann bestätigen bei Jacob-Computer passt, alle gelieferten Fantecs DB-ALU3e-6G OK, keine Fälschungen. Es ist übrigens günstiger, wenn der Shop-Aufrug per geizhals erfolgt. !:)
9 Stück insgesamt auf vier Bestellungen, nur so als Beispiel war immer vorrätig und wurde binnen max ca. 3-7 Tagen geliefert.

Günstiger billiger: Aufruf und Link über geizhals.de): 28,48€ (versandkostenfrei) (Stand 10.4.2019 19:40)
https://direkt.jacob.de/produkte/FANTEC-DB-ALU3e-6G-1693-artnr-2128707.html

Webseite direkt aufgerufen und teurer: 33,60€ (versandkostenfrei) (Stand 10.4.2019 19:40)
https://www.jacob.de/produkte/FANTEC-DB-ALU3e-6G-1693-artnr-2128707.html
 
Zuletzt bearbeitet:
Hallo zusammen,
kann mir jemand sagen, was der Unterschied zwischen dem ASM1153 und dem ASM1153E ist? Ich habe bisher kaum was dazu gefunden, das einzige war, dass der ASM1153E S-ATA III und der ASM1153 nur S-ATA II hat. Stimmt das?

Ich habe ein Inateck 2,5" Gehäuse bestellt, lsusb unter Linux Mint gibt Folgendes aus:
"ASMedia Technology Inc. ASM1051E SATA 6Gb/s bridge, ASM1053E SATA 6Gb/s bridge, ASM1153 SATA 3Gb/s bridge".
Um welchen Chip handelt es sich jetzt?

Gibt es irgendwo eine Übersicht für 2,5" Gehäuse? Es scheint schwierig zu sein, überhaupt herauszufinden, welcher Chip verbaut ist. Das letzte Gehäuse von Orico sorgte irgendwie dafür, dass die HDD am S-ATA-Port kein Dateisystem mehr hatte.
Ich suche eigentlich nur ein Gehäuse, das mir erlaubt, die Daten auf der HDD auch nach dem Ableben des Gehäuses noch zu lesen. Daher habe ich das Inateck bestellt, dort stand dabei, dass es den ASM1153 verwendet. Durch eine Firmware hier erhoffe ich mir, dass ich die gewünschte Funktionalität erhalte.

Vielen Dank im Voraus
 
pluspeter schrieb:
Hallo zusammen,
kann mir jemand sagen, was der Unterschied zwischen dem ASM1153 und dem ASM1153E ist? Ich habe bisher kaum was dazu gefunden, das einzige war, dass der ASM1153E S-ATA III und der ASM1153 nur S-ATA II hat. Stimmt das?

Ja, das stimmt, der ASM1153(e) hat SATA III-6Gbit/s, und der ASM1153 "nur" SATA II-3Gbit/s.
Die Firmware ist allerdings die selbe bei beiden, siehe bei usbdev.ru, dort wird (ASM1153/ASM1153E) angezeigt.

ASM1153
http://www.asmedia.com.tw/eng/e_show_products.php?cate_index=171&item=132
"Compliant with Serial ATA Specification Revision 2.6
"Serial ATA bus up to 3Gbps Signal bandwidth "

http://www.asmedia.com.tw/eng/e_show_products.php?cate_index=171&item=133
ASM1153E
"Compliant with Serial ATA Specification Revision 3.0"
"Serial ATA bus up to 6Gbps Signal bandwidth"

Mit "smartctl" (Paket "smartmontools") kannst du gegentesten, welche SATA-Stufe intern verbaut ist:
als root in Konsole/bash/shell/terminal eingeben:
smartctl -x /dev/sdX |less -SI

Hinweis: Wenn ein SATAII-3Gbit/s Gerät angesteckt wird, wird nur die die niedrigere Revision der SATA-HDD/SSD angezeigt, d.h. die Funktion einer 6GBit/s Bridge ist sozusagen "versteckt", also nicht ersichtlich.
Es muss ein SATA-III-6Gbit-Speichermedium an der SATA-USB-Bridge angesteckt sein, damit die SATA-III-6Gbit/s Fähigkeit angezeigt wird.


Mit SATAII-3Gbit/s HDD wird nur angezeigt (Fantec DB-ALU3e-6G):
"ATA Version is: ATA8-ACS (minor revision not indicated)
SATA Version is: SATA 2.6, 3.0 Gb/s

Mit SATAIII-6Gbit/s HDD/SSD (Fantec DB-ALU3e-6G):
ATA Version is: ATA8-ACS (minor revision not indicated)
SATA Version is: SATA 3.0, 6.0 Gb/s (current: 6.0 Gb/s)

Ich habe ein Inateck 2,5" Gehäuse bestellt, lsusb unter Linux Mint gibt Folgendes aus:
"ASMedia Technology Inc. ASM1051E SATA 6Gb/s bridge, ASM1053E SATA 6Gb/s bridge, ASM1153 SATA 3Gb/s bridge".
Um welchen Chip handelt es sich jetzt?

Wenn "lsusb" zu deiner Inateck wie bei meiner Fantec DB-ALU3E-6G als VID "174C" und PID "55AA" anzeigt, dann ist es ein ASM1153E.

"lsusb" listet zu meiner Fantec bei dem Standard-Linux-Kernel von Debian und Knoppix das Gleiche wie bei Dir:
"ASMedia Technology Inc. ASM1051E SATA 6Gb/s bridge, ASM1053E SATA 6Gb/s bridge, ASM1153 SATA 3Gb/s bridge"

Am anderen PC mit selbst-kompilierten und konfigurierten Linux-Kernel wird noch zusätzlich gemeldet:
ID 174c:55aa ASMedia Technology Inc. Name: ASM1051E SATA 6Gb/s bridge, ASM1053E SATA 6Gb/s bridge, ASM1153 SATA 3Gb/s bridge, ASM1153E SATA 6Gb/s bridge

Wenn es per SATA/USB deutlich über 270-300MByte/s schaffst, dann ist es ein ASM1153E:
Musst allerdings ntrl. mit einer schnellen SATAIII-6Gbit/s SSD testen in der Inateck, falls verfügbar und an einen SATAIII-6Gbit-Port per SATA-L-ESATA-Adapterkabel hängen, bzw. schnellen USB 3.0 Port, bzw. PCIe-adapter-Karte vorrausgesetzt (PCIe 2.0/3.0 haben in einem PCIe 2.0/3.0 Port gesteckt sein).
Kein Formatieren und Schreiben nötig (wird in Hauptspeicher gelesen, aber gelesene Daten gleich wieder verwofen:
Code:
ddrescue -b 4096 -c 8192 -f  /dev/sdX /dev/null
oder:
ddrescue --sector-size=4096 --cluster-size=8192 -f  /dev/sdX /dev/null
Dort wird dann die aktuelle Transferrate angezeigt

-b, --sector-size=<bytes>
sector size of input device [default 512]

"-c, --cluster-size=<sectors>
sectors to copy at a time"

Gibt es irgendwo eine Übersicht für 2,5" Gehäuse? Es scheint schwierig zu sein, überhaupt herauszufinden, welcher Chip verbaut ist. Das letzte Gehäuse von Orico sorgte irgendwie dafür, dass die HDD am S-ATA-Port kein Dateisystem mehr hatte.
Ich suche eigentlich nur ein Gehäuse, das mir erlaubt, die Daten auf der HDD auch nach dem Ableben des Gehäuses noch zu lesen. Daher habe ich das Inateck bestellt, dort stand dabei, dass es den ASM1153 verwendet. Durch eine Firmware hier erhoffe ich mir, dass ich die gewünschte Funktionalität erhalte.

Vielen Dank im Voraus

Ließ dir ggf. die Beiträge auf der Threadseite Seite hier, weiter oben, durch. Könnte interessant sein.
--
Ich weiß nicht genau, wo man eine genaue Tabelle bekommt.
Teilweise hatte ich auf der smartmontools Datenbank-Webseite(smartctl) ;
bzw. hatte eher eine Datenbank-Webseite von UAS-(USB-attached-SCSI)-fähigen/tauglichen Geräten und auch UAS-geblacklisten Geräten gesehen.
In dieser Übersicht werden gleichzeitig viele SATA-USB-Adapter-Modelle und Chipstätze aufgelistet.

Nur so als Hinweis, mal danach googeln. Vllt. hilft das ein bischen weiter:
Hier 'ne kleine Übersicht:
=>http://linux-sunxi.org/USB/UAS
=>https://www.smartmontools.org/wiki/Supported_USB-Devices

Dort wird aufgelistet, welche Modelle UAS ordentlich können (darunter ASM1153/ASM1153e), welche andere UAS laut Angaben können sollten, und bei welchen Chipstäzen UAS noch verbugt (fehlerhaft) ist, z.B.. bei ASM1051/ASM1053 und bei Norelys 106X /Orico 6518US3 UAS buggy, d.h. aus Sicherheit welche geblacklistet im Linux-Kernel.

----
Eine andere Art von Übersicht, z.B. wo was am günstigsten (und z.B. mit Suchfilter nach Eigenschaften):
geizhals.at (Österreich)
https://geizhals.eu (EU-weit)
geizhals.de (Deutschland)

Dort kannst du z.B. auch nach SATA-USB-Adapter filtern lassen und welche Geschwindigkeit die können.

So bekommst du bei höheren Geschwindkeiten die du z.B. für SATA filterst, automatisch die neueren/neusten Produkte/Chipsätze gelistet, je nachdem.
Oftmals gibt es auch zum jeweiligen Produkt Link "Info beim Hersteller", musst aber vorher das entsprechende Produkt jeweils detailliert (Detailansicht) noch aufrufen, dann ->"Info beim Hersteller". Einige Hersteller wie StarTech, etc listen dann jeweils den Chipsatz des Produktes auf, teilweise geht der Hersteller-Link aber auch nicht mehr.

Wenn du nach intern SATA 6Gb/s und nach "extern eSATA" filterst, wird noch dazu max USB. 3.0 angeboten,was man gleichzeitig mitauswählen/mitfiltern kann. D.h. Produkte mit eSATA können/haben als weiteres Kriterium noch max USB 3.0 5Gbit/s zusätzlich mit an Board.
Die Auswahl wird dann schnell begrenzt von den angebotenen Produkten. Die Fantec DB-ALU3e-6G unter diesen ist am günstigsten (ca. 25€-30€).
(SATAII/III intern, und extern USB 3.1 Gen2 10Gbit/s + eSATA gibt es gleichzeitig zusammen noch nicht.

www.geizhals.eu
-> Festplatten & SSDs
->Externe Gehäuse
(nach den folgende Kriterien gefiltert=muss gleichzeitig können):
Formfaktor: 3.5" (17)
Anschluss intern: SATA 6Gb/s (17)
Anschluss extern: USB 3.0 (17) eSATA (17)

(3,5 Zoll)
https://geizhals.de/?cat=gehhd&xf=339_3.5"~696_SATA+6Gb/s~840_USB+3.0~840_eSATA
--
Du kannst auch nach 2,5 Zoll filtern:
https://geizhals.de/?cat=gehhd&xf=339_2.5"~696_SATA+6Gb/s~840_USB+3.0~840_eSATA
oder beides:
https://geizhals.de/?cat=gehhd&xf=339_2.5"~339_3.5"~696_SATA+6Gb/s~840_USB+3.0~840_eSATA
--

Viele 2,5 Gehäuse haben nur den USB-Mikro oder C-Anschluss, welche relativ empfindlich sind.
Dann gibt's noch USB 3.0-A kombiniert mit eSATA =eSATAp. Da ließt man öfters und auch aus Erfahrung, dass die eSATAp-USB-Kombibuchsen ggf. leichter kaputt gehen, dass nicht mehr alle Buchsen-Eigenschaften funktionieren.

Ich hätte an deiner Stelle die Fantec DB-ALU3e-6G mit ASM1153e gekauft (3,5 Zoll) genommen ( ASM1153(E) )
Es passen aber auch 2,5-Zoll-Laufwerke rein.
Die DB-ALU3e-6G hat außer des USB 3.0, auch noch eSATA. Der eSATA der DB-ALU3e-6G kann ebenfalls SATAIII-6Gbit/s.
Meines Wissens ist die am günstigsten vom Preis-Leistungsverhältnis und hat noch einen Zusatzanschluss.
Außerdem ist der USB 3.0 ein USB-B, also stabiler

Wegen Produktfälschungen braucht man sich nicht Gedanken machen, jedenfalls nicht bei dem Händler wo ich gekauft habe, Jacob-Elektronik, dort 9 Stück in der Zwischenzeit innerhalb der letzten 2 Jahre dort gekauft, alles OK, alle neun Produkte auch tatsächlich wirklich geliefert wie bestell und angegeben ist. ;) :)

SCSI-Unmap (=TRIM-Equalivalent) kann die DB-ALU3e-6G auch nach manuellen Aufpsielen von Firmware 140509_A1_82_40.bin : TRIM durch (SCSI=>ATA-Translation) (Richtung SATA-intern.), was SCSI-Befehle nach ATA-Befehle umsetzt, also SCSI-Unmap nach ATA-TRIM umsetzt
(UASP = USB-attached-SCSI-Protokol =SCSI über USB)

TRIM direkter (per ATA-Passthrough über SCSI/UASP) geht damit nicht, bis jetzt keine Firmware hierfür vorhanden. Es gibt meines Wissens auch keine SATA-USB-Adapter, welche das können, weil sich die Hertseller eher nur noch auf neuere interne Schnittstellen konzentrieren, wie M.2.
--
Vllt. kann die Fantec DB-ALU31 mit ASM1351 TRIM direkt per ATA-Passthrough. Offiziel steht da aber nix von ATA-Passthrough-commandset bei Asmedia beim ASM1351, bloß zu den neueren Asmedia-Chipsatzen auf asmedia.com (z.B. ASM2362) -M.2-USB-Adaptern (KEIN SATA). (Außerdem fehlt der Fantec DB-ALU31 eSATA und sie hat nur einen empfindlicherenn USB-C Anschluss (weiß selber aus Erfahrung), und wurde schlecht bewertet)
 
Zuletzt bearbeitet:
Ich hab 2 x 2.5-Zoll-Gehäuse von Inateck 3.0 (Chipsatz ASM1153e) mit Ein-Aus-Schalter und USB-Anschluss Typ-A.
https://www.inateck.com/de/externe-...sb-3-0-anschluss-schnittstelle-feu3ns-1e.html

Beide sollen als Backupplatte für eine Freundin (Selbständig) an WIN 10-1903 verwendet werden.
Acronis 2017 ist das Backupprogramm und funktioniert an sich auch.
Jetzt das Problem - irgendwann kommt es bei unserm PC und durch Acronis zu einem von uns ungewollten LW-Wechsel. Es wird plötzlich das Ziel-LW T: für die Festplatte S: angesteuert obwohl wir eindeutig im Script natürlich für die Festplatte S: auch das Ziel-LW auf S: gestellt haben.
Durch diesen ungewollten automatischen Wechsel des Ziel-LW von Acronis kommt es natürlich zum Fehler und das Backup bricht ab.

Wen es genauer interssiert wie das Ganze sich genaue darstellt und was ich/wir alles schon versucht haben
https://forum.acronis.com/forum/deu...ewahlten-lw-buchstaben-nach-erstelltem-backup

Und dort im Thread aus dem Deutschen Acronis-Forum wurde ich dann von "G.Uphoff" (Helfer im Forum) auf ein Phänomen unter WIN 10 aufmerksam gemacht
Wenn man im Gerätemanager bei "Laufwerke" die externen Festplatten mit einem Rechtsklick auswählt, "Eigenschaften" und "Ereignisse" anklickt, wird dort mitunter "Gerät nicht migriert" angezeigt!
https://www.borncity.com/blog/2017/03/11/windows-10-fehler-gert-nicht-migriert/

Das traf tatsächlich auf unser Problem zu - wobei es immer nur 1 Platte betraf, die andere Platte wurde einwandfrei als migriert angezeigt.

Kennt das jemand im Zusammenhang mit ext. Festplatten-Gehäusen mit Chipsatz ASM1153e ebenfalls?

Mit anderen Chipsätzen bei ext. Gehäusen hatte ich übrigens ein solches LW-Problem in Acronis noch nie.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Vincent
Darf ich fragen was für eine Art von Backup du/Freundin durchgeführt hast/hat / versucht hast durchzuführent?
Klonst du die gesamte NTFS-Partition Winsows-C:? und/oder wird eine andere NTFS Partition komplett geklont oder nur Ordner kopiert/Partitionen reilweise geklont, weil nur bestimmte Verzeichnisse gewählt wurden?

Prüfe mal ob beie externen Platten wohin gebackup wurde. nicht diesselbe UUID haben wie die Quelle:
Biepsiel in cmd (Eingabebeaufforderung) als Admin:
fsutil fsinfo ntfsinfo c:

fsutil fsinfo ntfsinfo S:

fsutil fsinfo ntfsinfo T:

Prüfe, dass bei (hier Beispiel) "NTFS-Volumeseriennummer 0x5e5e8bde5e8bad79" nicht dasselbe steht bei S: und T: wie bei der Quelle und alle eine eigene UUID/Volumeseriennumer besitzen.

0x5e5e8bde5e8bad79 ist nur ein Beispiel

--
Meines Wssens ändert Acronis nach dem Klonen einer Partition anschließend nicht die UUID, und das kann unter Umständen zu Problemen führen, ggf. erst auffälliger/bemerkbar unter Win10 1903.

Falls die UUID identisch ist, kännte ein paar Tipps geben wie man die bei NTFS ändert, ist allerdings riskannt, wenn man nicht aufpasst, wenn man kein Backup aller angeschlossenen Geräte hat, von denen wöhrend des UUID/Volumesiernummer Änderns, weil es bei einem Fehler auf jeden Fall irgendein Gerät/Partition treffen könnte.
 
Zuletzt bearbeitet:
Kein Klonen - vollst. Lauifwerks-Backup auf ext. Fesplatte - kein Differentiellund oder Inkrementell.
Das Backup wird als *.tib-Datei geschrieben mit deren Hilfe bei Bedarf ein Recovery auf die zu vor gesicherte Platte bzw. im Falle eines Falles auf eine neue Platte problemlos zurückgeschrieben werden kann.
In meinem/unseren Fall sind 2 Backups vorgeschrieben - ein Backup muss immer außerhalb des Rechnerorts gelagert werden - Backups erfolgen immer abwechslend auf S: bzw. T:-Platte.
Danke für alle Hinweis ich prüfe das wenn ich wieder per Fernwartung an das System komme, evt sogar vor Ort wenn alles klappt in 3 Wochen.

Und in jedem Fall Danke für das Hilfsangebot komme darauf zurück Super Nett :daumen:
 
Zuletzt bearbeitet:
Also das gesamte Laufwerk bzw. die Partition wird gesichert, was man beim Klonen auch zuerst macht, aber die Sicherung wird nicht auf einem 2. Laufwerk /Partition wiederhergestellt, sondern die Sicherung wird als Datei (TrueImage-Archiv) auf einem externen Laufwerk in einem Ordner abgelegt? D.H. wenn es Probleme gibt bei dem Quell-Laufwerk wird die Sicherung wieder auf dem Quelllaufwerk zurückgespielt (solange Quell-Gerät OK und keine defekten Sektoren), richtig?

D.h. kein Klon auf 2. Speichermedium und 3., und somit keine identische Volumeseriennumern auf mehreren Geräten. Richtig?

Und es wird zur Sicherheit noch auf einem 2. externen Laufwerk noch die Sicherungsddateien abgelegt, richtig? Also dann S: und T:

Hab dir noch ne PM geschickt. Weiter unten dort ist ein Link zu heise, wo über einen etw. ähnlichen Fall mit externen Datenträgern berichtet wird, dass beim Upgrade der Win10-Installer vom Installationsmedium (USB Stick) externe HDD, und teilweise sogar auch intrne HDD als Installationsquelle, also beim Funktionsupgrade auf Win10 Ver 1903 Buchstabensalat bei den Installationsdatenträgern haben könnte, und das Setup dann Upgrade vermeidet. Ist ggf. auch ein genereller ein Bug auch in Ver 1903, wenn desswn Installer swchon das Problem aufweisen könnte. Auch wird hingewiesen, dass selbst interne HDDs betroffen sein könnten.
Angeblich beträfe es ggf. bloß zu-Ver.-1903-Upgradeinstallationen (also mit Migrieren), aber nicht wenn frisch also neu installiert würde.

Dann ggf. abwarten.
Als Alternative müsste man das Acronis-Bootmedium benutzen (ISO), was man mit dem Acronis-Media-Builder vom installierten Acronis unter Windows erstellen könnte, sofern du oder Freundin physischen Zugriff auf den Rechner hast. Oder eine neuere Acronis-Version probieren: Hinweise siehe in PM.
Ein paar Hinweise wie man das bootet mit grub2 oder grub4dos auch in PM

Oder abwarten bis Microsoft das Problem gelöst hat. Schien ja vorher nicht aufzutauchen.

"Mit anderen Chipsätzen bei ext. Gehäusen hatte ich übrigens ein solches LW-Problem in Acronis noch nie. "
Tritt/trat das >Problem auch mit früheren Win10 Versionen auf oder erst seit Ver 1903?
 
Zuletzt bearbeitet:
Problem habe ich nur bei diesem einem System und nur bei WIN 10 1903 ****. Ich habe noch 2 weitere Rechner die inzwischen auch WIN 10 1903 haben und ebenfalls mit jeweils 2. Backupplatten - in dem Falle allerdings 3,5-Zoll-Gehäuse bei denen keinerlei Probleme bezuüglich "Migration" ins System oder LW-Buchstabenverwechlung vorkommen bei gleichem Acronis 2017. Verwendete PCIe-Zusatzcard als 4 x USB 3.0-Controller und Mainboards sind identisch.

** Korrektur ***
Das LW-Problem mit Acronis 2017 existiert beim betroffenen System doch bereits seit WIN 10 1809
ist meinem Verweis hier im Thread auf
https://forum.acronis.com/forum/deu...ewahlten-lw-buchstaben-nach-erstelltem-backup
auch deutlich so zu entnehmen
 
Zuletzt bearbeitet:
Das sieht nach einem Win10 Bug 1903 aus, weil das selbe Acronis 2017 mit älterer Windows 10-version mit diesem gleichen 2,5 Adaptergehäuse nicht das Problem aufweist.

Weterhin schriebst du mir in der PM, dass nur Acronis durch den LW-Buchstabenwechsel betroffen sei, aber nicht das Windows 10 Ver 1903 selbst. Es ist ggf. schwerer zu erkennen, ob das Windows tatsächlich NICHT betroffen ist, weil beide externen Festplatten, die eine mit Laufwerk S:, die andere mit T haben das selbe Volume-Label: S und T:
"ext-HDD_PC-KH-S" haben. Das ist dann schwerer unterswcheidbar, wenn heimlich ein Buchbstabenwechsel stattfindet, was man in Acronis ntrl. bemerkt bei einem Backupvorgang, aber schlechter direkt in Windows.

Die beiden ext. Laufwerke mit S: und T: wurden aber auch nicht voneinader geklont, richtig?
Falls doch, dann selbe UUID.
Wahrscheinlich 2. externe Laufwerk auch manuell formatiert und dann das Label manuel umbennannt wie bei der 1. ext. HDD.

Sehr vewirrend, schriebst ja auch, dass ältere Windows Versionen nicht das Problem aufweisen, also dann wohl auch NICHT das erste Backup-Laufwerk noch auf 2. Laufwerk geklont, , was sonst in so 'nem Fall, wenn gleichzeitig angeschlossen, zu Problemen führen würde.
---
 
Zuletzt bearbeitet:
Die S:- und T:-Platte haben natürlich auch unterschiedliche Label "ext-HDD_PC-KH-S" und "ext-HDD_PC-KH-T"
Die LW-Buchstaben sind der jeweiligen Platte fest zugeordnet und können von keinem anderren USB-Gerät Anspruch genommen werden. Also S: für "ext-HDD_PC-KH-S" und T: für "ext-HDD_PC-KH-T"
Jedes Backupscript wurde extra einzeln für S: und T: erstellt - ein Klonen der Backupeinstellungen (was in Acronis ja möglich ist) erfolgte bewusst nicht.
Klonen an sich wurde in diesem Fall generell nie verwendet, weder beim erstellen der Backupscripte in Acronis noch in der Bearbeitung der Festplatten selbst. An einen WIN 10 1903 Bug glaube ich in diesem Falle nicht, da ich ja 2 weitere Rechner betreue bei denen das Verfahren mit 2. Backplatten problemlos unter WIN 10 1903 funktioniert.
Aber lass uns hier beenden - ich berichte wieder wenn ich meine Test mit den anderen USB-Cards und USB-Platten durch habe.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Vincent
Nicht unbedingt. Es wird beschrieben, dass Probleme bei Upgrade-Installationen auftreten können. Der andere PC mit Win 1903 wo auch auf 1903 geupgradet wurde , hat das Problem zwar nicht, aber mit gewisser Hardware bzw. Zufall kann das auch auftreten.

Was du machen könntest, wenn du in Köln bist, auf einer weiteren Partition auf der HDD auf dem selben System Win 10 1903 frisch zu installiernn.
Installieren dort Acronis und teste mit den 2 selben Asmedia ASM1153e Gehäusen, ob Acronis immer noch Probleme macht.
Wenn jetzt hier auch nicht auftritt, dann ist es eher ein Bug von Windows Ver 1903 (Upgradeinstallation).
Oder ein Zusammenspiel, oder Bug /Änderung in WIndows, k.A. und Acronis kommt damit nicht zu Recht.

Es können halt leicht unterschiedliche Windows-Installations-Konstllationen innerhalb eines Systems geben, durch Patches/Updates in welcher Reihenfolge Updates installiert wurden etc. Dann kann leicht mal zufällig irgendwas anders sein an der Win-Installation, an einem anderen Windows 10 PC, egal ob gleiche Hardware, was dann bei einer Upgradeinstallation, je nach Szenario ggf. zu Problemen führen könnte oder auch nicht.

Manchmal wurden hier schon Patches angeboten, Installation wurde nicht erfolgreichn durchgeführt, pklötzlich der Patch nicht mehr angeboten im Windows-Update etc.
---

Tut es das kein LW-Buchstabenwechsel, dann liegt es irgendwie im Zusammenspiel mit einer Win10 Upgrasdeinstallation.

Gut, wahrscheinlich ist es ggf. Kein Treiberproblem mit dieser Hardware. Würde erwarten, dass das installierte Acronis unter Windows den Windows-Treiber für die Geräte/Adapterbridge bentuzt. Nur das Acronis-Bootmedium benutzt eigene Treiber.
Wenn also das Gerät/Adapter unter Windowsm gut läuft und das Acronis benutzt den Windows-Treiber, dann wäre ein Treiberproblem durch Windows ggf. gut auschzuschließen und irgendein Bug an Acronis. Sicherheit hast du, wenn du mal mit dem selben USB-COntroller des Hosts-PCs mit dem selben USB-Adapter testet auf einem FIRSCH installierten Win20 1903 testet aufr dem selben System, wo der Fehller auftritt/auftrat, ob Acronis 2017 Backup läuft.
Noch größere Gewissheit hast du mit einer neueren Acronis, wo du Testversion bekommt etc siehe PM

Wenn du eine neue USB-PCIe-Karte reinsteckst wird ntrl. ein neuer Treiber installiert/ ggf. sauber reinstalliert und es könnte auch mit Upgradeinstallation laufen. Daran siehst du aber nicht woran es lag, auch mit anderen USB-Hostcontroller hätte es Probleme geben können, wenn der eingebaut und Treiber installiert war vor der Upgradeinstallation.
Dass die Lösungswege, den Treiber neu zu installieren nicht helfen, schließt nicht aus, dass es an einer >Upgraqdeinstallation liegt. In dem Fall wäre Windows vergurkt, dasss öftersd man neu installieren muss um ein sauber funktionierendes neuere Windows-Version zu haben.

Mehr kann ich hier aus der Ferne nicht vorschlagen und genau fetstellen. Dies kannst nur du rausfinden, wenn du selber damit z.B. so rumtestet, hier ein paar ggf. gute Vorschläge zur Eingrenzung. :)
 
Zuletzt bearbeitet:
Nur kurz registriert, um ein dickes Danke an TE Mtechlerin auszusprechen. Kann dank der angebotenen Dateien meine alten ASMedia 1051 Sharkoon Docks rehabilitieren! 4 Jahre alter Thread, immer noch aktuell.
 
  • Gefällt mir
Reaktionen: Vincent
I'm looking for ASM1153E firmware with 4k emulation. Apparently, the original delivery of the Fantec DB-ALU3e-6G in 2015 had firmware which performed a 4k emulation on the ASM1153E. But I can not find this firmware.
 
Zuletzt bearbeitet:
Zurück
Oben