Another drm/dri lockup - when moving the mouse

Another drm/dri lockup - when moving the mouse

[Helge Hafting]

I have reported this before, but now I have some more data.

I have an office pc with this video card:
VGA compatible controller: ATI Technologies Inc Radeon RV100 QY [Radeon 
7000/VE]

In previous reports I found that starting xfree or xorg with dri support
cause a hang after a little while.  It seems that this only happens when
the mouse moves.  Something I didn't discover before because there
are lots of unplanned mouse movements - the thing is sensitive and jumps
a pixel now and then when I move stuff on the desk.

Taking care not to move the mouse, I can start X and run glxgears
with acceleration.  The slightest mouse movement during 3D activity
kills the machine instantly so it only responds to the reset button.  Mouse
movement without 3D activity may or may not kill the pc.

Could there be a problem where 3D-stuff and code to move the mouse
"steps on each other toes" somehow?  Or some way to test this further,
by disabling the mouse or force some kind of software fallback for
the mouse cursor?

Helge Hafting

Helge Hafting

Re: Another drm/dri lockup - when moving the mouse

[Roland Scheidegger]

Helge Hafting wrote:
> I have reported this before, but now I have some more data.
> 
> I have an office pc with this video card:
> VGA compatible controller: ATI Technologies Inc Radeon RV100 QY [Radeon 
> 7000/VE]
> 
> In previous reports I found that starting xfree or xorg with dri support
> cause a hang after a little while.  It seems that this only happens when
> the mouse moves.  Something I didn't discover before because there
> are lots of unplanned mouse movements - the thing is sensitive and jumps
> a pixel now and then when I move stuff on the desk.
What xorg / xfree / drm versions are you talking about?

> Taking care not to move the mouse, I can start X and run glxgears
> with acceleration.  The slightest mouse movement during 3D activity
> kills the machine instantly so it only responds to the reset button.  Mouse
> movement without 3D activity may or may not kill the pc.
> 
> Could there be a problem where 3D-stuff and code to move the mouse
> "steps on each other toes" somehow?  Or some way to test this further,
> by disabling the mouse or force some kind of software fallback for
> the mouse cursor?
You could use Option "SWcursor" "true".
Since it crashes even without 3d sometimes, the problem does not seem to 
be related to dri (as in, dri driver). Sounds more like it's related to 
CP activity. Not sure what would cause this, there seem to be a lot of 
mouse cursor movement crashes reported lately... Do you have a USB mouse 
whose controller shares the IRQ with the graphic card maybe?

Roland

Re: Another drm/dri lockup - when moving the mouse

[Helge Hafting]

Roland Scheidegger wrote:

> Helge Hafting wrote:
>
>> I have reported this before, but now I have some more data.
>>
>> I have an office pc with this video card:
>> VGA compatible controller: ATI Technologies Inc Radeon RV100 QY 
>> [Radeon 7000/VE]
>>
>> In previous reports I found that starting xfree or xorg with dri support
>> cause a hang after a little while.  It seems that this only happens when
>> the mouse moves.  Something I didn't discover before because there
>> are lots of unplanned mouse movements - the thing is sensitive and jumps
>> a pixel now and then when I move stuff on the desk.
>
> What xorg / xfree / drm versions are you talking about?

Any version.  It has been like this for years with all versions of xfree 
from debian testing,
so I have simply given up using 3D on this particular machine.  I also tried
downloading and compiling x.org 6.8.1 to have a look at transparency
and shadows.  Transparency worked - dri crashed as usual.  At the moment,
I use the debian package xserver-xfree86-dri-trunk which contains the
x.org server (not the xfree one).  My current kernel is 2.6.11-mm3.

>
>> Taking care not to move the mouse, I can start X and run glxgears
>> with acceleration.  The slightest mouse movement during 3D activity
>> kills the machine instantly so it only responds to the reset button.  
>> Mouse
>> movement without 3D activity may or may not kill the pc.
>>
>> Could there be a problem where 3D-stuff and code to move the mouse
>> "steps on each other toes" somehow?  Or some way to test this further,
>> by disabling the mouse or force some kind of software fallback for
>> the mouse cursor?
>
> You could use Option "SWcursor" "true".

Thanks, I'll try that.

> Since it crashes even without 3d sometimes, the problem does not seem 
> to be related to dri (as in, dri driver).

Stable as rock, _if_  Load "dri" is commented out from xorg.conf (or 
from XF86Config-4)

> Sounds more like it's related to CP activity. Not sure what would 
> cause this, there seem to be a lot of mouse cursor movement crashes 
> reported lately... Do you have a USB mouse whose controller shares the 
> IRQ with the graphic card maybe?

No usb.  The mouse is connected to the ps/2 mouse port.  As I mentioned, 
this is
not a recent problem.  I could never load dri on this machine without
such a crash.  I can check whether the IRQ gets shared though.

Helge Hafting

Re: Another drm/dri lockup - when moving the mouse

[Roland Scheidegger]

Helge Hafting wrote:
>> Since it crashes even without 3d sometimes, the problem does not
>> seem to be related to dri (as in, dri driver).
> 
> 
> Stable as rock, _if_  Load "dri" is commented out from xorg.conf (or
>  from XF86Config-4)
Well, commenting that out makes the 2d ddx driver not to use the CP, drm
etc.

Almost sounds like a hardware issue to me, very few people have problems 
when only using 2d (dri loaded or not) with the radeon driver (as far as 
I can tell). You could try using pci gart instead of agp, if there's a 
problem with your agp bridge (not sure if that would help though in that 
case), Option "BusType" "PCI" (old xorg versions might not understand 
that option however, they might have a boolean "ForcePCIMode" option 
instead).

Roland

Re: Another drm/dri lockup - when moving the mouse

[Jon Smirl]

On Wed, 16 Mar 2005 14:52:39 +0100, Helge Hafting
<helge.hafting@aitel.hist.no> wrote:
> No usb.  The mouse is connected to the ps/2 mouse port.  As I mentioned,
> this is
> not a recent problem.  I could never load dri on this machine without
> such a crash.  I can check whether the IRQ gets shared though.

Can you replace the PS/2 mouse with a USB one? This sounds to me like
a hardware problem or the driver for your PS/2 mouse is interfering
with DRM.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: Another drm/dri lockup - when moving the mouse

[Helge Hafting]

Roland Scheidegger wrote:

> Helge Hafting wrote:
>
>> I have reported this before, but now I have some more data.
>>
>> I have an office pc with this video card:
>> VGA compatible controller: ATI Technologies Inc Radeon RV100 QY 
>> [Radeon 7000/VE]
>>
>> In previous reports I found that starting xfree or xorg with dri support
>> cause a hang after a little while.  It seems that this only happens when
>> the mouse moves.  Something I didn't discover before because there
>> are lots of unplanned mouse movements - the thing is sensitive and jumps
>> a pixel now and then when I move stuff on the desk.
>
> What xorg / xfree / drm versions are you talking about?
>
>> Taking care not to move the mouse, I can start X and run glxgears
>> with acceleration.  The slightest mouse movement during 3D activity
>> kills the machine instantly so it only responds to the reset button.  
>> Mouse
>> movement without 3D activity may or may not kill the pc.
>>
>> Could there be a problem where 3D-stuff and code to move the mouse
>> "steps on each other toes" somehow?  Or some way to test this further,
>> by disabling the mouse or force some kind of software fallback for
>> the mouse cursor?
>
> You could use Option "SWcursor" "true".

This didn't help.  The cursor was definitely SW, flashing on and off
when over a scrolling xterm. The machine still died quickly.

> Since it crashes even without 3d sometimes, the problem does not seem 
> to be related to dri (as in, dri driver). Sounds more like it's 
> related to CP activity. Not sure what would cause this, there seem to 
> be a lot of mouse cursor movement crashes reported lately... Do you 
> have a USB mouse whose controller shares the IRQ with the graphic card 
> maybe?

The card gets IRQ 16, which isn't shared with anything in this machine.

Helge Hafting

Re: Another drm/dri lockup - when moving the mouse

[Martin K. Petersen]

>>>>> "Helge" == Helge Hafting <helge.hafting@aitel.hist.no> writes:

Helge> I have reported this before, but now I have some more data.  I
Helge> have an office pc with this video card: VGA compatible
Helge> controller: ATI Technologies Inc Radeon RV100 QY [Radeon
Helge> 7000/VE]

FWIW, I have exactly the same problem with recent (~2.6.9+ or so)
kernels.  PS/2 mouse as well.

(mkp@funky) ~> lspci | grep ATI
0000:01:00.0 VGA compatible controller: ATI Technologies Inc Radeon RV100 QY [Radeon 7000/VE]

Turning off DRI did it for me...

-- 
Martin K. Petersen      http://mkp.net/