Eumex x04PC

On Wed, 21 Sep 2005 13:42:41 +0200
"M.K." <sir-kunibert@...> wrote:

> das Problem mit dem h=E4ngenden rmmod hab ich auch schon gehabt,=20
> allerdings nur mit folgender Konfiguration:
> Eumex504 und Suse9.1. Alles andere, also Eumex 604 oder 704 und/oder=20
> Suse9.2 oder Mandrake hat dieses Problem nicht gehabt. Deshalb habe ich=20
> es auf Suse geschoben.

Diesen Bug hatte ich ja schon gefunden, das war lag an der Abmelde-
reihenfolge in emx_exit(), da ist es ganz entscheidend, das usb_deregister()
zum Schlu=DF gemacht wird, ist ja auch logisch, war aber zeitweise nicht so.

> Jetzt, da es bei dir auch aufgetreten ist und du=20
> auch noch so hartkn=E4ckig nach einem Bug suchst, hab ich wieder einen=20
> Blick in den Treiber geworfen und siehe da: In emx_disconnect() wird=20
> nach dem Aufruf von emx_delete() ein Semaphor eines NULL-Zeigers=20
> freigegeben. Ich denke, das k=F6nnte der Bug sein, den du schon seit Tage=
n=20
> suchst.

Ja, das war er nat=FCrlich. Danke. :-) Und das rmmod da hing lag sicher dar=
an,
das diese Semaphore nicht freigegeben werden konnte. Weil jetzt ist alles
prima bei mir.

Gru=DF
Fabian

> das diese Semaphore nicht freigegeben werden konnte. Weil jetzt ist al=
les
> prima bei mir.

und 

> einen Blick auf die Tasklets geworfen... Huch, wo sind denn die ganzen=
 Spinlocks,
> es sind trotz der vielen Tasklets, kaum welche zu sehen, ist ja echt W=
under, das der
> Treiber so gut funktioniert, weil ich schon diverse Variablen gefunden=
 habe, die

Nix ist prima! Du willst wissen, wo die ganzen Spinlocks geblieben sind?=
?? 

Also:
Vor langer Zeit, als der Treiber noch mit Threads arbeitete, haben Semap=
hore und Spinlocks wunderbar kritische Bereiche gesch=FCtzt. Da war die =
Welt noch in Ordnung.
Als ich dann alles (so ziemlich alles) auf Tasklets umgestellt habe, sin=
d die Semaphore auf der Strecke geblieben, weil sie in Tasklets nicht ei=
ngesetzt werden d=FCrfen. Tasklets d=FCrfen ja nicht schlafen, was bei S=
emaphoren bekanntlich der Fall ist. Also blieben noch die Spinlocks =FCb=
rig. Dann habe ich mich an die Schreibtasklets f=FCr die CMD-, B1- und B=
2-Daten an USB rangemacht. Diese haben urspr=FCnglich so ziemlich gleich=
 ausgesehen, wie die Lesetasklets heute noch aussehen: Es gab eine Schle=
ife, die nacheinander die Datens=E4tze aus der Queue geholt hat und dann=
 ans USB gesendet hat. Da aber die Schreibfunktion des USB-Subsystem sof=
ort zur=FCckkehrt, auch wenn der URB noch gar nicht =FCbertragen wurde, =
gab es Probleme, weil die Schleife sofort den n=E4chsten Datensatz sende=
n wollte und das USB-Subsystem streikte. Also war der n=E4chste Gedanke,=
 in der Schleife einen Spinlock einzubauen, der die Schreibfunktion des =
USB-Subsystems besch=FCtzt: Vor dem Aufruf wird der Spinlock besetzt. Ke=
hrt die Funktion zur=FCck, bleibt die Schleife beim n=E4chsten Durchlauf=
 an dem Spinlock h=E4ngen, bis dieser vom Completion Handler wieder frei=
gegeben wird. Klingt doch logisch, oder? Als ich das ausprobieren wollte=
, hab ich angefangen an meiner geistigen Integrit=E4t zu zweifeln. Wie a=
uch immer ich das angestellt habe, der Spinlock hat nichts bewirkt. Nach=
 sehr vielen Tests hab ich dann gefunden, dass Spinlocks in Tasklets kei=
ne Wirkung haben!

Probier's aus:

Irgendwo in einem Tasklet, z.B. im CMD-Tasklet in unserem Treiber:
spinlock deklarieren
spinlock initialisieren
...
int i;
...

for (i =3D 0; i < 10; i++)
{
spinlock besetzen (wei=DF jetzt die Anweisungen nicht auswendig)
printk("Test %d\n", i);
}
...

Obwohl der Spinlock 10 mal besetzt wird, l=E4uft das Tasklet durch, als =
ob es ihn gar nicht geben w=FCrde. Warum ist das so? Keine Ahnung!

Michael

On Wed, 21 Sep 2005 20:11:42 +0200
"M.K." <kunibert@...> wrote:

> Also blieben noch die Spinlocks =FCbrig. Dann habe ich mich an die Schrei=
btasklets f=FCr die CMD-, B1- und B2-Daten an USB rangemacht. Diese haben u=
rspr=FCnglich so ziemlich gleich ausgesehen, wie die Lesetasklets heute noc=
h aussehen: Es gab eine Schleife, die nacheinander die Datens=E4tze aus der=
 Queue geholt hat und dann ans USB gesendet hat.

Ich hoffe mal der sf-Mailman hat deine Mail nicht oben abgebissen.
Hab mich schon gewundert, warum du beim schreiben ausgerechnet Einzelbetrie=
b machst,
weil das geht massiv auf den Datendurchsatz.

> Da aber die Schreibfunktion des USB-Subsystem sofort zur=FCckkehrt, auch =
wenn der URB noch gar nicht =FCbertragen wurde, gab es Probleme, weil die S=
chleife sofort den n=E4chsten Datensatz senden wollte und das USB-Subsystem=
 streikte.

Naja, da mu=DF dann eben der n=E4chste URB her. ;-) Gerade mal einem Blick =
auf die URB-API
geworfen. So lange Daten zum senden da sind, holt man einfach neue URBs mit=
 usb_alloc_urb und=20
GPF_ATOMIC und schickt die ab. Der Completion-Handler ist immer der Gleiche=
 und gibt die URBs
einfach immer nur frei (+ evtl. Fehlermeldung). Das Problem ist nur den =DC=
berblick dar=FCber zu
behalten, was gerade an URBs "unterwegs" ist, weil man mu=DF die ja zur=FCc=
kholen k=F6nnen, wenn der
Treiber entladen wird. Soll hei=DFen, man braucht noch ne Liste (siehe linu=
x/list.h) wo man die=20
Adressen der gerade verschickten URBs reinpackt, damit man die unlinken kan=
n.

> Also war der n=E4chste Gedanke, in der Schleife einen Spinlock einzubauen=
, der die Schreibfunktion des USB-Subsystems besch=FCtzt: Vor dem Aufruf wi=
rd der Spinlock besetzt. Kehrt die Funktion zur=FCck, bleibt die Schleife b=
eim n=E4chsten Durchlauf an dem Spinlock h=E4ngen, bis dieser vom Completio=
n Handler wieder freigegeben wird. Klingt doch logisch, oder?

Klar.

> Als ich das ausprobieren wollte, hab ich angefangen an meiner geistigen I=
ntegrit=E4t zu=20
zweifeln. Wie auch immer ich das angestellt habe, der Spinlock hat nichts b=
ewirkt.=20
Nach sehr vielen Tests hab ich dann gefunden, dass Spinlocks in Tasklets ke=
ine Wirkung haben!

Ist ja echt b=F6se! Das macht aber auch irgendwie Sinn, wenn ich so dr=FCbe=
r nachdenke...

> Obwohl der Spinlock 10 mal besetzt wird, l=E4uft das Tasklet durch, als o=
b es ihn
> nicht geben w=FCrde. Warum ist das so? Keine Ahnung!

M=F6gliche Erkl=E4rung: Das haben die Kernelentwickler einfach deaktiviert,=
 weil, wozu noch
ein Spinlock im Tasklet, wenn beim Aufruf des Tasklets schon einer aktiv is=
t, damit
das Tasklet nur einmal l=E4uft wohl auch auf SMP-Systemen. Ein Problem sind=
 die ganzen=20
Tasklet bla-aktiv-Variablen, die auch au=DFerhalb des Tasklets abgefragt we=
rden. Das
Problem ist, das die nicht atomar sind und es da b=F6se race condition-Fehl=
er geben kann.
z.B. Du checkst gerade au=DFerhalb des Tasklets die Variable mit if und der=
 Wert ist 0
also l=E4uft nicht, nur hat die das gerade aktive Tasklets noch nicht auf 1=
 gesetzt, weil
er eben erst gestartet wurde. Das du au=DFerhalb denkst, das das Tasklet ni=
cht l=E4uft,
gibts du zum Beispiel dem laufenden Tasklet den beschriebenen Speicher unte=
rm Arsch frei
und das Tasklet ist schreibt wild in der Landschaft rum. :-(
Ist eigentlich kien Problem das zu fixen (atomic_t benutzen), die Frage ist=
 nur, ob ich
nicht wieder die H=E4lfte der Variablen =FCbersehe...

Gru=DF
Fabian