Re: Revert 737a3bb9416ce2a7c7a4170852473a4fcc9c67e8 ?

["Michel Dänzer" <michel@daenzer.net>]

On Mit, 2011-04-13 at 14:27 +0200, Gabriel Paubert wrote:=20
> On Wed, Apr 13, 2011 at 02:12:16PM +0200, Michel D=C3=A4nzer wrote:
> > On Mit, 2011-04-13 at 09:59 +0200, Gabriel Paubert wrote:=20
> > > On Tue, Apr 12, 2011 at 07:29:22PM +0200, Michel D=C3=A4nzer wrote:
> > > > On Die, 2011-04-12 at 14:00 +0200, Gabriel Paubert wrote:
> > > > > On Tue, Apr 12, 2011 at 01:46:10PM +0200, Michel D=C3=A4nzer wrot=
e:
> > > > > > >=20
> > > > > > > With no_wb=3D1 the driver goes a bit further but the X server=
 ends
> > > > > > > up in an infinite ioctl loop and the logs are:=20
> > > > > >=20
> > > > > > Which ioctl does it loop on? Please provide the Xorg.0.log file=
 as well.
> > > > >=20
> > > > > From memory, the code was 0x64, which is DRM_RADEON_GEM_WAIT_IDLE=
.
> > > >=20
> > > > Note that it's normal for this ioctl to be called every time before=
 the
> > > > GPU accessible pixmap memory is accessed by the CPU. Unless the ioc=
tl
> > > > always returns an error, this may not indicate a problem on its own=
.=20
> > >=20
> > > It seems to be an infinite loop, always returning EINTR because
> > > of regular SIGALRM delivery.
> >=20
> > That does sound like the GPU locks up. Do you get any messages in dmesg
> > about lockups and attempts to reset the GPU at any time?
>=20
> No.

Hmm, I guess the constant SIGALRMs might prevent the lockup detection
from kicking in... Maybe you can try starting the X server with
-dumbSched to see if that gets things along any further, but in the end
there's probably no way around figuring out what causes the lockup and
fixing that anyway.


--=20
Earthling Michel D=C3=A4nzer           |                http://www.vmware.c=
om
Libre software enthusiast         |          Debian, X and DRI developer