[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MiNT] wakegem + naes 2

> > >As far as I know it is still needed. It seems this is a kernel problem,
> > >not any AES (otherwise it would be strange, if all AESes would share same
> > >bug). But. As of kernel version 1.15.9 or something, the WakeGEM causes
> > >occasional crashes because, apparently, the kernel's interval timer does
> > >not work correctly. I have no clue what was changed and where, CHANGES

> > Interesting.  Perhaps it was wakegem causing the newer betas to be
> > unstable here. It was b9 and b10 that I had problems with sudden
> > freeze ups.

I talked with Frank two days ago and he suggested what this problem can be
referred to. It is likely that the problem with wakegem causing crashes is
solved. About the problem which is solved by wakegem itself, i would
suspect either Fselect() or select()/unselect() code in the devices
installed by the AES. But I am not sure about this. I would only point
out, that there are occasional problems with Fselect() in the presence of
the AES, e.g. N.Closure uses Fselect() on console device to cause an
arbitrary delay of the program flow and after the behaviour it seems that
this Fselect() call sometimes never returns. Then again, I don't know
N.Closure's internals from other source other than extrapolation made of
the example source code written in the N.AES hypertext doc.

Being at Fselect() I also noticed, that this call seems to wake up when
waiting on a pipe, when some program at the other side of the pipe makes
Fopen()/Fclose() sequence (not writing any data to the pipe). I would say
that this behaviour is not good, since in my understanding
Fselect() should only wake when real data are written to. Same for
Fselect() waiting for reads.

Konrad M.Kokoszkiewicz
mail: draco@atari.org

** Ea natura multitudinis est,
** aut servit humiliter, aut superbe dominatur (Liv. XXIV,25)
** Taka to juz natura pospolstwa, ze albo sluzy ono unizenie,
** albo bezczelnie sie panoszy.