Bug#613593: xserver-xorg-video-radeon: [regression] X fails to start
On Mon, 28 Feb 2011 16:10:39 +0100, Michel Dänzer <firstname.lastname@example.org> wrote:
> > ==19774== Source and destination overlap in memcpy(0x5c84c70, 0x5c84c70,
> > 408) ==19774== at 0x40258E5: memcpy (mc_replace_strmem.c:497)
> > ==19774== by 0x49BD3EA: exaMemcpyBox (exa_migration_classic.c:59)
> > ==19774== by 0x49BD8C4: exaCopyDirty (exa_migration_classic.c:234)
> > ==19774== by 0x49BDDF3: exaCopyDirtyToFb (exa_migration_classic.c:298)
> > ==19774== by 0x49C0048: exaDoMigration_mixed
> > (exa_migration_mixed.c:113) ==19774== by 0x49BB75C: exaDoMigration
> > (exa.c:1131) ==19774== by 0x49C6E08: exaTryDriverComposite
> > (exa_render.c:734) ==19774== by 0x49C75C7: exaComposite
> > (exa_render.c:1033) ==19774== by 0x811E11C: damageComposite
> > (damage.c:640) ==19774== by 0x810F3BF: CompositePicture
> > (picture.c:1710) ==19774== by 0x49C6933: exaTrapezoids
> > (exa_render.c:1181) ==19774== by 0x810F0A7: CompositeTrapezoids
> > (picture.c:1751)
> The only way I think this could happen is if the UploadToScreen hook
> fails. Indeed, I've only noticed now that you have
> Option "EXANoDownloadFromScreen" "on"
> Option "EXANoUploadToScreen" "on"
> in xorg.conf. Does it work better without these options? The driver
> doesn't really support running without these hooks anymore.
Nice catch, thanks! Removing the options does indeed allow the server to
start, and so far everything is working correctly.
Would you like a patch to ignore (with a warning) these options if they're