I think it is highly unlikely your cache could be causing deadlocks. What are the symptoms? eb or jboss deadlock? Are many threads using the same cached remote interface proxy instance simultaneously?
What do you mean by "client"? Is it in jboss vm (maybe a session bean) or another vm?
If the client is in another vm, why is it accessing entity beans directly anyway? This is apt to cause too many remote calls and too many transactions. Even just wrapping your entity bean calls into a stateless session bean will have the same effect as your client side cache, using the internal jboss entity cache (I think).
We run all code in the same VM (at the moment, though this can change in the nearby future).
At the moment, we kicked out most of the caches and replaced them by
1) isModified() on all Entity EJB implementations
2) <tuned-updates>true<../> for all Entity Beans
3) Transactions starting in the client application (usually a SessionBean or Tomcat). To make transactions work more easy in Tomcat, we build a transaction aware request interceptor for Tomcat (which we are willing to release to the JBoss project).
This solves the deadlock problems and results in a reasonable speed.