Fundamental issues for the ASU

Carsten Haitzler (The Rasterman) raster at
Fri May 16 17:54:24 CEST 2008

On Fri, 16 May 2008 16:46:48 +0100 Andy Green <andy at> babbled:

> 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
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Fedora -
> iEYEARECAAYFAkgtrGgACgkQOjLpvpq7dMqMtgCfbqpky2WCBvsE829+WDuKMuSc
> SE0An0ISjj/5ZMdSZX7VSsjXYa6VQ5On
> =N3we

Carsten Haitzler (The Rasterman) <raster at>

More information about the distro-devel mailing list