DRM_CAS bug with x86_64

Ian Romanick idr at us.ibm.com
Mon Aug 8 18:56:10 PDT 2005

Hash: SHA1

Alan Coopersmith wrote:
> Ian Romanick wrote:
>> Bernardo Innocenti wrote:
>>> GAS choked on the DRM_CAS invocation in ffb_lock.h because
>>> __ret was declared as "int" and so it gets passed in %edx
>>> instead of %dl or %dh as required by the setnz instruction.
>>> I just wrapped the declaration with DRM_CAS_RESULT() as done
>>> elsewhere.
>> This seems to have never hit us because on x86 the FFB driver no-ops its
>> LOCK_HARDWARE and UNLOCK_HARDWARE macros.  Can somebody please explain
>> why that is?  My *guess* is that FFB hardware can only actually exist on
> I was wondering why ffb was even being built on x86_64.   If it's referring
> to the board from Sun (which marketing called a "Creator" or "Creator 3D"),
> it was only ever made for the UPA bus (UltraSPARC Port Architecture), not
> PCI or any other common bus, and I've never seen a UPA bus outside of a
> SPARC machine.

The irony is that it gets built on non-SPARC platforms so that we'll
know right away if a change has broken its build.  He had cases in the
past where changes that broke the ffb build went *6 months* without
being noticed.
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org


More information about the xorg mailing list