On Mit, 2011-04-13 at 14:27 +0200, Gabriel Paubert wrote: > On Wed, Apr 13, 2011 at 02:12:16PM +0200, Michel Dänzer wrote: > > On Mit, 2011-04-13 at 09:59 +0200, Gabriel Paubert wrote: > > > On Tue, Apr 12, 2011 at 07:29:22PM +0200, Michel Dänzer 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änzer wrote: > > > > > > > > > > > > > > With no_wb=1 the driver goes a bit further but the X server ends > > > > > > > up in an infinite ioctl loop and the logs are: > > > > > > > > > > > > Which ioctl does it loop on? Please provide the Xorg.0.log file as > > > > > > well. > > > > > > > > > > From memory, the code was 0x64, which is DRM_RADEON_GEM_WAIT_IDLE. > > > > > > > > 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 ioctl > > > > always returns an error, this may not indicate a problem on its own. > > > > > > It seems to be an infinite loop, always returning EINTR because > > > of regular SIGALRM delivery. > > > > 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? > > 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. -- Earthling Michel Dänzer | http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
