Hi,
this is referring to the a very reproducable lockup that occurred with
glaxium on r100 hardware. Several months ago I tracked it down to
emission of state changes and introduced a workaround that waits for 3D
idle before state changes. Now I had a new idea about a possible cause
of trouble: th
Felix Kühling wrote:
Hi,
this is referring to the a very reproducable lockup that occurred with
glaxium on r100 hardware. Several months ago I tracked it down to
emission of state changes and introduced a workaround that waits for 3D
idle before state changes. Now I had a new idea about a possible
Am Samstag, 03. Januar 2004 04:52 schrieb Felix Kühling:
> Hi,
>
> this is referring to the a very reproducable lockup that occurred with
> glaxium on r100 hardware. Several months ago I tracked it down to
> emission of state changes and introduced a workaround that waits for 3D
> idle before state
On Sun, 4 Jan 2004 19:30:45 +0100
Dieter Nützel <[EMAIL PROTECTED]> wrote:
> Am Samstag, 03. Januar 2004 04:52 schrieb Felix Kühling:
> > Hi,
> >
> > this is referring to the a very reproducable lockup that occurred with
> > glaxium on r100 hardware. Several months ago I tracked it down to
> > emi
Felix Kühling wrote:
A patch is attached. The order in which state atoms are emitted now is
pretty arbitrary. It may be worth finding out exactly which permutations
of state changes trigger the lockup. In the interest of security we
could detect them in the DRM driver and emit a 3D idle to prevent
