Beiträge von Arnulf zu Linden

Wenn die Suchmaschine gefüttert wird mit: sis 730 133 problem

kommt als ein Treffer:

und damit ist klar, dass das mit 133/133/33 nicht funktionieren kann.

Ein Athlon XP 2400+ läuft auf dem Brett nicht, auch nicht mit 100/100/33. Es startet zwar, friert dann aber bei memtest86+ im ersten Durchlauf ein. Somit bleibt es beim Athlon XP 2200+, der @ 112/112/34 mit mageren 1,512 GHz läuft.

Die deutschsprachige WP ist zu SiS-Chipsets 'n Totalausfall. In den beiden für den SiS 730 relevanten Artikel in der englischsprachigen WP wurde obiger Link als Referenz hinzugefügt. Da stand vorher nämlich, dass der SiS 730 133 MHz FSB unterstützt, was aber real wohl erst ab stepping B1 der Fall sein dürfte.

Besonders ärgerlich: Das Tauschen aller 20 auf dem Brett vorhandenen, optisch unauffälligen, grünen Luxon-Zeitbomben, was in diesem Fall alle Elkos ≥ 470 µF betraf, war wahrscheinlich völlig unnötig, da dadurch keine Verbesserung erreicht wurde.

Jetzt nach dem Elko-Tausch:

memtest86+ 5.3.1b

Nach Deinem Hinweis:

memtest86+ 4.3.6: schmeißt @ 133/133/33 bei Test #6 Fehler, läuft @ 112/112/34 fehlerfrei durch

memtest86+ 7.2.0: schmeißt @ 133/133/33 bei Test #7 Fehler, läuft @ 112/112/34 fehlerfrei durch

Damals vor dem Elko-Tausch:

memtest86+ 5.0.1

Zitat von Blue

Hatte mal fälle das neuere oder ältere Versionen Fehler produzierten, was wohl Software bedingt war..

Das hatte ich nur mal bei Hardware aus dem Mesozoikum, Dunstkreis 386…486.

Und dann laufen ältere Version u.U. nicht korrekt auf sehr neuer Hardware, wobei hier das Fehlerbild von "friert irgednwann ein" bis "startet nicht" reicht. Auf x86_64 sollte es nach meiner Erfahrung Version 6 64-Bit sein.

Thread-Exhumierung:

Alle Elkos ≥ 470 µF wurden getauscht: Immer noch der gleiche Mist.

Mit Einstellung 112/112/34 MHz läuft es stabil, mit 133/133/33 MHz, was der Athlon XP2200+ und die beiden 512 MiB SDRAM PC-133 Riegel können und auf anderen Brettern auch liefern, schmeißt memtest86+ reproduzierbar bei Test #7 weiße Schrift auf rotem Grund. Selbst maximal konservative RAM-timings schaffen keine Abhilfe.

Gibt es da noch irgendeine Chance, das Brett stabil mit 133 MHz FSB in Gang zu kriegen?

zwei Kleinigkeiten:

1. Das "umbruchgeschützte Leerzeichen" (No-Break Space) U+00A0 und das "schmale umbruchgeschützte Leerzeichen" (Narrow No-Break Space) U+202F werden von der Software ungefragt in das "Leerzeichen" (Space) U+0020 konvertiert. Somit lassen sich unerwünschte Umbrüche etwa zwischen Zahlen und Einheiten nicht mehr verhindern.
2. Die von der Software bereitgestellten Smileys sind aufgrund ihrer aliasing-Optik schlechter zu erkennen als die früher im WHF üblichen und nur teilweise übernommenen Smileys in pixelized-Optik.
   <Geschmacksfrage>Ich finde diese neuen "matschigen" Smileys hässlich.</Geschmacksfrage>

Zitat von Blue

K7S5A […] lief nur mit Linux noch stabil, da RAM Errors und badmem-flag gesetzt war. Schuldig waren die Elkos beim RAM Slot ca..

Dieser Hinweis in Kombination mit der Tatsache, dass nach der ersten Runde Elkotausch auf einem K7S5A das onboard-100Base-TX (SiS 900) nach Jahren wieder funktioniert, führte dazu, dass am Wochenende auf beiden K7S5A alle Elkos ≥ 1000 µF getauscht wurden.

Vor dem Elkotausch durften bei beiden K7S5A keine aggressiven RAM timings eingestellt werden, also etwa für "DDR PC-400 CL3"-Riegel CL2 @ FSB266, was auf vielen anderen Brettern problemlos läuft. Die beiden K7S5A liefen nur mit den "setup defaults" (Timing Setting Mode = Normal; SDR/DDR CAS Latency = SPD). nach dem Elkotausch laufen beide K7S5A mit aggressiven RAM timings. Gesteckt sind auf beiden K7S5A je 2 GiB RAM = 2× 1 GiB DDR PC-400 CL3. Im BIOS wurden nun gesetzt Timing Setting Mode = Ultra; SDR/DDR CAS Latency = 2T. memtest86+ wurde auf beiden K7S5A nach jeweils drei fehlerfreien Durchläufen beendet.

Am onboard USB 1.1 funktioniert nun auch wieder eine USB-Maus. Vor dem Elkotausch war daran nicht zu denken. Es ging nur mit einer PS/2-Maus oder einer USB-Maus an einer PCI USB 2.0 Karte.

Löten an 4-layer-PCB ist nach wie vor sehr nervig, aber für den ollen Kram gibt es ja keinen Ersatz mehr oder nur noch zu Mondpreisen.

PcChips M810D

Vor einiger Zeit verabschiedete sich USB partiell mit einem kleinen Rauchwölkchen. Da muss es wohl 'n Kurzen beim Anschluss eines Kartenlesers gegeben haben. Seitdem waren die vier Heck-USB-Anschlüsse, die zwei der drei auf dem Brett verfügbaren USB-Ports entsprechen, und der mit einem Pärchen dieser Anschlüsse shared Pinheader, an den der Kartenleser angeschlossen worden war, tot. Linux (lspci, lsusb, cat /proc/interrupts) zeigte die USB-Ports aber weiterhin korrekt an. Also mal 'n self-powered-hub angeschlossen und der wurde von Linux ebenfalls erkannt. Eine daran angeschlossene USB-Maus funktionierte. Das legte die Vermutung nahe, das nur die +5 V an den Heck-USB-Anschlüssen nicht mehr funktionierten, D+ und D- hingegen schon.

Nach dem Einlöten einer selbstrückstellenden Sicherung (60 V; 0,5 A hold; 1,0 A trip), was durch Nutzung des +5 V-Pins des shared Pinheaders und eines nicht genutzten Lötstützpunktes auf dem Brett, an dem die +5 V vom Netzteil anliegen, sogar auf der Bauteilseite des Bretts möglich war, funtkionieren die vier Heck-USB-Anschlüsse wieder.

Warum alle vier Heck-USB-Anschlüsse, also zwei USB-Ports auf einer +5 V-Leitung liegen, erschließt sich mir allerdings nicht. Eigentlich sollte doch jeder USB-Port seine eigene, im Falle von USB 2.0 mit jeweils 0,5 A abgesicherte +5 V-Leitung haben.

Elko-Tausch auf einem der beiden mit Blähkos belasteten Asus A7N8X-E Deluxe:

3300 µF 6,3 V → 3300 µF 10 V (8 Stk.)

Beim Ausbau des Bretts fiel noch ein 820 µF 6,3 V RM 3,5 auf, der auf halb acht hing. Kann natürlich auch durch die Elko-Pest verursacht worden sein, sah aber eher nach der Folge eines rein mechanischen Ereignisses aus. Jedenfalls fiel die Entscheidung, auch diesen und einen baugleichen Elko zu ersetzen. 820 µF ist jetzt aber noch so gängig, als dass man diesen Wert inna Kramkiste liegen hätte. Also wurde am Nachmittag die witterungsbedingt unvermeidliche Fahrradtour um eine Schleife zum letzten Elektronikbauteilehöker in H verlängert. Der hatte nur 820 µF 25 V RM 5,0, aber egal. Auf dem Brett befinden sich in der Nähe dieser beiden Elkos weder Stecker noch Slots noch Kühler. Und RM 3,5 scheint eh gerade auszusterben.

Kolateralschaden:

Für den Tausch von fünf der acht 3300 µF musste der Prozessorkühler runter. Beim Abnehmen oder wieder aufsetzen des Kühlers, oder einfach nur so, hat sich der Athlon XP 3200+ AXDA3200DKV4E sehr wahrscheinlich final abgeseilt. Lüfter drehen, aber kein POST, keine error beeps …

Mit dem letzten Athlon XP 3200+ AXDA3200DKV4E aus der Kramkiste läuft die Kiste, gerade rödelt memtest86+. Das sieht also nicht gut aus für den anderen Athlon XP 3200+, eine letzte Chance auf 'nem anderen Brett bekommt er aber noch, bevor dessen Beisetzung eingeleitet wird.

Nachtrag:

Auf 'nem anderen Brett kommt mit dem Prozessor auch nix mehr. Der ist hin!

Zitat von Xaar

Wie wäre es mit der Veröffentlichung vom Quellcode von MS Xenix 1.00 oder MS OS/2 1.00? Oder noch besser: Dem BASIC für den Altair 8800?

Ist schon klar: Du hast die dazu passenden Maschinen zu Hause stehen und möchtest OSS drauf laufen lassen.

Das Update 23H2 → 24H2 kam mit, nachdem einmal "Nach Updates suchen" angeklickt wurde. So 'ne dicke Blase lasse ich möglichst dann laufen, wenn die Computer gerade nicht anderweitig benötigt werden.

Wenn im lokalen Netzwerk ein Server oder NAS verfügbar ist, sollte nach Abschluss des Updates überprüft werden, ob noch Zugriff darauf möglich ist, da das Update die Einstellung "Unsichere Gastanmeldungen aktivieren" zurück setzt. Ein Zugriff auf Server oder NAS, die einfach und schlicht ohne nerviges user/password-Gedöns konfiguriert sind, ist dann nicht mehr möglich.

Das Update 23H2 → 24H2 hat die Kiste genommen. Das wird entsprechend bei Einstellungen → System → Info angezeigt. Das Problem wurde durch das Januar-Update für 24H2 verursacht:

2025-01 Kumulatives Update für Windows 11 Version 24H2 für x64-basierte Systeme (KB5050009)

Da kommen zwei Möglichkeiten in Betracht:

1. Mit dem Jahreswechsel schießt Microsoft die ollen Kisten ins Aus.

2. Das Update hat was inne Windeln.

Für 1. findet sich im Internet auf die Schnelle kein Hinweis, dafür aber umso mehr Hinweise für 2..

Daher wird das jetzt so lange ausgesessen, bis der Rechner wieder benötigt wird. Wenn dann immer noch irgendein Update hängt, fliegt das Windows runter. Falls aus irgendeinem Grund eine Neuinst. fällig werden sollte, dito.

Die letzten Einsätze der Kiste waren Programmierung in python3 und damit zusammenhängend LibreOffice und Firefox. Ansonsten kommen noch Gimp und Inkscape in Frage. Das läuft alles auch auf Linux. Vor allem kann die Hardware das locker stemmen, weshalb von daher noch kein Grund für 'ne neuere Kiste gegeben ist. Und wenn die Python mal richtig große Beute würgen muss, macht die das auf einem Ryzen 7 5800X.

Zitat von freaked

welches update und was sagt die ereignisanzeige dazu..

Kommt Montag Abend …

Die Kiste steht nicht bei mir inna Bude.

Zitat von clik!84

Setup.exe /product server

Das war die Lösung, um das Inplace-Upgrade da drauf zu bekommen. Und ja, wenn das Update nächste Woche immer noch hängt, wird das mit 24H2 vom USB-Stick der letzte Versuch werden.

Zitat von Smaecks

würd ich halt im geschäftlichen kontext nicht machen. wenn die hupe irgendein geschäftlichen sinn erfüllt, dann muss man aber auch sagen dass nach 13 jahren die maschine vielleicht mal ihr lebensende erreicht hat.

Da sitzen, so denn sich jemand das noch antut, studentische Hilfskräfte dran. Da muss also nicht der letzte Schrei an Hardware stehen, und wenn es gar nicht mehr mit Windows 11 geht, wird nur noch Linux drauf laufen. "Schmeiß weg, kauf neu!" ist nahezu immer die schlechteste Lösung. Und am Ort des Geschehens ist "der Igel im Portemonaie" auch sehr präsent, zumal an zwei Arbeitsplätzen (AMD FX 4100, Brett nur mit BIOS, …) zeitnaher Investitionsbedarf besteht …

Ein für Windows 11 laut Microsoft-Anforderungen nicht geeigneter PC¹ wurde letzten Herbst von Windows 10 64-Bit pro auf Windows 11 pro 23H2 per Inplace-Upgrade hoch gezogen. Das läuft soweit auch alles, aber seit ein paar Tagen kommt die Kiste mit einem Update nicht weiter. Liegt das an speziell dieser Kiste (Hardware, Treiber, …) oder tritt das mit Windows 11 24H2 auf PCs, die Microsoft nicht mehr will, jetzt generell auf?

Wäre schon irgendwie blöd, wenn das nicht mehr geht², denn der PC¹ sollte Windows 11 auch weiterhin von der Hardware her stemmen können.

¹Hardware:

• Intel Core i7 3770K (Ivy Bridge)
• Gigabyte GA-Z77-DS3H
  • TPM 2.0 wird nicht unterstützt
  • TPM 1.2 möglich, aber nicht installiert
• 32 GiB RAM
• AMD Radeon HD-7770
• SATA-SSD

²Der PC¹ steht nicht bei mir privat. Was ich privat in so einem Fall machen würde, dürfte hinlänglich bekannt sein …

Bist Du evtl. Opfer davon geworden:

Windows 11 24H2 Kein Zugriff auf NAS mit SMB [Workarounds] [Update]: Erklärungen von Microsoft - Deskmodder.de

Zum Thema Weichlöten mit oder ohne Blei hilft ein Blick ins Blei-Zinn-Phasendiagramm:

5.4.3 Kompliziertere Phasendiagramme: Eutektika

"klumpiges Zeug" bedeutet, dass die Lötstelle und das Lot nicht ausreichend erhitzt werden. Dann landet man im Blei-Zinn-Phasendiagramm nur in L+α oder L+β und eben nicht in L, wobei L+β häufig auftritt, wenn eine alte Lötstelle, die mit bleihaltigem Lot erstellt wurde, mit bleifreiem Lot nachbearbeitet wird. Bei ausreichender Erwärmung tritt das Problem nicht auf.

Auf Arbeit verwende ich schon seit > 10 Jahren bleifreies Lot auch zur Reparatur alter Geräte, deren Lötstellen bleihaltiges Lot enthalten. Die dort vorhandene Lötstation "Weller Magnastat" (einfach, aber sehr robust und extrem langlebig) funktioniert mit bleifreiem Lot nur, wenn die Lötspitzen "8" verwendet werden, die die höchstmögliche Temperatur annehmen, die mit dieser Lötstation erreicht werden kann. Lötspitzen "5" oder "6" funktionieren nur mit bleihaltigem Lot.

Auf Arbeit verwende ich Elektroniklot Sn99Ag0.3Cu0.7 Drahtdurchmesser 1,0 mm mit Flussmittelseele.

Wenn Dir eine saubere Trennung zwischen bleihaltig und bleifrei wichtig ist, nimm einfach zwei Lötspitzen. Dann kannst Du für bleifrei gleich eine wählen, die eine für bleifreie Lötungen ausreichend hohe Temperatur an die Lötstelle bringt.

Bei direkt geheizten Lötspitzen sollte bedacht werden, dass Lötspitzen Verschleißteile sind …

Performance boost? Oder bringt die CF gegenüber der HDD nix bei der Hardware-Basis?

Zitat von Dirk

aber das ding zu retten ist schon lustig. Gut es ist zumindest legendär.

Keine Ahnung ob das legendär ist.

Als Testsystem hat es den Vorteil, dass neben zwei DDR-RAM-slots auch zwei SDRAM-slots vorhanden sind. In den SDRAM-slots laufen auch 256 MiB single-sided Module und 512 MiB Module, die im nächst älteren Testsystem („AMD K6-2+ 600“ auf Shuttle HOT-591P) keine Chance haben.

Zitat von Dirk

Und wahrscheinlich ist heute ein stabilerer Betrieb als damals mit damaligen BIOS, Treiber und Speicher möglich.

Auf dem reparierten Brett (Testsystem) läuft eh nur entweder ein Live-Linux oder memtest86+. Auf dem verbauten Brett läuft mittlerweile 'ne Slackware 14.2 mit Kernel 4.19.303. Diese Kombi hat genauso wenig Probleme mit dem SiS-Chipsatz wie zuvor die Slackware 13.0 mit Kernel 2.6.39.4. Gegen kaputt gehende Hardware ist aber auch der stabilste Kernel machtlos …

Elitegroup K7S5A, bestückt mit AMD Athlon XP 2400+ AXDA2400DKV3C & 2 GiB RAM = 1 GiB DDR1 PC-266 + 1 GiB DDR1 PC-333:

Elkoseuche bekämpft, also zwei Sorten Elkos getauscht, da das Brett nicht mehr stabil mit FSB266 lief.

2200 µF 6,3 V (7 Stk., davon 4 Stk. aufgebläht) → 2200 µF 10 V

1000 µF 10 V (2 Stk., beide aufgebläht) → 1000 µF 16 V

Das Brett läuft wieder stabil mit FSB266 und selbst das schon seit Jahren tot geglaubte onboard 100Base-TX (SiS 900) funktioniert wieder.

Spaß sieht anders aus.

Die vielen neuen Elkos rechts unter dem Brett sind nicht alle übrig und auch nicht nur den erhältlichen VPE geschuldet. Es ist viel schlimmer. Im Bestand lauert in einer Kiste ein weiteres K7S5A.

Zweifel wurden geäußert …

Und dann ist auch die Frage, wie quer da ein BIOS schießen kann. Ist die komplett sinnentleerte Anzeige 80486DX-2 66 für den Prozessor schon das Maximum oder geht noch weniger bis gar nix?

Zitat von michi

und 66 MHz x3 bei einem C6-200 funktionieren.

Dat geit.

Das lief hier neulich mal: idt WinChip C6-200MHz auf Chaintech 5VGM M101 mit Jumper-Setup 66 MHz FSB ×3,0. Das BIOS meint zwar, es wäre ein 80486DX2-66 im Sockel, aber der Linux-Kernel erkennt den Prozessor, cat /proc/cpuinfo zeigt den Prozessor korrekt an.