On Fri, 07 Nov 2008 14:30:47 -0800
James Hsiao <[EMAIL PROTECTED]> wrote:
> diff --git a/arch/powerpc/boot/dts/kilauea.dts
> b/arch/powerpc/boot/dts/kilauea.dts
> index dececc4..43d4f91 100644
> --- a/arch/powerpc/boot/dts/kilauea.dts
> +++ b/arch/powerpc/boot/dts/kilauea.dts
> @@ -94,6 +94,13 @@
On Wed, Nov 12, 2008 at 11:36:49PM +0100, Tobias Geiger ([EMAIL PROTECTED])
wrote:
> it works! for the first time i have this card, it actually does something
> useful ;) Thanks a lot so far!
>
> Problem now is, it eates up all my cpu somehow - i.e. my system now generates
> hi/si 98% of the ti
Hi Evgeniy
it works! for the first time i have this card, it actually does something
useful ;) Thanks a lot so far!
Problem now is, it eates up all my cpu somehow - i.e. my system now generates
hi/si 98% of the time, everything feels ~200% slower than "normal"
Greetings and many thanks for you
>>> # grep talitos /proc/interrupts
>>> 24: 0 IPIC Level talitos
>>>
>>> What could cause this?
>>>
Doh! After playing around for a few days, I figured it out:
>From the DTS File:
[EMAIL PROTECTED] {
...
interrupts = <0x11 0x8>;
...
};
Turns out SEC is Interrupt ID 11, which is
o `crypto_alloc_shash'
lib/built-in.o: In function `libcrc32c_mod_fini':
libcrc32c.c:(.exit.text+0xc): undefined reference to `crypto_free_tfm'
Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
---
lib/Kconfig | 1 +
1 file changed, 1 insertion(+)
--- linux-next-20081112
On Wed, Nov 12, 2008 at 08:43:06PM +0100, Tobias Geiger ([EMAIL PROTECTED])
wrote:
> Hello Evgeniy,
>
> i tried that, know it just hangs while mounting the decrypted device. No
> special dmesg error or anything.:
Please try attached patch against vanilla driver.
Likely I messed up with ring siz
On Wednesday 12 November 2008 14:52:59 Jarod Wilson wrote:
> While working with some FIPS RNGVS test vectors yesterday, I discovered a
> little bug in the way the ansi_cprng code works right now.
>
> For example, the following test vector (complete with expected result)
> from http://csrc.nist.gov/
On Wed, Nov 12, 2008 at 02:52:59PM -0500, Jarod Wilson wrote:
> While working with some FIPS RNGVS test vectors yesterday, I discovered a
> little bug in the way the ansi_cprng code works right now.
>
> For example, the following test vector (complete with expected result)
> from http://csrc.nist.
While working with some FIPS RNGVS test vectors yesterday, I discovered a
little bug in the way the ansi_cprng code works right now.
For example, the following test vector (complete with expected result)
from http://csrc.nist.gov/groups/STM/cavp/documents/rng/RNGVS.pdf ...
Key = f3b1666d13607242e
Hello Evgeniy,
i tried that, know it just hangs while mounting the decrypted device. No
special dmesg error or anything.:
ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 5
PCI: setting IRQ 5 as level-triggered
hifn795x :00:09.0: PCI INT A -> Link[LNKA] -> GSI 5 (level, low) -> IRQ 5
hifn795x:
Hi,
i tested 2.6.28-rc4 with the patch from
http://marc.info/?l=linux-crypto-vger&m=122643041300555&w=2
but i get the following error, as soon as i try to mount the de-crypted
dm-cypt-block device (cryptsetup luksOpen however works):
hifn0: r: , active: 0, started: 20, success: 4247: q
Hi Tobias.
On Wed, Nov 12, 2008 at 05:10:41PM +0100, Tobias Geiger ([EMAIL PROTECTED])
wrote:
> hifn0: r: , active: 0, started: 20, success: 4247: qlen: 0/1, reset:
> 1.
Please try to disable watchdog for now, its logic to detect stall
hardware is a bit subtle:
--- drivers/crypto/hifn_
12 matches
Mail list logo
