Ich hatte ja zur MS-Doc für Hyper-V verlinkt (wenn Dich etwas "abgehängt" haben sollte, dann ja vermutlich eher diese Dokumentation von MS, in der auch erklärt wird, worin letztlich der Unterschied zu anderen Virtualisierungen besteht) ... es ist nun mal so, daß dann auch die "Hauptmaschine" (aka "root partition") als virtualisiertes System (mit ein paar speziellen Rechten, was die "Verwaltung" der realen Hardware angeht) auf dem Hypervisor läuft - EDIT: in etwa so, wie ein Linux auf einem Xen-Kernel laufen würde, falls Du das besser kennen solltest.
Das ist ein Unterschied zu den anderen Virtualisierungstechniken (unter Windows) wie VMware oder VirtualBox, wo die Virtualisierung als Prozess INNERHALB des Windows-Systems, das für die Bedienung der Hardware zuständig ist, arbeitet - ggf. mit ein paar Kernel-Modulen/-Treibern als Unterstützung. Dabei bedienen dann aber die Treiber des "Basis-OS" (also des Windows-Systems) die Hardware, während es bei Hyper-V dann eher die des Hypervisors sind (selbst wenn er sich die ggf. aus der "root partition" erst zusammenklaubt).
Kurz gefaßt könnte man (nicht in allen Aspekten stimmig, aber in weiten Teilen) behaupten, daß in dieser Konfiguration von Windows 10 dann ein vollkommen anderes OS als das, was man "sieht", die Steuerung der realen Hardware übernimmt und schon das System, mit dem Du dann "arbeiten" kannst, nur noch als virtuelle Maschine in dieser Umgebung des Hypervisors arbeitet. Im Ergebnis müssen auch für die "root partition" schon alle Netzwerk-Zugriffe virtualisiert werden - daher hat auch Dein System NUR NOCH virtuelle Netzwerk-Adapter (der PAN-Adapter kommt sicherlich von einer Zuweisung des BT-Adapters an diese VM):
Rich (BBCode):
0:16:359: check adapter(Bluetooth Device (Personal Area Network) #7) adapter 0x17: Ip: 0.0.0.0(0.0.0.0) (dhcp)
0:16:360: check adapter(Hyper-V Virtual Ethernet Adapter) adapter 0x45: Ip: 172.20.80.1(255.255.240.0) (static)
0:16:360: check adapter(Fortinet Virtual Ethernet Adapter (NDIS 6.30)) adapter 0xe: Ip: 0.0.0.0(0.0.0.0) (dhcp)
0:16:360: check adapter(Hyper-V Virtual Ethernet Adapter #2) adapter 0x22: Ip: 192.168.56.2(255.255.255.0) (static)
0:16:360: check adapter(Hyper-V Virtual Ethernet Adapter #3) adapter 0x25: Ip: 192.168.1.55(255.255.255.0) (dhcp)
0:16:366: check adapter(Hyper-V Virtual Ethernet Adapter #4) adapter 0x4: Ip: 192.168.178.30(255.255.255.0) (static)
0:16:366: compatible ipaddress (static) found: 192.168.178.30 on adapter 0x4
0:22:495: search on addr: 192.168.178.1
0:23:162: ---> read environment <---
0:23:266: open ftp 192.168.178.1 port 21
Wie Du selbst sehen kannst, haben die unterschiedliche IP-Adressen ... und vermutlich (was hier nicht zu erkennen ist) auch unterschiedliche "connectivity" zu anderen Netzwerk-Geräten, je nachdem, wie da die "virtuelle Netzwerk-Hardware" konfiguriert ist. Auch ist unklar, wie genau der Router und der PC miteinander verbunden waren - direkt oder über einen (Hardware-)Switch ... und das ist wiederum entscheidend dafür, wann und wie da die Erkennung einer aktiven Ethernet-Verbindung (über "media sense") am Ende läuft.
Das, was Deine "root partition" davon am Ende sieht, ist auch nur noch "virtuell" - d.h. in Deinem Windows kann (und wird) auch dann ein "connected" signalisiert werden (was auch richtig wäre, denn schließlich hängt der Adapter ja an einem "virtuellen Switch"), wenn die Hardware-Schnittstelle im Hypervisor vielleicht noch gar nicht aktiv ist, WEIL die FRITZ!Box gar nicht mit Strom versorgt wird und dennoch das einzige Gerät ist, was an dem betreffenden (physikalischen) Netzwerk-Adapter hängt.
Solange man also nicht sicher sein kann, daß tatsächlich auch der Test mit der anderen Box denselben (virtuellen) Netzwerk-Adapter verwendet HAT (dafür fehlt dann das Protokoll), kann man auch nicht sicher sein, was da ggf. bei der virtuellen Netzwerk-Kommunikation identisch und was vielleicht anders war. DAS ist es, was ich als "Mangel" an diesem Kreuztest sehe ... um die Ergebnisse auch WIRKLICH vergleichen zu können, müßte wenigstens noch 100% sicher sein, daß ebenfalls der Adapter mit dem Index 4 genutzt wurde und eigentlich wären sogar die Eigenschaften der Ethernet-Verbindung (mit Blick auf den ausgehandelten Übertragungsmodus) zu prüfen.
Zumal das Timing irgendwie "merkwürdig" aussieht im FTP-Protokoll ... nach 16 Sekunden wird ein Netzwerk-Adapter "ausgewählt" - so weit, so gut. Das kann tatsächlich etwas dauern bei der "enumeration" der Adapter und erst dann, wenn da einer selektiert wurde, beginnt das Aussenden der UDP-Broadcast-Pakete für die Suche nach dem Gerät.
Aber m.W. wird auch erst dann die Aufforderung angezeigt, das Gerät JETZT wieder mit Strom zu versorgen und wenn man nicht mit der Hand an irgendeinem der Stecker lauert bzw. da eine (ggf. auch per Software) schaltbare Steckdose verwendet, dann ist die Spanne von 6 Sekunden zwischen der Aufforderung (selbst wenn man die nicht "komplett" neu lesen muß, weil man das schon einige Male gemacht hat) und der Antwort der Box auf das UDP-Paket an Port 5035 schon recht kurz. Obendrein gibt es noch mind. zwei Netzwerk-Adapter im System, die mit DHCP arbeiten - wo also auch erst ein (virtuelles) "connected" eine Suche nach einer IP-Adresse auslöst.
Denn vorher wird man ja schon SEHR deutlich dazu aufgefordert, das Gerät stromlos zu machen und auch wenn das bei VR9-Modellen vielleicht nicht sooo wichtig ist, wie bei späteren, würde man sich ja (gerade als "Anfänger", wenn man die genauen Abläufe noch nicht so gut kennt - und DIESES "Anfänger" legt man dann auch nicht ab, indem man nur ein paar Boxen mit dem Recovery-Programm bearbeitet, sondern erst, wenn man sich für das interessiert, was dabei vom Recovery-Programm gemacht wird und welche Reaktionen das dann auf der Box auslöst) dennoch erst einmal an diese - recht genauen - "Anweisungen" des Recovery-Programms halten. Mit etwas Pech (und einer sehr neuen Version des Bootloader-Codes - wobei ich nicht sicher bin, ob es das bei VR9-Modellen tatsächlich auch schon gab) braucht es dann gerade auch dieses "power-off reset", damit da der richtige Pfad von EVA eingeschlagen wird beim Initialisieren der Box.
Wie Du weiter oben nachlesen kannst, hatte ich auch schon vor dem Blick in Dein FTP-Protokoll die Netzwerk-Verbindung im Verdacht (in #3) und in einer Umgebung wie bei Dir kann es dafür eben mehrere Ursachen geben. Schon die Tatsache, daß da bei einigen Paketen die TCP-Checksummen nicht stimmen, sollte aufhorchen lassen - neben reinen Fehlern bei der Übertragung der Daten kommen in einer virtualisierten Umgebung aber noch so manch andere Möglichkeiten zusammen, wo da etwas daneben gehen kann.
Zum Beispiel sind hier ja zwei verschiedene "Netzwerk-Treiber" im Spiel (einmal der für den virtuellen Adapter und einmal der für den physikalischen, der vom Hypervisor "bedient" wird) und wenn das Berechnen der Prüfsummen an die Netzwerk-Hardware ausgelagert werden soll (
https://docs.microsoft.com/en-us/wi...g/technologies/hpn/hpn-hardware-only-features - das firmiert dann alles unter "Offloading"), dann kann es da im Zusammenspiel auch schon mal knirschen ... deshalb bevorzuge ich bei der Untersuchung solcher Probleme dann immer die "echte" Hardware, wo auch der Treiber so konfiguriert werden kann, daß eben kein Offloading verwendet wird und man einigermaßen sicher sein kann, daß sich nicht aus der "Aufgabenverteilung" zwischen dem Treiber für den Netzwerk-Adapter und dem IP-Stack des OS zusätzliche Probleme ergeben können.
Außerdem würde ich - in dieser Umgebung - nicht mal Wetten eingehen wollen, daß die anderen Tests mit den "kleinen" Ethernet-Geschwindigkeiten auch tatsächlich auf der realen Hardware mit der verringerten Geschwindigkeit gearbeitet haben und nicht nur auf der virtuellen - wenn ein virtueller Adapter auch tatsächlich bei 10 Mbit/s nur 10 Mbit/s "überträgt", dauert das dann auch schon "länger". Und das kann auch ein weiterer Unterschied zwischen dem Test mit der "unwilligen" Box und dem anderen Gerät sein - wenn die Autonegotiation bei der anderen Box "nur" auf 100 oder gar 10 Mbit/s kam, dann werden ja auch nur zwei und nicht alle vier Adernpaare im Ethernet-Kabel verwendet. WENN dann die beiden "ungenutzten" irgendwie "wacklig" sind (bis hin zum - unbemerkten - Kabelbruch in einem Adernpaar, was bei HF ja nicht automatisch mit einer Unterbrechung gleichzusetzen ist) und bei dieser Box dennoch genutzt werden, könnte das auch Übertragungsfehler erklären - auch hier würde ich schon deshalb "mehr Kontrolle" über die Hardware haben wollen, als sie ein Hypervisor von MS auf dem PC bietet.
Hinzu kommt noch, daß die meisten der Erfahrungen, die in diesem Board diskutiert werden, mit Windows-Editionen gemacht wurden, wo eben KEINE Hyper-V-Virtualisierung verwendet wird (entweder weil die Hardware das nicht hergibt, denn Hyper-V braucht recht moderne Prozessor-Features als "Hardware-Support" für diese Virtualisierungen oder wo die Windows-Edition das auch schlicht nicht bietet - selbst wenn man es "mit Tricks" auch bis hin zum Windows 10 Home aktivieren könnte) ... selbst mit VMware (in Gestalt des VMware-Players) und Oracle VM VirtualBox dürften mehr (und längere) Erfahrungen vorliegen, als mit Hyper-V (auch wenn MS das schon seit Windows 7 und dem "XP Mode" auch in "kleineren" Editionen verwendet ... es ist eben nicht überall "so einfach" auch zu aktivieren).
Wieso Dich jetzt die Spannungen - generell und "beim Flashen" - so faszinieren, verstehe ich nicht ... wenn Du eine Option hast, das Netzteil gegen ein anderes zu tauschen, dann mach das einfach EINMAL und dann sollte es "auch gut" sein (meinetwegen auch über Kreuz mit der Box, wo das alles funktioniert). Es gibt bis zum Zeitpunkt dieser Fehler noch keine plausible Erklärung, warum da plötzlich der Stromverbrauch ansteigen sollte und damit dann ggf. ein Einbruch bei der Versorgungsspannung entstehen könnte, der die Netzwerk-Übertragungen so sehr beeinträchtigt ... wenn da tatsächlich "Brummen" eingestreut werden sollte über die Spannungsregler auf dem PCB (die sollten das schon ausreichend glätten können), dann sollte das leicht zu ermitteln sein (das sollte man mit einem Oszi bei entsprechender Auflösung ja sehen können) - allerdings wäre das schon "recht exotisch", wenn das nur "manche" Pakete verunstalten sollte und dann nicht alle. Aber meinetwegen kommen Störungen auch noch über das Netzwerk-Kabel zwischen PC und Box ... auch wenn da die differentielle Signalübertragung das einigermaßen robust gegenüber "Fremdeinstrahlungen" machen sollte.
Von einem "erhöhten Stromverbrauch" an der Stelle, wo das bei Dir offenbar klemmt, würde ich jedenfalls nicht ausgehen. Da läuft die CPU, der Hauptspeicher, der Netzwerk-Switch, die PHYs und - zeitlich begrenzt auf die beiden Intervalle, in denen mtd3 und mtd4 beschrieben werden (schau in Dein eigenes FTP-Protokoll) - noch das Flashen von wenigen Zellen im SPI-Flash (bei einer 7490). Danach wird sogar noch einmal zur Kontrolle gelesen (
RETR env), auch wenn ich keine Wetten darauf abschließen würde, daß dabei die Daten tatsächlich "frisch" aus dem SPI-Flash stammen - zumal auch unklar bleibt, aus welcher (nach dem Flashen ja identischen) TFFS-Partition die Daten dann stammen sollen.
Von Sekunde 41 bis Sekunde 60 (in Deinem Protokoll in #1) läuft da jedenfalls nichts zusätzlich, was irgendwie "erhöhten Stromverbrauch" erzeugen könnte ... wenn man mal davon absieht, daß hier die CPU dann (m.W. aber auch erst nach der kompletten Datenübertragung) etwas mehr beschäftigt wird, wenn der Kernel zu entpacken ist. Aber alles das, was da sonst noch so in einer FRITZ!Box enthalten ist (vom Xilinx-FPGA und den POTS- und ISDN-Anschlüssen über die WLAN-Hardware bis zu den USB-Ports) und für dessen Versorgung die Spannungsregler ebenfalls ausgelegt sind (m.W. kommen da immer noch 12 V Gleichspannung aus den Schaltnetzteilen von AVM und auch die sollten schon einigermaßen geglättet sein, wobei die Spannungsregler auf dem PCB noch genug Reserven haben sollten), IST zu diesem Zeitpunkt nicht in Betrieb.
Gibt es ein Recovery-Tool von AVM für Linux?
Nicht daß ich wüßte ...
Aber es gibt auch für Linux alternative Software (halt nicht von AVM) - üblicherweise würde ich hier wieder die "eigene Suche" empfehlen, aber ich mache mal eine Ausnahme und führe ein zwei Links auf (weil für diese Threads habe ich tatsächlich die Links auch in meiner Liste):
https://www.ip-phone-forum.de/threads/wie-recovere-ich-eigentlich-richtig.299790/post-2280100 - hier geht es eher darum, was das Recovery-Programm von AVM noch für Probleme machen kann ... aber irgendwo sollte da auch stehen, wie genau der Ablauf bei so einem Recovery-Lauf für eine 7490 eigentlich aussieht (was man teilweise ja auch im FTP-Log verfolgen kann)
https://www.ip-phone-forum.de/threa...n-aus-yourfritz-eva_tools.298591/post-2264928 - hier geht es dann tatsächlich um alternative Tools, mit denen man die Firmware auf die Box bringen kann (mit einer Linux-Shell oder auch mit MS PowerShell)
Wobei es nicht wirklich um die Frage des OS geht (außer daß man bei einem Linux-Host halt auch etwas genauer hinschauen kann - zumindest nach meiner Einschätzung) ... der Verweis erfolgte meinerseits nur, weil es (meines Wissens) deutlich mehr Linux-Versionen gibt, die als "Live-System" direkt vom USB-Stick gestartet werden können (auch wenn das bei Windows ebenfalls machbar ist, braucht das dort schon "spezielle Kenntnisse" oder entsprechende Programme, wenn man sich ein "Windows To Go" auf einem Stick zusammenstellen will) und wenn man tatsächlich dieselbe Maschine, auf der Windows mit Hyper-V installiert ist, benutzen muß, ist das zumindest eine Alternative.
Aber ich gehe mal davon aus, daß Du mittlerweile die TFFS-Partitionen im SPI-Flash gründlich genug gelöscht hast (das wird mit weiteren Versuchen vermutlich auch nicht besser) und dann könntest Du zumindest in Erwägung ziehen, ab jetzt nur noch die zu installierende Software ins RAM zu schreiben ... etwas anderes macht das Recovery-Programm in dem letzten Schritt, der bei Dir dann so oft scheitert, auch nicht. Welche Plattform Du dafür dann verwenden willst, spielt nicht wirklich eine entscheidende Rolle ... solange Du zusätzliche Fehlerquellen (wie eben Virtualisierung oder Verkabelung, etc.) aus dem Spiel läßt.
Im Recovery-Thread habe ich auch die Alternativen beschrieben, wie man das anders bzw. in Deinem Kontext wohl sogar besser verkabeln könnte - wenn Du keinen "managed switch" hast (wo man i.d.R. die Ports auf einen Modus festnageln kann), findest Du ja vielleicht doch einen (älteren) 100 Mbit/s-Switch, den Du zwischen PC und Box klemmen kannst; dann werden ebenfalls automatisch nur noch 2 Adernpaare im Ethernet-Kabel genutzt (zwischen Box und Switch). Es soll sogar schon vorgekommen sein, daß zwei (vermeintlich) identische Geräte desselben Herstellers alleine aufgrund von Bauteil-Toleranzen bei automatischer Aushandlung von Ethernet-Verbindungen mit derselben Gegenstelle und demselben Kabel unterschiedliche Ergebnisse erzielten ... von anderen denkbaren Fehlerquellen (Kabelbrüche hatte ich schon erwähnt und daß die bei den verwendeten Frequenzen nicht mehr automatisch in einer "Unterbrechung" enden müssen) braucht man da noch gar nicht anfangen.
Wenn Du wissen möchtest, ob tatsächlich die Netzwerk-Hardware IN DER BOX so wacklig ist, daß diese "Schuld" an dem Problem trägt, dann kannst Du den FTP-Client ja einfach selbst (per Skript) so lange mit Kommandos (und darauf folgenden Datenübertragungen, z.B. nach einem
RETR env) traktieren, bis Du auch dabei einen Fehler verursachen konntest. Wenn das aber nur bei "Bulk-Übertragungen" von Daten auftritt (wo dann auch auf der PC-Seite eher "segmentation offload" oder auch "checksum offload" verwendet wird und das auch im Zusammenhang mit "Warteschlangen", weil die Daten schneller "bereitgestellt" werden, als sie gesendet werden können - das Ziel muß ja auch die bisher übertragenen Daten erst mal quittieren), dann würde ich (aus dem Bauch heraus und mit der Erfahrung, die sich mit den Jahren halt so ansammelt) hier eher auf ein Problem beim Virtualisieren der Hardware tippen.
Warum die sich dann bei anderen FRITZ!Boxen bisher nicht ausgewirkt hat, weiß ich auch nicht ... aber um das tatsächlich als "Mysterium" zu sehen, müßte man gleichzeitig auch 100% sicher sein, daß die "Testbedingungen" dabei immer identisch waren - von der Hardware bis zu den Software-Einstellungen. Angesichts des hohen "Automatisierungsgrads" bei diesen Aktionen, bin ich aber eher skeptisch, daß das auch jedes Mal tatsächlich überprüft wurde ... und "Kreuztests" helfen halt auch nur dann, wenn man die Umstände richtig einschätzt und nicht die falschen Schlüsse aus Ergebnissen zieht.
Wo ich auch noch so meine Probleme habe, Dir zu folgen, sind die Vermutungen, was genau die Anzeigen bei "REJECTED" jetzt bedeuten sollen. WIR hier haben die bisher genau ein einziges Mal zu Gesicht bekommen (in Deinem Protokoll der RS232-Kommunikation in #1) ... wärst DU nicht derjenige, der die Protokolle ZWEIER Versuche miteinander vergleichen sollte, um dabei dann zu erkennen, ob das tatsächlich immer dieselben Adressen sind (was ich für sehr unwahrscheinlich halte, weil das dann auch immer dieselben Fehler bei der Übertragung sein müßten)?
Da diese Meldungen ja auch beim Übertragen der TFFS-Images auftreten, ist erst einmal nicht anzunehmen, daß sie erst etwas mit dem Entpacken des Kernels zu tun haben ... also MÜSSEN sie sich ganz offensichtlich auf Übertragungsprobleme beziehen - denn gleichzeitig tauchen sie ja auch zu einem späteren Zeitpunkt weiter auf, wo es gar nicht mehr um Zugriff auf den Flash-Speicher geht. Die erfolgen nun mal nur beim Schreiben der beiden TFFS-Partitionen und danach erst wieder, wenn das geladene FRITZ!OS sich in den Flash installieren will - obendrein sind das auch noch unterschiedliche Flash-Speicher (NAND für das OS, SPI-NOR für das TFFS-Image).
Wenn Du die Zugriffe einfach mal dadurch "zerlegst", daß Du eben NICHT das Recovery-Programm benutzt, was ja (siehe FTP-Protokoll) mehrere Operationen nacheinander ausführt und mit dem man dann (offensichtlich) keine Zuordnung der Anzeigen in der seriellen Console zu den Aktionen des Recovery-Programms mehr herstellen kann, dann dürfte das auch schon wieder deutlich klarer werden - einfach weil man dann auch erkennen kann, WELCHE Operationen denn jetzt zu den beobachteten Meldungen führen.
Denn selbst "raten" fällt - angesichts der unterschiedlichen "Adressen" in den Meldungen - ja einigermaßen schwer. Während die Adressen 0xAF86A991 bis 0xAF8909CC aus dem "ersten Block" noch einigermaßen zu den MIPS-Adressierungen passen würden (
https://s3-eu-west-1.amazonaws.com/downloads-mips/documents/MD00091-2B-MIPS64PRA-AFP-06.03.pdf - Kapitel 4.3) und vielleicht auch noch die im "zweiten Block" (0xA7756FD5 bis 0xA779A771) passen KÖNNTEN, wird das bei denen im "dritten Block" dann schon deutlich schwerer. Die ersten beiden wären ja dann
kseg1, was gemeinhin "uncached" und "unmapped" ist und für "memory-mapped I/O" verwendet wird, wobei vermutlich auch im AVM-Code für EVA eher auf DMA für die "Bedienung" der Ethernet-Schnittstelle (zum internen Switch hin) gesetzt wird (wozu auch
kseg1 wieder passen würde) - für den Linux-Kernel kann man das in den von AVM bereitgestellten Source-Code-Paketen nachlesen.
Die Adressen zwischen 0x2F6E08D7 und 0x3173B908 lägen dann ja wieder in "kuseg" (das ist über die MMU gemappter Speicher, dessen Adressen zwischen 0x0 und 0x7FFFFFFF liegen können), aber schon auf einem einigermaßen "komischen" Mapping. Die 7490 hat 256 MB RAM (das sind hexadezimal dann 0x10000000 Bytes) - selbst wenn man jetzt mal unterstellt, daß der Bootloader da tatsächlich das Memory-Management ÜBERHAUPT aktiviert, warum sollte das dann auf diese "krummen Adressen" erfolgen? Schon weil das an sich nur wenig Sinn ergibt, denn der übertragene, entpackte und gestartete Kernel initialisiert das dann ohnehin noch einmal neu und der WILL schon mit Adressen aus
kseg0 gestartet werden, wie man an den Ladeadressen im Kernel-Image sieht - der 07.29-Kernel der 7490 hat 0x80002000 als Lade- und 0x80006DD0 als Entry-Adresse.
Auch ausgehend vom
STOR-Kommando im FTP-Dialog (
0:41:153: send: STOR 0x8df3f300 0x90000000) sind da eher Adressen aus
kseg0 im Einsatz (das ist ja genau die "obere Grenze" des "unmapped, cached"-Speichers, wenn 256 MB "physisch" vorhanden sind) - wobei man natürlich (ohne die Quellen zu kennen) nicht AUSSCHLIESSEN kann, daß AVM da tatsächlich die MMU nutzt. Nur wofür sollte das hier gut sein? Es verkompliziert die Sache ja nur unnötig ... niemand kann dem Bootloader verbieten, seinerseits auch (ständig) mit Adressen aus
kseg0 zu hantieren, zumal das eben einiges leichter macht.
Ich bezweifle zwar ("aus Gründen") eher, daß es sich um "echte" RAM-Adressen handelt, habe aber gleichzeitig auch keine bessere Idee, welche Hexadezimalwerte AVM in diesen Messages anzeigt (zumal man die auch nicht so häufig zu Gesicht bekommt). Für RAM-Adressen spräche es aber wieder, daß alle diese Angaben innerhalb der Spanne liegen, die durch die Größe des zu übertragenden Images (0x20BDD00) abgesteckt wird. Nimmt man den ersten Wert aus dem "dritten Block" (0x2F6E08D7) und addiert die Größe des Images dazu, liegt auch der letzte Wert (0x3173B908) noch "im Rahmen".
Andererseits fände ich es auch komisch, wenn hier die Netzwerk-Buffer NICHT auf irgendwelchen integralen Grenzen liegen würden (ich bin nicht mal sicher, ob man das bei I/O-Operationen tatsächlich ohne Alignment starten könnte) - aber das kann natürlich auch der Buffer nach einem Umkopieren sein ... dennoch ist eine Adresse für einen Buffer, die auf "1" endet (auch wenn's später noch andere, auch gerade Werte gibt), schon einigermaßen ungewöhnlich und entweder sind die Daten da tatsächlich komplett "unaligned" oder das ist nicht der Beginn der Daten im jeweiligen Block, sondern irgendein Flag, wohin diese "Adresse" dann zeigt.
Rein von der Logik her, würde ich diesen Meldungen aber auch nicht zu viel Bedeutung zumessen ... zumindest nicht, ohne mir zuvor den dazu passenden Mitschnitt der Netzwerk-Kommunikation angesehen zu haben. Denn ich würde eigentlich davon ausgehen, daß der TCP-Stack im Bootloader, WENN er einen Fehler bemerkt (wozu ich auch Checksummen-Fehler in TCP-Paketen zählen würde), das entsprechende Paket NICHT quittiert (jedenfalls nicht mit einem ACK) und dann sollte ja - zumindest in der Theorie - auch eine erneute Übertragung (Retransmission) stattfinden - dafür macht man den ganzen TCP-Zirkus schließlich ... ansonsten könnte man ja auch UDP (z.B. mit TFTP auf L5) nehmen (ja, ich weiß, da gibt es keine "Kommandos" - es geht "ums Prinzip" der Sicherungsschicht beim TCP).
Gleichzeitig ist es natürlich dennoch auffallend, daß die Abstände häufig genau 0x5A0 Bytes betragen ... das wären dann 1440 Bytes dezimal und könnte auf den ersten Blick an gängige Nutzdaten-Größen im Netzwerk erinnern. Aber auch das paßt eigentlich "nicht so richtig" zu TCP-Paketen, denn bei einer (Ethernet-)MTU von 1500 Bytes, wären nach Abzug der IPv4- und TCP-Header (jeweils 20 Bytes, wenn keine Erweiterungen verwendet werden) immer noch 1460 Bytes an Nutzdaten pro Paket zu erwarten (beim FTP-Protokoll ist ja eher kein "padding" zu erwarten und die verbleibenden 20 Bytes könnten eigentlich auch genutzt werden - außer irgendein "segmentation offloading" ist da doch involviert und das würde ggf. auch IPv6-Header (mit 40 Bytes) berücksichtigen - was aber EVA wieder nicht kennt). Aber auch DAS sollte ein Mitschnitt schnell zeigen können (ich habe leider gerade keinen alten zur Hand und mein Capture-Driver für WireShark funktioniert unter Windows nicht so richtig, so daß ich auch kein Recovery-Programm mitschneiden kann) - neben eventuellen NACKs und Retransmissions, sollte man da auch die Paketgrößen sehen können.
So, das reicht dann auch wieder ... ich empfehle Dir erneut (wie schon weiter oben in #3), noch nach weiteren "Quellen" zum Aufbau und den Besonderheiten einer 7490 zu suchen und das zu verstehen, bevor Du weitere Experimente startest. Diese Recherche kann hier oder an anderen Stellen im Internet erfolgen - wobei ich mich zu der Behauptung versteigen würde, daß hier (und früher bei "wehavemorefun" bzw. jetzt bei Boxmatrix, wobei letzteres "nur noch" Statistik ist und kaum noch Hintergrund-Info liefert - jedenfalls nach meinem Dafürhalten) dann doch die "Primärquellen" liegen und vieles, was man da draußen im Internet noch so findet, auf "Nacherzählungen" dessen basiert, was hier mal veröffentlicht wurde (von ca. 2005 bis in die "Jetzt-Zeit").
Es gäbe jedenfalls noch so einige Ansatzpunkte (angefangen beim Mitschnitt der Netzwerk-Kommunikation zur Klärung, was da gesendet und was empfangen wird - und ob es tatsächlich auch Retransmissions gibt) für weitere Tests, bevor man die Box dann endgültig entsorgt. Zumal bei der 7490 noch dazu kommt, daß zwei der Ethernet-PHYs (für die DA/AD-Wandlung der Ethernet-Schnittstellen) bereits im SoC integriert sind und zwei weitere als "diskrete" Bauelemente (was nur ausdrücken soll, daß sie NICHT im SoC integriert sind) vorliegen. Wenn tatsächlich alle vier Ports nur Schrott übertragen, dann müßte der Schaden ja erst HINTER diesen PHYs (in Richtung Switch und weiter zur CPU) liegen ... da wird's dann aber zunehmend enger mit möglichen Erklärungen, warum nur einige (der erste Block hat 38 REJECTED-Meldungen, der zweite 57 - bei exakt der gleichen Datenmenge, die zu übertragen ist) der Netzwerk-Pakete nicht richtig ankommen. Zumindest wenn man davon ausgehen wollte, daß tatsächlich die Hardware der 7490 schadhaft ist ...
