-----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. - -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-----
