Hallo Andreas!
Ich bin heute ein gutes Stück mit dem Testen weitergekommen und habe nun eine sehr starke Vermutung woher die Probleme mit Command Line und Divisor 0/1 kommen - es liegt am USB Controller bzw am USB Treiber.
Auf dem uralt Laptop mit AMD CPU (hab' ihn vor dem Test auf die aktuelle Debian Stretch upgedated) dauert das Abfragen der Command Line satte 2ms. Da Command bei Divisor 0/1 nur ca 1.5-2ms auf low ist kann es also passieren, dass der PC ein Command Frame "übersieht" (nämlich dann wenn er kurz bevor Command auf low geht checkt, und dann 2ms später wenn Command schon wieder auf High ist).
Auf 2 anderen, etwas älteren, PCs dauet das Abfragen 1ms, am RPi1 und 3 etwa 350-500us und auf meinem Laptop (Lenovo X230) ca 100-200us (abhängig davon ob ich den USB2 oder USB3 Port verwende).
Wenn ich einen USB2.0 Hub zwischen PC/Laptop und dem FTDI Adapter hänge dauert das Abfragen etwa 200us - und auch am uralt Laptop geht damit Divisor 0 problemlos.
Ich hab' dann mit "lsusb -t" nachgesehen welcher Treiber / Port denn genau verwendet wird.
Direkt am USB des uralt Laptops eingestöpselt sieht's so aus:
- Code: Alles auswählen
hias@alte-delle:~$ lsusb -t
/: Bus 06.Port 1: Dev 1, Class=root_hub, Driver=ohci-pci/2p, 12M
/: Bus 05.Port 1: Dev 1, Class=root_hub, Driver=ohci-pci/2p, 12M
|__ Port 1: Dev 4, If 0, Class=Vendor Specific Class, Driver=ftdi_sio, 12M
/: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=ohci-pci/2p, 12M
/: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ohci-pci/2p, 12M
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ohci-pci/2p, 12M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/10p, 480M
Mit USB2 Hub dazwischen so:
- Code: Alles auswählen
hias@alte-delle:~$ lsusb -t
/: Bus 06.Port 1: Dev 1, Class=root_hub, Driver=ohci-pci/2p, 12M
/: Bus 05.Port 1: Dev 1, Class=root_hub, Driver=ohci-pci/2p, 12M
/: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=ohci-pci/2p, 12M
/: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ohci-pci/2p, 12M
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ohci-pci/2p, 12M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/10p, 480M
|__ Port 7: Dev 2, If 0, Class=Hub, Driver=hub/5p, 480M
|__ Port 1: Dev 3, If 0, Class=Human Interface Device, Driver=usbhid, 480M
|__ Port 3: Dev 4, If 0, Class=Vendor Specific Class, Driver=ftdi_sio, 12M
Auf meinem ca 10 Jahre alten Quadcore Xeon (direkt an der Frontbuchse eingestöpselt) sieht's so aus:
- Code: Alles auswählen
hias@tv:~$ lsusb -t
/: Bus 10.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M
/: Bus 09.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M
|__ Port 1: Dev 3, If 0, Class=Vendor Specific Class, Driver=ftdi_sio, 12M
/: Bus 08.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M
/: Bus 07.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M
/: Bus 06.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M
/: Bus 05.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M
/: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/6p, 480M
/: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 5000M
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 480M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/6p, 480M
Im nicht-funktionierenden Fall (direkt am USB Port des uralt AMD Laptops) ist der ohci-pci Treiber zuständig.
Mit dem USB2 Hub dazwischen "wechselt" das zum ehci-pci Treiber (und läuft dann).
Am Xeon Server ist uhci_hcd zuständig (und geht dann auch).
Am Laptop ist entweder der xhci_hcd oder der ehci-pci zuständig (und beide gehen).
Kannst Du das bei Dir auch mal ausprobieren? Poste mal den output von "lsusb -t" von Deinem PC und Laptop, sowohl direkt eingestöpselt als auch mit USB2 Hub dazwischen. Ein kurzer Test mit atariserver wär auch interessant.
Für mich sieht es zZt so aus als würde nur der ohci-pci Controller/Treiber Probleme machen. Wäre interessant zu wissen ob's bei Dir auch so ist (und ich hab' nur den einen Laptop der einen OHCI Controller verwendet, alle anderen PCs hier haben U/E/XHCI).
so long,
Hias