On Fri, 16 May 2008 16:46:48 +0100 Andy Green <[EMAIL PROTECTED]> babbled:
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Somebody in the thread at some point said: > > | | gah! waiting for the cmdq to flush and it never does. thats bad. too > much > | | context switching - lets keep this filed for now? > | > | Command queue handling in glamofb -- and it seems from what I saw xglamo > | contains a cut and paste of it -- had a very bad issue with not having > | locking around command queue stuff, which is AFAIK modal in the Glamo. > | I added locking there and various kernel badness on boot went away. So > | suggest eyeballing it with that in mind. > | > |> x wont have any locks in it as its not threaded! :) but good advice in > |> general! :) > > Did anyone tell glamofb about this :-) Because it can just come in and > do what it feels like at any time regardless of "not threaded" X state > or whatever modal juju it has put the glamo into. Dunno what would > trigger it to do so though. > > I was surprised to see "kernel" code like setting pll rates in xglamo, > if it is indeed anything to do with the problem maybe the answer is to > make ioctls to do all that in glamofb under a single locking system. hmm - this could be it if we suspend.resume - kernel fiddling while the glamo is busy and cmdq is active... though this shouldnt happen.... as such x would validly assume no one else is screwing with the glamo while it owns it. > - -Andy > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org > > iEYEARECAAYFAkgtrGgACgkQOjLpvpq7dMqMtgCfbqpky2WCBvsE829+WDuKMuSc > SE0An0ISjj/5ZMdSZX7VSsjXYa6VQ5On > =N3we > -----END PGP SIGNATURE----- -- Carsten Haitzler (The Rasterman) <[EMAIL PROTECTED]>
