Wenigstens ein paar Grundlagen zu kennen wäre schon hilfreich, wenn man sowas analysieren bzw. reparieren will.
Bestückung: "HC" und High Speed CMOS ICs, die HCT High Speed CMOS mit TTL Pegeln. Das übrige Geraffel (F, LS) sind verschiedene TTL Varianten. Kann man alles bei den üblichen Quellen (z. B. Wikipedia) nachlesen. Da TTL und CMOS andere Bereiche für die High und Low Pegel haben kann man die nicht einfach wahllos mixen.
MAC-Adresse: Warum willst Du die ändern? Es gab ein paar verschiedene Ansätze bei den LANCE-basierten Karten, von "gar nicht gespeichert, muss der Treiber beisteuern" über "batteriegepuffertes SRAM" bis zu I2C EEPROMs (wobei bei einer der Karten in meinem Besitz, die ein Register hatten, um den I2C in Software realisieren zu können (da wurden also letztlich die Pegel auf dem Bus direkt im Register abgebildet) invertierte Pegel hatte. Beim Experimentieren hatte ich mir dann erstmal das EEPROM gelöscht ;-/
Die KM62256 sind lt. Google SRAMs. Die kannst Du natürlich ausbauen und in einen EEPROM-Brenner stecken, viel Information wird sich damit nicht gewinnen lassen.
Die MAC-Adresse (Achtung: Auch hier wieder für jedermann offen zugängliches Grundlagenwissen!) teilen sich in drei Bytes Herstellerkennung und drei Bytes Karten-Kennung. Bei großen Stückzahlen brauchte der Hersteller dann u. U. mehrere Hersteller-Kennungen. Relevant ist die Eindeutigkeit der MAC-Adresse nur im jeweiligen Netzwerk-Segment - letztlich bestimmt die MAC-Adresse, wer das Paket empfängt, über das ARP Protokoll wird eine Tabelle aufgebaut, die IP-Adressen den MAC-Adressen zuordnet. Die kann man sich mit "arp -a" auch anschauen. Sobald über höhere Protokolle geroutet wird spielt die Eindeutigkeit über die Netzwerkgrenzen hinweg keine Rolle mehr. Wenn ich also zwischen zwei physikalisch getrennten Netzen z. B. IP route kann die gleiche MAC-Adresse in beiden Netzen vorhanden sein.
Da die vom Treiber ausgegebene MAC-Adresse gültig ist, warum willst Du sie ändern?
Dass das letzte Byte bei Deiner Karte vom Label abweicht, könnte auch bedeuten, dass irgendwann mal versehentlich auf das EEPROM geschrieben wurde.
Zu den Fehlermeldungen des Testprogramms: Fehler im Puffermanagement könnten auch auf defektes SRAM oder defekte Glue Logik hindeuten. Die LANCE Karten simulieren ein Dual Ported RAM, d. h. sowohl die CPU als auch der LANCE können auf den Speicher zugreifen. Einige der Karten Designs hatten Fehler in der Arbiter-Logik. Da konnte dann z. B. ein beschleunigter Atari den Speicher dauerhaft "hoggen", so dass der LANCE dann Daten verloren hat. In meinen Treibern gab es dazu entsprechende Compilerschalter, um Wartezyklen zu erzwingen. Wenn die Karte aber mal funktioniert hat ist eher davon auszugehen, dass irgendein Baustein der Glue Logik oder eben das SRAM einen Schuss hat.
Bei den Treibern konnte man auf jeden Fall z. T. auch manuell Adressen zuweisen - wichtig eben bei den Karten, die die Adresse gar nicht speichern oder im SRAM (wenn die Batterie leer ist oder ein anderer Treiber den Speicher, wo die Adresse erwartet wird, überschreibt).
Das Datum in den Startmeldungen ist Dir sicherlich schon aufgefallen - der Spaß ist mehr als 20 Jahre her, und seitdem Frank Naumann die Sachen übernommen hatte habe ich auch nichts mehr daran gemacht. Das ist einfach zu lange her. Da musst Du also selbst in die Sourcen schauen, um zu sehen, welcher Treiber für welche LANCE-basierte Karte wie tickt...
Viele Grüße,
Torsten
Thema: defekte PAM VME Netzwerkkarte ... (Gelesen 17612 mal)