Kernel Thread blockiert die Tastatur oder blockiert

[nobody0]

In einem ganz kleinen Treiber habe ich einen kleinen kernel Thread, damit der Treiber Rechteck-Signale regemäßig ausgibt (Anhang).
Es funktioniert auch halbwegs, aber:

- Unter SuSE 9.2 ist anschließend die Tastatur meistens (aber nicht immer) blockiert; nicht einmal Magic System Key Request funktioniert dann :eek:
Über ssh kann ich aber rein und nachdem der Thread terminiert ist, funktioniert die Tastatur problemlos, aber ohne Thread ist der Treiber praktisch gekillt und häufig per ssh einloggen will ich nur für den Treiber nicht machen.
Wie kann man denn dieses Hängen der Tastatur unter SuSE abschalten? :confused:

- Unter Debian gibt es keine Tastatur-Blockade, aber häufig funktioinert der Thread nicht richtig, d. h. laut top läuft der Thread problemlos, aber über den Parallelport kommt kein Signal, wie ich z. B. mit der angeschlossenen LED sehe. :eek:
Wie kann man dieses Blockieren denn abstellen :confused:

[nobody0]

Übrigens sind die Probleme unabhängig vom Thread; wenn ich das Pin-Wackeln in die init-Funktion einbaue, treten die Probleme ebenso auf.
Und wie ich mit einer ISA-Karte herausgefunden habe, ist das Problem unter Debian wohl, daß der Mainboard-Treiber einen Bug hat, denn mit der Karte funktioniert es problemlos.
Unter SuSE ist wohl die Ursache, dass der Tastatutreiber einige Bugs hat, denn gelegentlich erscheien einige Tasten dauerhaft gedrück, auch wenn die Tastatur (egal ob PS/2 oder USB oder welcher Hersteller) nicht benutzt wird.

Anbei die finale selbstdokumentierende Version.
;)

Bilder von der Hardware gibt's hier:
http://random.linux-site.net/files/unsorted/par/

[almoeli]

Hi,

dein Thread frist alle Rechenzeit, die er irgendwie bekommen kann.
Das liegt daran, dass du eine Endlosschleife programmiert hast, die mit udelay verzögert wird. udelay ist eigentlich nur für KURZE Wartezeiten gedacht, da es die Rechenzeit nicht an andere Prozesse abgibt.
Dein Thread wird also nur aufhören zu arbeiten, wenn er durch einen höher priorisierten Prozess zwangsweise unterbrochen wird.
Damit auch andere Prozesse drankommen können, solltest du nicht udelay warten, sondern mit schedule_timeout. Vorher nicht vergessen den Thread auf interruptable zu stellen:


set_current_state(TASK_INTERRUPTIBLE);
shedule_timeout(delay*HZ);

So sollte dein Thread sich nicht ganz so resourcenfressend im Rechner breitmachen.

Gruß

almoeli

[nobody0]

Hi,

dein Thread frist alle Rechenzeit, die er irgendwie bekommen kann.

Das stimmt nicht; der Thread kann nur die Rechenzeit einer CPU belegen; alle anderen CPUs bleiben frei.
Die sauberste Lösung wäre eigentlich einen Timer zu nehmen und über dessen ISR die Pins zu toggeln (auf ARM9 habe ich mal sowas gemacht), denn das braucht praktisch kaum CPU-Zeit und liefert ein sauberes Timing, aber ich habe keinen Timer mehr frei, oder kennst Du einen, der im PC brachliegt?

Deshalb gibt es bei kleinen Wartezeiten, also kleiner als 1/HZ, nur noch busy waiting und das frisst 100 % der CPU-Zeit.
Das ist aber kein Problem, denn ich habe nur dualprozessor-PCs ;)
Viele Leute haben ja schon CPUs mit HT und demnächst gibt's ja auch Destop-CPUs mit dual-core.

Edit: Der Treiber ist für bis zu 500 kHz, also eine Million mal pro Sekunde mit den Pins wackeln oder Einlesen.
Eine Seite mit User-Space-Programmen, die kein busy waiting machen und für Frequenzen bis 500 Hz gedacht sind, gibt's hier:

http://www.mikrocontroller.net/forum/read-4-154677.html#new