On Fri, Nov 05, 2010 at 03:12:38PM +0100, Phil Sutter wrote: > > Yes, kind of. With that trivial fix applied, the driver is stable most > of the time.
Great. > Yes, it does, but triggering the bug is not really trivial. I've had > best results with a speed testing tool using the asynchronous interface, > memory corruption occured in each run. The same tool operating > synchronously doesn't crash as soon, but having three or more instances > running in parallel yields the same result. > > This problem is so racey, a simple printk statement at the beginning of > padlock_xcrypt_ecb() fixes it. Enclosing the same function's content in > lock_kernel()/unlock_kernel() statements helps as well. Interesting. Do you have preemption enabled? Can you share the test program with us? > > Can you provide some information on the CPU where you're seeing > > this? > > This is the faulty one: > | -bash-4.0# cat /proc/cpuinfo > | processor : 0 > | vendor_id : CentaurHauls > | cpu family : 6 > | model : 15 > | model name : VIA Nano processor l2...@1600mhz > | stepping : 2 Is there anyone else on the list who has this hardware? Thanks, -- Email: Herbert Xu <herb...@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
