Re: PATCH: Octeon RNG support

2013-10-22 Thread Jonathan Matthew
On Tue, Oct 22, 2013 at 1:05 PM, William Orr w...@worrbase.com wrote: Hey tech@ Here's a patch that adds octeon's onboard rng chip as a source of entropy. Currently I fire this off every second, which neither seemed to increase the load on my ERL or produce duplicate outputs. This patch

Re: Update the sdmmmc stack to take care of the SMC_CAPS_SINGLE_ONLY capability

2013-10-22 Thread Sylvestre Gallon
On Sat, Oct 19, 2013 at 1:51 PM, Raphael Graf r...@undefined.ch wrote: On Fri, October 18, 2013 9:54 am, Sylvestre Gallon wrote: Hi tech@ Here is a diff to allow the sdmmc SMC_CAPS_SINGLE_ONLY caps to do something. The bits I take are from NetBSD and it works well with ommmc(4) on my Beagle

Kernel page fault in current

2013-10-22 Thread Vladimir Támara Patiño
Hi, I'm having problems with current, I'm using Xorg after some time there is a kernel trap (3 times I have seen the same one): kernel: page fault trap, code=0 stopped at wsdisplaypoll+0x35 movq 0x60(%rdx, %rax, 8), %rax Trace shows wdisplaypoll() at wdisplaypoll+0x35 VOP_POLL() at

Make bioctl(4) print cache policy

2013-10-22 Thread Mark Kettenis
Diff below makes bioctl(4) print the cache policy for that's currently in effect for RAID volumes. It only prints the state (WB for write-back, WT for write-through) if the RAID controller driver fills in the details in response to a BIOCVOL ioctl. This diff adds such support to mfi(4). #

Re: Make bioctl(4) print cache policy

2013-10-22 Thread Mike Belopuhov
On 22 October 2013 15:22, Mark Kettenis mark.kette...@xs4all.nl wrote: Diff below makes bioctl(4) print the cache policy for that's currently in effect for RAID volumes. It only prints the state (WB for write-back, WT for write-through) if the RAID controller driver fills in the details in

Re: Kernel page fault in current

2013-10-22 Thread Philip Guenther
On Tue, Oct 22, 2013 at 5:21 AM, Vladimir Támara Patiño vtam...@pasosdejesus.org wrote: Hi, I'm having problems with current, I'm using Xorg after some time there is a kernel trap (3 times I have seen the same one): Current is a moving target, so saying current without a timestamp or at least

Re: UPDATE: xkeyboard-config 2.10.1

2013-10-22 Thread Matthieu Herrb
On Thu, Oct 10, 2013 at 11:30:59PM +0600, Alexandr Shadchin wrote: Hi, This update xkeyboard-config to the latest release 2.10.1. http://koba.devio.us/distfiles/xkeyboard-config-2.10.1.diff or http://koba.devio.us/distfiles/xkeyboard-config.2.10.1.diff.tgz Change: * 10+ bugs fixed *

Re: Make bioctl(4) print cache policy

2013-10-22 Thread Nick Holland
On 10/22/13 09:47, Mike Belopuhov wrote: On 22 October 2013 15:22, Mark Kettenis mark.kette...@xs4all.nl wrote: Diff below makes bioctl(4) print the cache policy for that's currently in effect for RAID volumes. It only prints the state (WB for write-back, WT for write-through) if the RAID

PATCH: Round 2 of octeon rng

2013-10-22 Thread William Orr
Hi again tech@ This is my second attempt at a patch to add support for the octeon's onboard rng. I've fixed all of the concerns (ISC license, wrong #define, comment removal) and I've also come bearing statistics on the quality of the entropy. I dd'd 512M of /dev/random and ran the ent from

Re: PATCH: Round 2 of octeon rng

2013-10-22 Thread Ted Unangst
On Tue, Oct 22, 2013 at 18:31, William Orr wrote: You'll notice that there's no significant difference between the output of the two rngs. However, with octrng the dd completed in under a minute (more entropy in pool). Without, it took several minutes. If you want time output, I can add that

Re: PATCH: Round 2 of octeon rng

2013-10-22 Thread William Orr
On Oct 22, 2013, at 9:06 PM, Ted Unangst t...@tedunangst.com wrote: On Tue, Oct 22, 2013 at 18:31, William Orr wrote: You'll notice that there's no significant difference between the output of the two rngs. However, with octrng the dd completed in under a minute (more entropy in pool).

Re: PATCH: Round 2 of octeon rng

2013-10-22 Thread Theo de Raadt
I can do this again with time, but pulling data from /dev/random took significantly longer without my patch than with it. That is not possible.