Probleme nach Installation von AOS4.1FE Update 1

[Cyborg]

Ohne Kristallkugel oder zumindest irgendeinen Hinweis kann ich leider auch nicht weiterhelfen.

@ evillord
Du hast doch Update 1 ausgiebig auf Deinem XE getestet. Ist Dir irgendwas aufgefallen? Vielleicht könntest Du Dich privat mit Helmut austauschen, um einen Hinweis auf das Problem zu finden?

[Freund_Blase]

Hallo,

"Save list to file" bringt in diesem Anwendungsfall nicht viel, da es reichlich schwierig sein dürfte,
abzuspeichern sobald der Rechner eingefroren ist. Doch es gibt eine Möglichkeit, wenn auch ein
bißchen von hinten durchs Auge.
Snoopy kann die Daten an ein serielles Terminal schicken (Menü "Output", Punkt "Serial Terminal Output").
Diese Einstellung lässt sich auch speichern (Menü "General", Punkt "Remember Settings").
Mit Sashimi (gibt es im Depot) kann man die serielle Ausgabe in eine Datei umleiten (run sashimi >RAM:debug).
Ich empfehle Sashimi die Daten in einer separaten Partition (SFS) ablegen zu lassen,
um eventuellem Datenverlust vorzubeugen.
Nun noch ein kleines Shell-Script bauen, welches man händisch oder via WBStartup startet.
Apropos WBStartup, vielleicht liegt hier ja das Problem und ich habe mit der zeitweisen Deaktivierung von
ScreenBlankerEngine nur zufällig ins Schwarze getroffen. Sowas ähnliches hatte ich auch mal
unter AmigaOS 3.x, da vertrugen sich zwei Programme nicht und ich musste sie "auseinandersetzen".
Einfach mal alles in den WBStartup-Einstellungen deaktivieren und wenn es dann immer noch Probleme gibt,
können wir zumindest WBStartup ausschließen.

@whose
Was für ein Sam hast Du denn?
Ich habe hier, neben meinem Sam440ep-flex (Hauptrechner), auch noch einen Sam460ex
(vorläufig zum rumspielen) bei dem es keine Probleme (abgesehen von den zwei großen
(Speicher/RamDisk-Handling und EHCI), die aber beide Sams betreffen und auch schon länger existieren),
mit dem Update 1, gab. Mein kleiner Sam ist da etwas zickiger.

Neben dem (zum Glück nur) anfänglichen Stabilitätsproblem gibt es auch ein (Eis-)Kaltstartproblem,
beim booten vom USB-Stick. Zur Erklärung, ich starte FE, zur Zeit, von einem USB-Stick,
auf meiner Platte befindet sich noch AmigaOS 4.1 Update 6. Grund ist eine "notwendige" Repartitionierung
in Kombination mit extremer persönlicher Faulheit , wobei mir die eklatante Ausdünnung naher und
auch fernerer genetischer Varianten vor 2 (nunmehr 3) Jahren und der darauffolgende Zores,
trefflich als Ausrede dient.
Jedenfalls kommt es gelegentlich vor, daß mein Sam440ep-flex beim booten vom Stick (Kick von ersten,
System von zweiten Partition via bootdevice) beim Bootlogo hängen bleibt. Dieses Problem tritt nur
mit AmigaOS 4.1 FE Update 1 auf dem Sam440ep-flex nach dem Einschalten, nicht jedoch nach
Warm- oder Kaltstart, aus dem System heraus, oder auf dem Sam460ex (gleicher Stick,
andere Partition), auf.

Und wenn ich schonmal dabei bin... telnet, per Doppelklick mit dem Router verbunden,
"grimt" unter FE (mit und ohne Update). Rufe ich telnet aus der Shell auf,
funktioniert es einwandfrei.



MfG
FB

[whose]

Hallo,

"Save list to file" bringt in diesem Anwendungsfall nicht viel, da es reichlich schwierig sein dürfte,
abzuspeichern sobald der Rechner eingefroren ist. Doch es gibt eine Möglichkeit, wenn auch ein
bißchen von hinten durchs Auge.

Korrigiere mich, wenn ich da falsch liege, aber für mich sieht es so aus, als würde Snoopy die Ausgabe direkt und ohne Puffer-Umweg in eine Datei schreiben. Vorausgesetzt, man schreibt auf ein Nicht-FFS-Filesystem, sollten die Daten auch nach einem Absturz noch zugänglich sein.

Serielles Terminal wäre natürlich besser, aber nicht jeder hat ein solches vorrätig

@whose
Was für ein Sam hast Du denn?
Ich habe hier, neben meinem Sam440ep-flex (Hauptrechner), auch noch einen Sam460ex
(vorläufig zum rumspielen) bei dem es keine Probleme (abgesehen von den zwei großen
(Speicher/RamDisk-Handling und EHCI), die aber beide Sams betreffen und auch schon länger existieren),
mit dem Update 1, gab. Mein kleiner Sam ist da etwas zickiger.

Ich habe auch keine Probleme mit dem SAM440ep, bis auf die Dauerbaustellen EHCI/hub.usbfd/HID tut es ziemlich klaglos seinen Dienst. Es hat sogar den Anschein, als wäre die Instabilität bei VRAM-Mangel nun behoben, die sporadischen Einfrierer von z.B. Codebench kamen bisher nicht wieder vor.

Zur Erläuterung: ich betreibe Codebench im eigenen Screen, dementsprechend ist VRAM irgendwann Mangelware auf dem kleinen SAM440ep. Ab und an kam es vor, daß z.B. beim Scrollen via Scrollbar das System einfror. Meist war das der Fall, wenn mein Progrämmchen sich auch noch einen Schluck aus der VRAM-Pulle genehmigte. Hin und wieder passierte das auch beim Scrollen per Cursor, oder wenn eine Hilfe-Blase geöffnet wurde. Mit Update 1 für FE trat das bisher noch nicht wieder auf.

Das "Kleine" lief aber auch vor dem Update schon ziemlich gut und überwiegend stabil. Demnächst kommt dann ein 460ex lite, da ist das Thema "VRAM-Mangel" dann einstweilen durch

Jedenfalls kommt es gelegentlich vor, daß mein Sam440ep-flex beim booten vom Stick (Kick von ersten,
System von zweiten Partition via bootdevice) beim Bootlogo hängen bleibt. Dieses Problem tritt nur
mit AmigaOS 4.1 FE Update 1 auf dem Sam440ep-flex nach dem Einschalten, nicht jedoch nach
Warm- oder Kaltstart, aus dem System heraus, oder auf dem Sam460ex (gleicher Stick,
andere Partition), auf.

Das kommt mir bekannt vor... man kann da nur Vermutungen anstellen, aber da sich EHCI unter AmigaOS4 generell noch etwas ziert, könnte es damit zu tun haben. Diese Hänger habe ich nämlich auch. Allerdings boote ich dann nicht von dem Stick, sondern habe schlicht vergessen, den Stick wieder aus dem 2.0-Hub am EHCI rauszuzupfen. Die meiste Zeit bootet das System dann zwar klaglos, aber ab und an "klemmt´s".

Und wenn ich schonmal dabei bin... telnet, per Doppelklick mit dem Router verbunden,
"grimt" unter FE (mit und ohne Update). Rufe ich telnet aus der Shell auf,
funktioniert es einwandfrei.

Das wiederum klingt eher nach einem Bug in TelNet. Amok laufender Zeiger... sprich, der TelNet-Client überprüft wahrscheinlich nicht, ob von der Workbench gestartet wurde und wandert dann gemütlich durch ein Argument-Zeiger-Array, das gar nicht existiert, weil dessen (vermeintlicher) Speicherplatz (Page 0) geschützt ist...

Wenn Du im "TelNet"-Piktogramm "Start durch..." auf "Shell" änderst, müßte das eigentlich behoben sein.

[Freund_Blase]

Hiho,

Korrigiere mich, wenn ich da falsch liege, aber für mich sieht es so aus, als würde Snoopy die Ausgabe direkt und ohne Puffer-Umweg in eine Datei schreiben. Vorausgesetzt, man schreibt auf ein Nicht-FFS-Filesystem, sollten die Daten auch nach einem Absturz noch zugänglich sein.

Ok, mach ich . Nee im Ernst, es mag ja sein, daß Snoopy direkt ohne Puffer-Umweg in eine Datei schreibt,
aber eben nur die, bis zum speichern, aktuellen Daten. "Save list to file" ist eine "behalte was ich hab" und
keine Logging-Funktion, was nunmal nix bringt, wenn es schon geknallt hat.

Serielles Terminal wäre natürlich besser, aber nicht jeder hat ein solches vorrätig

Genau und hier kommt Sashimi ins Spiel, damit kann man das Ganze ohne weiteres Gedöns
direkt auf dem, zu testenden, Rechner in eine Datei umleiten.


zu VRAM:
Damit hatte ich hier (zumindest auf dem kleinen, mit großem nicht getestet) noch keine Probleme,
benutze allerdings auch die "winzige" Auflösung von 1024*768.
Ist der Grafikspeicher aufgebraucht wird einfach normales RAM verwendet und alles läuft etwas
zäher (habe ich mal aus Neugier ausprobiert). Das System ist dadurch nicht instabiler geworden.
Anders sieht es leider mit der Ram Disk:, mit SWAP (obwohl es bei SWAP mit Update 1
leichte Verbesserung gab) und dem Speicher "oberhalb" von 1024MiB (Sam460ex) aus.


zu USB/EHCI:
Na, da hab ich bisher wohl Glück gehabt, denn ich verwende "OS vom Stick" seit AmigaOS4.1 Update 5
(Notfallstick (USB-Stick liegt neben Computer, CD im Schrank)) und hatte vor FE Update 1 noch keinen
Bootpic-Hänger nach (Eis-)Kaltstart (und nur da). Früher passierte es "schlechtestenfalls" und sehr selten,
daß nach Warmstart von Platte statt vom Stick gebootet wurde (ob in diesen Fällen bootdevice nicht
gefunden oder ignoriert wurde, weiß ich nicht).

Überhaupt konnte ich (bisher) einen Waffenstillstand zwischen EHCI, meinem Sam440ep-flex und
mir schließen. Maus und Tastatur kamen an einen USB 1.1 Hub (OHCI), welcher wiederum an dem hinteren,
UBoot relevanten, USB 2.0 (EHCI) Port angeschlossen wurde (beide laufen so über OHCI).
Dann hab ich noch ein USB 2.0 Hub (mit Netzteil) am zweiten hinteren Port, sowie den internen
USB 1.1 Anschluß nach draussen geführt. Mit den zwei vorderen "unbehubten" USB-Ports bin ich somit gut
gerüstet und alles funktioniert weitestgehend (wenn auch nicht immer, manchmal hat EHCI einfach
einen schlechten Tag).

Leider hab ich mit dem Sam460ex nicht so viel Fortune. Hier scheint mir EHCI noch zickiger
(klar ist ja auch schneller, kann also viel effektiver "Abstürzen" ) zu sein.
Es würde schon helfen, wenn man nicht nur das CONTROL-Feld (sehr nützlich) sondern auch
MAXTRANSFER steuern könnte (ENV-Variable für Mounter).


zu TelNet:
Ich habe das Problem "gelöst" (workaround). TelNet und die neue Console vertragen sich nicht recht,
was nicht unbedingt heißt, daß das console.device der Schuldige ist.
Aber von Anfang an: es machte keinen Unterschied ob ich "Start über" "Workbench" oder "Shell"
eingestellt habe. Es öffnete sich ein Fenster (voreingestellte Console bzw. "Workbench-Ausgabefenster")
in dem gemeldet wurde, daß TelNet sich mit dem Host (Router) verbunden hat und schon gab es
Besuch vom Reaper. Bei "Starten über... Shell" werden übrigen die Tooltypes nicht ausgewertet.
Wenn ich jetzt "telehack.com" (statt des Routers) als Host eintrage (Tooltypes), "grimt" das Programm
seltsamerweise nicht. Interessanterweise auch nicht, wenn TelNet es nicht schafft mit dem Router
Kontakt aufzunehmen. Also schien es eigentlich nur im Umfeld der Passworteingabe zu knallen.
Ich habe dann ein wenig mit den Einstellungen (s:telnet-config) herumgespielt und konnte das Problem einkreisen. TelNet bieten die Möglichkeit der Console, zur Laufzeit, den Namen des Servers zu geben.
Bei "selber geöffnetem" Consolen-Fenster "grimt" es (bei der Passworteingabe (was auch immer
TelNet da macht)) bei "fremd geöffnetem" (z.B. bei Aufruf direkt aus der Shell) nicht.
Seit der Deaktivierung dieses Features läuft TelNet problemlos.



MfG
FB

[whose]

Korrigiere mich, wenn ich da falsch liege, aber für mich sieht es so aus, als würde Snoopy die Ausgabe direkt und ohne Puffer-Umweg in eine Datei schreiben. Vorausgesetzt, man schreibt auf ein Nicht-FFS-Filesystem, sollten die Daten auch nach einem Absturz noch zugänglich sein.

Ok, mach ich . Nee im Ernst, es mag ja sein, daß Snoopy direkt ohne Puffer-Umweg in eine Datei schreibt,
aber eben nur die, bis zum speichern, aktuellen Daten. "Save list to file" ist eine "behalte was ich hab" und
keine Logging-Funktion, was nunmal nix bringt, wenn es schon geknallt hat.

Serielles Terminal wäre natürlich besser, aber nicht jeder hat ein solches vorrätig

Genau und hier kommt Sashimi ins Spiel, damit kann man das Ganze ohne weiteres Gedöns
direkt auf dem, zu testenden, Rechner in eine Datei umleiten.

Ach so... und das funktioniert dann besser, als das direkte Schreiben in eine Datei von Snoopy aus, weil es technisch das Gleiche ist. Und ist auch weniger Aufwand, als in Snoopy einen Menüpunkt anzuwählen und einen Dateinamen einzutackern. Verstehe...

Eine Ausgabe-Umleitung in eine Datei via Sashimi bringt im Fall eines harten Absturzes nicht mehr, als direktes Schreiben in eine Datei von Snoopy aus. Wenn die Ausgabefunktion von Snoopy nichts mehr schreiben kann, wie soll es dann die von Sashimi können? Wir reden ja davon, daß Ausgabe in eine Datei geschrieben werden soll. Gleiche Basis und so. Und ohne weitere Unterstützung kommen keine Meldungen von z.B. Open()-Problemen über Sashimi. Da hilft dem Normalo eigentlich nur Snoopy. Und für diesen Fall ist Snoopy ja auch gemacht. Sashimi ist eine "Bedarfsumleitung" für die Leute, die kein serielles Terminal einsetzen wollen. Es hat aber auch gewisse Nachteile, u.A. bei "harten" Abstürzen.

Ein Lösungsansatz mit Sashimi-Hilfe wäre höchstens der resetfeste Debug-Puffer von Sashimi, den man EVENTUELL nach einem Neustart mit der Option "RECOVER" in eine Datei schreiben kann. Bei den klassischen Einfrierern habe ich mit der Möglichkeit bisher aber noch nie Erfolg gehabt.

Weshalb ich zum Debuggen meist mit seriellem Terminal arbeite. Hat aber halt nicht jeder

Und Helmut ist dadurch auch nicht unbedingt geholfen, weil er dann ZWEI Hilfsprogramme vor dem Start des "Problemkindes" einstellen muß.

zu VRAM:
Damit hatte ich hier (zumindest auf dem kleinen, mit großem nicht getestet) noch keine Probleme,
benutze allerdings auch die "winzige" Auflösung von 1024*768.
Ist der Grafikspeicher aufgebraucht wird einfach normales RAM verwendet und alles läuft etwas
zäher (habe ich mal aus Neugier ausprobiert).

Ganz so simpel ist es nicht... Manchmal, wenn VRAM voll ist, wird derzeit unbenötigtes VRAM ins RAM "ausgelagert" und bei Bedarf wieder "zurücktransferiert". P96 hatte da einen Mechanismus für, ich glaube nicht, daß das komplett entfernt wurde.

Das System ist dadurch nicht instabiler geworden.
Anders sieht es leider mit der Ram Disk:, mit SWAP (obwohl es bei SWAP mit Update 1
leichte Verbesserung gab) und dem Speicher "oberhalb" von 1024MiB (Sam460ex) aus.

Scheint auch eine Frage der jeweiligen Anwendung und des Speicherbedarfs zu sein...

zu TelNet:
Ich habe das Problem "gelöst" (workaround). TelNet und die neue Console vertragen sich nicht recht,
was nicht unbedingt heißt, daß das console.device der Schuldige ist.

Müßte man halt im telnet-Quellcode nachsehen... ist es das Ding von Peter Bengtsson aus dem Depot?

[Freund_Blase]

Hallo,

@whose

Verstehe...

Scheinbar nicht .
Sei bitte so freundlich und mache mal folgendes: starte Snoopy; wähle "Save list to file";
merke Dir die Dateigröße der Ausgabedatei; spiel ein bißchen im System herum (damit
Snoopy was auszuspucken hat); vergleiche Dateigröße...

Bevor es zwischen uns blutig wird... zum besseren Verständnis:
Wenn ich Helmut richtig falsch verstanden habe, möchte er Snoopy mitlaufen lassen und
dann nach einem spontanen Absturz (und Neustart) in der Datei nachschauen, wer da so
zuletzt zugange war, um so eventuell den Übeltäter zu finden.
Können wir uns darauf einigen?

Scheint auch eine Frage der jeweiligen Anwendung und des Speicherbedarfs zu sein...

In der Tat... allerdings wirkt es so als passieren da auch "böse Dinge", die die Hardware tangieren.
Lass ich, zum Beispiel, memtester auf meinem Sam460ex freie Hand, so wird von 17xy heruntergezählt
und bei 13xy schaltet sich USB ab (tatsächlich nicht nur ein einfacher Softwareabsturz - bei Hub,
Tastatur und Maus gehen die Lichter aus) und das System friert komplett ein.
Mit "memtester 10xy" (bei meinem "alten" FE-System war es "memtester 1024") kann ich
meinen Sam460ex sogar ausschalten.

... ist es das Ding von Peter Bengtsson aus dem Depot?

Ja.


MfG
FB

[whose]

Verstehe...

Scheinbar nicht .

Ah, mein Fehler... ich hatte kein echtes Log laufen lassen. Aber schon toll, daß zumindest das "Banner" direkt geschrieben wird...

In der Tat, im Normalfall bringt "Save to file" nichts. Also Sashimi...

Scheint auch eine Frage der jeweiligen Anwendung und des Speicherbedarfs zu sein...

In der Tat... allerdings wirkt es so als passieren da auch "böse Dinge", die die Hardware tangieren.
Lass ich, zum Beispiel, memtester auf meinem Sam460ex freie Hand, so wird von 17xy heruntergezählt
und bei 13xy schaltet sich USB ab (tatsächlich nicht nur ein einfacher Softwareabsturz - bei Hub,
Tastatur und Maus gehen die Lichter aus) und das System friert komplett ein.
Mit "memtester 10xy" (bei meinem "alten" FE-System war es "memtester 1024") kann ich
meinen Sam460ex sogar ausschalten.

Hm... ich hab mich mit dem memtester-Humbug nie näher beschäftigt. Wenn ich da mal theoretisieren darf: das Ding schreibt "hart" Werte in den Speicher, ohne zu berücksichtigen, wo sich PCI-I/O-Bereiche, Devices und Libraries befinden?

Da soll es dann wohl sein, daß der USB ausgeht (oder die SAM selbst).

Wenn es so ist, wie ich mutmaße, dann kannst Du von Glück reden, daß es Dir nicht die Boot-Festplatte (bzw. deren Partitionierung/Format) zerlegt hat

Ich war dem memtester-Spuk gegenüber schon von Anfang an sehr skeptisch. Ich hatte mal (ist schon länger her) eine Diskussion mit einem Amijeweled-Nutzer, der Probleme mit seinem MicroA1 hatte und Amijeweled dafür verantwortlich machte. Nun war es so, daß ich einen vom Benutzer gemutmaßten Speicher-Bug ausschließen konnte (den hatte ich nämlich schon gefunden) und ich fragte dann mal ganz dumm, wie viel RAM der MicroA1 denn so hat. "512 MB. Mit memtester getestet, läuft einwandfrei!". Nach längerem Hin und Her hat er sich dann überreden lassen, zum Test wieder das damals mitgelieferte 256MB-Modul einzubauen. Siehe da, Probleme weg.

Seitdem lasse ich die Finger von dem Teil

... ist es das Ding von Peter Bengtsson aus dem Depot?

Ja.

Ich kann mir das mal näher anschauen, Zeit und Muße vorausgesetzt. Der Fehler sollte eigentlich "nur" eine Kleinigkeit sein.

[HelmutH]

Hab mir Sashimi mal runtergeladen und es so gestartet, wie es in der .doc unter
Example startup usage
=====================
Sashimi ASKSAVE (in its own shell window)
Run >NIL: Sashimi >"CON:0/20/640/120/Sashimi/AUTO/CLOSE/WAIT/INACTIVE" ON NOPROMPT
Run Sashimi >Test:debug (Run Sashimi >RAM:debug steht drin)

steht, dabei wird die debug Datei angelegt, aber die Datei bleibt ohne Daten.
Was hab ich dabei falsch gemacht

Bei meinem ersten Versuch ist der Rechner eingefrohren.

[whose]

Run Sashimi >Test:debug

Sollte schon passen...

Ich bin zur Zeit nicht zu Hause, sonst könnte ich direkt selbst nachsehen... soweit ich in Erinnerung habe, ist in dem Snoopy-Menu, in dem man die Ausgabe in eine Datei wählen kann, auch was von wegen "Serial Output". Ich weiß allerdings nicht, ob das "Snoopy-Ausgabe auf seriell" bedeutet oder "Umleitung serielles Debug auf Snoopy".

[HelmutH]

Irgendwie ist das zu hoch für mich.
Habs grad einmal hin bekommen, das Sashimi was in eine Datei weg geschrieben hat, doch jetzt will es wieder nicht.
Ich kann über Sysmon sehen das Sashimi als Background CLI Prozess läuft, aber aus einem mir nicht erklärbaren
Grund schreibt Sashimi nicht mehr in diese Datei. Die Datei ist komischerweise vom Typ project und nicht vom
Typ ascii, was er beim Versuch wo es geklappt hat, daraus gemacht hat. Hat da jemand eine Idee woran das liegen kann

Nachtrag:
Und so gehts:
1. Snoopy starten
2. Snoopy >output >Serial Terminal Output anharken
3. Sashimi doppelklicken
4. Sashimi Befehl ausführen : Sashimi >Daten:AmigaProg/Sashimi/Sashimi2_1/SysProb/20170123Prob
5. und enter drücken oder ausführen klicken
Puh, war das eine Geburt.