Ok, klar, dass DKMS nicht funktionieren kann: Es wird noch gar nicht genutzt. 
Es muss tatsächlich per Hand kompiliert werden. Die Datei /usr/share/doc/opencbm-xa1541-module-source/README.Debian kennst du und hast du ausgeführt?
Du hattest ja gesagt, du bekommst es nicht kompiliert. Was sind die Fehlermeldungen?
Da müsste man tatsächlich nochmal ran.
Es muss tatsächlich per Hand kompiliert werden. Die Datei /usr/share/doc/opencbm-xa1541-module-source/README.Debian kennst du und hast du ausgeführt?
Du hattest ja gesagt, du bekommst es nicht kompiliert. Was sind die Fehlermeldungen?
Oh, ich hatte dich so verstanden, dass das automatisch passiert, wenn man das Repository verwendet...
Ich hab' auch die Packages von Debian durchgesucht. make-kpkg konnte ich da nicht finden.
PS: make-kpkg scheint erst in testing zu existieren. Ich kann das Betriebssystem upgraden, wenn das hilfreich ist. Wird allerdings etwas dauern, da ich ja zwei Upgrades machen muss und aus mir unerfindlichen Gründen die Lan-Verbindung zu dem Rechner meist nur ca 40KB/s macht trotz 100mbit-Leitung...
Mit der zweiten angegebenen Möglichkeit erhalte ich:
Das Verzeichnis /lib/modules/4.19.0-18-686/build existiert nicht.
Wenn ich /lib/modules/4.19.0-18-686/build/include anlege und es nochmal versuche, erhalte ich
Der reguläre Ausdruck erlaubt keine Großbuchstaben. Ich denke mal, das "KERNEL_VERSION" müsste durch "4.19.0-18-686" ersetzt werden, aber ich kann nicht rausfinden, wo ich das machen müsste. (#export DH_VERBOSE=1 in debian/rules auskommentieren hat auch nichts an der Ausgabe geändert.)
Oh, ich hatte dich so verstanden, dass das automatisch passiert, wenn man das Repository verwendet...
Dachte ich auch.
Man merkt, dass die Erinnerung schlecht wird.
Das wäre automatisch passiert, wenn es schon DKMS nutzen würde. Tut es aber nicht.
Ich habe heute angefangen, es umzubauen, werde damit aber nicht fertig.
PS: make-kpkg scheint erst in testing zu existieren
Das ist komisch, weil das schon in älteren Kernels vorhanden war (ca. 2008 habe ich es auch schon anderweitig benutzt).
Ich will davon aber gerade ganz wegkommen.
Das Verzeichnis /lib/modules/4.19.0-18-686/build existiert nicht.
Da fehlen die Kernel-Header.
Lösche das Verzeichnis mal wieder. Ich muss rausfinden, ob DKMS es automatisch erzeugt, oder ob ich da noch einen weiteren Schritt einbauen muss. Jedenfalls sollte man so etwas nicht selbst erzeugen, sonst hast du ganz schnell ein Debian-System, bei dem elementare Dinge nicht mehr funktionieren.
Wie gesagt, ich bin dran.
Das Verzeichnis /lib/modules/4.19.0-18-686/build existiert nicht.
Jedenfalls sollte man so etwas nicht selbst erzeugen, sonst hast du ganz schnell ein Debian-System, bei dem elementare Dinge nicht mehr funktionieren.
Das ist mir schon klar. Aber es ist ein alter Rechner, den ich auch komplett neu installieren könnte, wenn notwendig. Da wollte ich einfach mal sehen, was passiert. Evtl. könnte es dir ja weiter helfen.
Wie gesagt, ich bin dran.
OK. Ich werde geduldig warten. 
OK. Ich werde geduldig warten.
Probiere es nun nochmal.
OK. Ich werde geduldig warten.
Probiere es nun nochmal.
Ich musste ein dist-upgrade fahren, damit die neuen Versionen installiert wurden. Danach gab es eine Änderung: dkms status --verbose liefert jetzt
cbmctrl reset liefert aber weiterhin
Dein dkms status sagt mir, dass die Modul-Sourcen zwar hinzugefügt wurden, aber nicht kompiliert oder gar als Modul installiert.
Du schreibst, dass du erst Updates machen musstest. War da ein Update des Kernels bei?
Bei meinen Versuchen habe ich gemerkt, dass Debian dann das Modul nicht neu kompiliert, wenn vor der Installation nicht die Machine neu gestartet wird (und damit der neue Kernel aktiv ist).
Hintergrund ist allem Anschein nach, dass Debian dann die Kernel-Header nicht für den alten, noch laufenden Kernel installiert, so dass es nicht kompiiert werden kann. Wenn man sie per Hand nachinstalliert wird das Modul dann doch kompiliert.
Das habe ich übrigens mit anderen Kernel-Modulen verifiziert; es liegt also nicht an meinem Modul, sondern scheint ein grundsätzliches Problem zu sein.
Also Vorschlag: Neustart nach dem Update, damit der neue Kernel aktiv wird, und dann nochmal opencbm-xa1541 neu installieren.
Man kann das Kompilieren zwar auch erzwingen (als root: dkms build -m opencbm-xa1541 -v 0.4.99.103.git.1642361917.3be5c7d2 && dkms install -m opencbm-xa1541 -v 0.4.99.103.git.1642361917.3be5c7d2; die Version (nach -v) gilt nur für deine obigen Angaben, ansonsten wäre das anzupassen), aber eine neue Installation scheint mir schneller zu gehen als die Kommandos per Hand einzugeben.
Wie man die kernel-headers installiert war jetzt nicht so schwer rauszufinden.
Genau das ist es, was fehlschlägt, wenn man Debian aktualisiert hat ohne danach noch einem neu zu Booten: Die Header sind nicht da.
Bei mir hat er sie aber beim Neuinstallieren nachinstalliert, deshalb wundert es mich, wieso es bei dir nicht gemacht wurde.
Zu dem Problem mit dem exklusiven access: Ich sehe in der Ausgabe von lsmod, dass du die Module ppdev und lpr hast. Die können unter Umständen den Parallelport sperren, so dass OpenCBM keinen Zugriff mehr bekommt.
Probiere mal rmmod lpr und/oder rmmod ppdev und führe es dann neu aus.
intel_rng: Firmware space ist locked read-only. [...] Try using the 'no_fwh_detect' option.
Das hat was mit den Generator für die Pseudo-Zufallszahlen zu tun. Sollte nicht mit OpenCBM zu tun haben.
Das mit dem "Kernel tainted" ist normal, wenn man Module ("Treiber") installiert, die nicht aus dem originalen Linux-Kernel stammen (wie hier). Damit will Linux nur anzeigen, dass man jetzt quasi "die Garantie verliert". Bei eventuellen Crash-Reports wird dann gerne eine Analyse verweigert, da der Kernel ja tainted war.
cbmctrl reset scheint zu tun: Floppy hört auf zu laufen und nach kurzer Zeit beendet sich der Befehl.
Was ist, wenn du nochmal cbmctrl reset ausführt? Die Floppy muss kurz anlaufen und sich dann wieder beenden.
Beim Laden gibt der Treiber aus, was für ein Kabel er erkennt (XM1541 oder XA1541). Was sagt ihr denn hier?
Dann gibt es noch das Programm cbmlinetester. Damit kann man gezielt Leitungen auf aktiv setzen und auch wieder inaktivieren.
Er zeigt sowohl an, wie er die Leitungen setzt (obere Zeile), als auch, wie er sie wieder zurückliest (untere Zeile). Damit kann man Probleme ganz gut diagnostizieren, wenn z.B. das Kabel ein Problem hat.
cbmlinetester -i geht in den interaktiven Modus. Dann kann man mit r, a, c und d (also immer die Kleinbuchstaben) die entsprechende Leitung (RESET, ATN, CLK, DATA, in der Reihenfolge) aktivieren und mit den entsprechenden Großbuchstaben die Leitung wieder deaktivieren.
Kannst du damit etwas erkennen?
cbmctrl reset scheint zu tun: Floppy hört auf zu laufen und nach kurzer Zeit beendet sich der Befehl.
Was ist, wenn du nochmal cbmctrl reset ausführt? Die Floppy muss kurz anlaufen und sich dann wieder beenden.
Ja, das tut. Aber dann jedesmal danach ein Timeout.
Beim Laden gibt der Treiber aus, was für ein Kabel er erkennt (XM1541 oder XA1541). Was sagt ihr denn hier?
cbm_init: using passive (XM1541) cable (auto), irq 7
Dann gibt es noch das Programm cbmlinetester. Damit kann man gezielt Leitungen auf aktiv setzen und auch wieder inaktivieren.
Er zeigt sowohl an, wie er die Leitungen setzt (obere Zeile), als auch, wie er sie wieder zurückliest (untere Zeile). Damit kann man Probleme ganz gut diagnostizieren, wenn z.B. das Kabel ein Problem hat.
cbmlinetester -i geht in den interaktiven Modus. Dann kann man mit r, a, c und d (also immer die Kleinbuchstaben) die entsprechende Leitung (RESET, ATN, CLK, DATA, in der Reihenfolge) aktivieren und mit den entsprechenden Großbuchstaben die Leitung wieder deaktivieren.
Kannst du damit etwas erkennen?
Ich hab' keine Ahnung, was da sein müsste. Aber mein Gefühl sagt mir, dass das alles richtig ist. (Keine weiteren Meldungen bei dmesg.)
Ich hab' keine Ahnung, was da sein müsste. Aber mein Gefühl sagt mir, dass das alles richtig ist.
Meins sagt mir, dass wir ein Problem mit dem Kabel haben...
Was sofort ins Auge springt:
Entweder ist das Kabel defekt, oder der PC kann die Floppy nicht gut genug treiben. Das wiederum ist unwahrscheinlich, wenn die Floppy auf RESET ("r") reagiert (mit Laufen des Motors) und auf inaktivieren von RESET ("R") wieder der Motor ausgeht.
Post Address: LPT1, 378, IRQ 7 (scheint mir richtig zu sein, alternativ gäbe es noch: LPT2, 278, IRQ 5 und LPT3, 3BC, IRQ 7 und None)
Da könntest du ja mal rumspielen. Allerdings ist bei den Ergebnissen bislang nicht zu erwarten, dass das (zumindest bislang) ein Problem ist.
Wenn später etwas anderes nicht ginge könnte es der IRQ sein, aber hier müsste schon mehr gehen!
Port Definition: Extended Cpabilities (ECP) (alternativen: Standard AT (Centronics), Bidirectional (PS-2), Enhanced Parallel (EPP))
Eigentlich sollte alles (bis auf "Standard AT (Centronics)") gehen, weil es prinzipiell berücksichtigt wird. Du kannst aber gerne EPP und Bidirectional mal gegenchecken.
Zeilen 1-19: Wieso wird DATA als aktiv gelesen, obwohl es nicht gesetzt ist (und es auch keinen Grund dafür gibt)?
Du meinst vermutlich CLOCK, nicht DATA? Das muss m.E. nichts bedeuten. Das Bild, das cbmlinetester -i direkt nach dem Start unter "own" vermittelt ist immer unvollständig. Ich kenne es nur vom xum1541, da ist es aber auch so, dass der Adapter u.U. einen Zustand steuert, der im Programm nicht ersichtlich ist. Das wird bei dem Gerätetreiber vermutlich nicht anders sein. Es stimmt erst, wenn man die Leitung einmal getoggelt hat (sieht man ja auch, dass CLOCK verschwindet, nachdem es explizit gelöscht wurde).
Bei den anderen beiden Punkten stimme ich aber zu. Speziell müsste bei ATN auch DATA gesetzt werden.
Juhu, es funktioniert! 
Ich hab' das Kabel mal bei der Floppy in den anderen Steckplatz gesteckt. Da tuts. Ich vermute, dass beim ersten irgendwo ein Kontakt nicht vorhanden war. Kann ich dann in Ruhe mal irgendwann testen.
Zuvor aber: Dir erst mal vielen, vielen, lieben Dank. Das war Erste-Klasse-Support. Du hast jetzt was gut bei mir! 
Ich vermute, dass beim ersten irgendwo ein Kontakt nicht vorhanden war. Kann ich dann in Ruhe mal irgendwann testen.
Aufmachen, Platine raus, IEC-Buchsen nachlöten, alles wieder zusammenbauen und Ruhe ist.
Juhu, es funktioniert!
Glückwunsch!
Ziel erreicht.
Zuvor aber: Dir erst mal vielen, vielen, lieben Dank.
Und dabei habe ich die Debian-Pakete auch nochmal debugged.
Win-Win.
Du meinst vermutlich CLOCK, nicht DATA?
Richtig.
Das muss m.E. nichts bedeuten. Das Bild, das cbmlinetester -i direkt nach dem Start unter "own" vermittelt ist immer unvollständig. Ich kenne es nur vom xum1541, da ist es aber auch so, dass der Adapter u.U. einen Zustand steuert, der im Programm nicht ersichtlich ist. Das wird bei dem Gerätetreiber vermutlich nicht anders sein.
Na ja, der Gerätetreiber versucht zu erkennen, ob er ein XA1541 oder XM1541 hat, und resettet dann alles. Danach sollte es eigentlich passen.
Ich bin mir da ziemlich sicher; leider ist der einzige Rechner, an dem mein XA1541 noch geht (Parallelport), zur Zeit nicht lauffähig sondern muss repariert werden, daher kann ich es gerade nicht ausprobieren.
Wenn natürlich die Erkennung von XA1541/XM1541 fehlschlägt (weil keine Floppy dranhängt oder sie sich komisch verhält), dann kann das tatsächlich passieren.
Aufmachen, Platine raus, IEC-Buchsen nachlöten, alles wieder zusammenbauen und Ruhe ist.
Ich würde vorm Nachlöten erst einmal ein hochauflösendes Bild machen und versuchen zu erkennen, ob es daran liegt (oder auch eventuell die Platinen einen Hau weg hat).
Mal geht's mal geht's nicht. Selbst wenn man den Stecker gar nicht rausgezogen hat zwischendurch.
Klassischer Fall von Wackelkontakt -> Buchsen nachlöten sollte das beseitigen....
