07:53 <jnettlet> Hey guys. Do we have working support for the crypto engine and hwrng on the 5420 and later SOCs? I see that the ChromeOS kernel has the same problem as android of not being able to keep the entropy pool filled so new processes and connections can stall.

07:54 <jnettlet> I will install rngd for now but would prefer to use the hwrng which it seems does exist

09:49 <Wizzup> jnettlet: maybe haveged? I haven't run into exhausting problems before btw

09:52 <jnettlet> Wizzup, under ChromeOS?

09:54 <jnettlet> trust me I am sure you have. check your entropy_avail under /proc I am sure it is around 150-300 bytes, which means every time you launch a new time you input is micro-freezing trying to gather entropy

09:54 <jnettlet> also things that constantly run under ssl will be causing lag on input because that is the primary entropy gatherer in 3.4

09:55 <jnettlet> the reason intel doesn't have this problem is that their hwrng driver feeds the random pool with only a partial mix of kernel randomness for security.

09:56 <jnettlet> I don't know why Google continually makes this mistake. Android has the same problem

09:58 <jnettlet> I think 3.4 actually does all this within an interrupt mutex as well which when all IRQs are being serviced by CPU0 it will cause micro-stuttering in everything

10:18 <Wizzup> jnettlet: no, never under chromeOS

10:18 <Wizzup> and intel only very recently had this

10:18 <Wizzup> And most distros don't use randomness that much

10:18 <jnettlet> so the contents /proc/sys/kernel/random/entropy_avail is around 3000?

10:19 <Wizzup> nope, much less

10:20 <jnettlet> yes, so that is creating input lag

10:20 <Wizzup> lag to what exactly?

10:20 <jnettlet> and much more because in earlier kernels the input randomness is collected under an rcu lock

10:20 <Wizzup> I know this is required for a lot of things

10:20 <jnettlet> launching processes for one

10:20 <Wizzup> right, I am (soon) going to run gentoo hardened with pax etc

10:20 <Wizzup> so that'll be a problem

10:21 <jnettlet> Why does Google continue to screw up this inefficiency?

10:21 <jnettlet> it is like they aren't even trying with ARM

10:21 <Wizzup> If you want you can use haveged

10:22 <Wizzup> cat /proc/sys/kernel/random/entropy_avail

10:22 <Wizzup> 186

10:22 <jnettlet> I want to use the hwrng :)

10:22 <Wizzup> cat /proc/sys/kernel/random/entropy_avail

10:22 <Wizzup> 1708

10:22 <Wizzup> right, I guess :)

10:22 <Wizzup> I don't think haveged is a bad thing though, but ack

10:23 <jnettlet> you can tweak read_wakeup_threshold and write_wakeup_threshold so they stay awake longer and collect more randomness

10:23 <jnettlet> that is a power consuming crap alternative but makes a big difference in the snappiness of an ARM chromebook

10:23 <Wizzup> so is there a driver for the hwrng?

10:24 <jnettlet> not in the 3.4 kernel. chromeos has /dev/hwrng linked to /dev/urandom :(

10:24 <jnettlet> I don't know about upstream.

10:24 <Wizzup> I have a /dev/hwrng node

10:25 <Wizzup> With the chrome kernel, but it's not a symlink

10:26 <jnettlet> oh nice. maybe that just broke in the beta channel

10:26 <jnettlet> but it is still not feeding the entropy pool for the kernel

10:26 <D1337d> 3.18 has the exynos hwrng and tpm rng support in it

10:27 <jnettlet> great!

10:27 <jnettlet> but ARM hwrng's still aren't being used as a partial entropy pool like the intel hwrng

12:04 <D1337d> is there any good way to diagnose a kernel comming up and nothign on screen

12:04 <D1337d> without hardware mods

12:35 <James_T> lick the cpu

12:58 <D1337d> thats an option, but if i am going to pop the case i may as well break out the solder iron

13:12 <James_T> yeah