Re: Announce loop-AES-v3.7l file/swap crypto package

[Markus Reichelt]

* Jari Ruusu  wrote:

> loop-AES changes since previous release:
> - Worked around kernel interface changes on 4.13 kernels.
> - Added second util-linux patch to work around gpg 2 pinentry-mode bug.

Thank you!

Re: Announce loop-AES-v3.7l file/swap crypto package

[Markus Reichelt]

* Jari Ruusu  wrote:

> loop-AES changes since previous release:
> - Worked around kernel interface changes on 4.13 kernels.
> - Added second util-linux patch to work around gpg 2 pinentry-mode bug.

Thank you!

Re: Linux 3.10.54

[Markus Reichelt]

* Greg KH  wrote:

> I'm announcing the release of the 3.10.54 kernel.

These days I don't follow this list that closely anymore but I wonder
why the following patch has not been included:

md/raid6: avoid data corruption during recovery of double-degraded RAID6
http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/drivers/md?id=9c4bdf697c39805078392d5ddbbba5ae5680e0dd

Thanks for any info on that.

-- 
left blank, right bald
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.10.54

[Markus Reichelt]

* Greg KH gre...@linuxfoundation.org wrote:

 I'm announcing the release of the 3.10.54 kernel.

These days I don't follow this list that closely anymore but I wonder
why the following patch has not been included:

md/raid6: avoid data corruption during recovery of double-degraded RAID6
http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/drivers/md?id=9c4bdf697c39805078392d5ddbbba5ae5680e0dd

Thanks for any info on that.

-- 
left blank, right bald
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.6.23.14

[markus reichelt]

* Greg Kroah-Hartman <[EMAIL PROTECTED]> wrote:

> It contains a single fix for a problem that could cause a local
> user to cause file system corruption on some types of filesystems.

Some types of filesystems? Which ones? 

-- 
left blank, right bald


pgpDjfZ3kpyxn.pgp
Description: PGP signature

Re: Linux 2.6.23.14

[markus reichelt]

* Greg Kroah-Hartman [EMAIL PROTECTED] wrote:

 It contains a single fix for a problem that could cause a local
 user to cause file system corruption on some types of filesystems.

Some types of filesystems? Which ones? 

-- 
left blank, right bald


pgpDjfZ3kpyxn.pgp
Description: PGP signature

Re: NFS Bug in 2.6.23 ?

[markus reichelt]

* Gianluca Alberici <[EMAIL PROTECTED]> wrote:

> If i cd into it and ls it is like doing a refresh: everything works
> again for a certain amount of time, then, again. It reminds me an
> old version of CFS which used to claim: 'stale NFS file handle'.

"there are no fish in my pond"


# CONFIG_NFS_DIRECTIO is not set

Ive had probs with that option set, disabling did the trick for me.

-- 
left blank, right bald


pgpZAfnQNwrd9.pgp
Description: PGP signature

Re: NFS Bug in 2.6.23 ?

[markus reichelt]

* Gianluca Alberici [EMAIL PROTECTED] wrote:

 If i cd into it and ls it is like doing a refresh: everything works
 again for a certain amount of time, then, again. It reminds me an
 old version of CFS which used to claim: 'stale NFS file handle'.

there are no fish in my pond


# CONFIG_NFS_DIRECTIO is not set

Ive had probs with that option set, disabling did the trick for me.

-- 
left blank, right bald


pgpZAfnQNwrd9.pgp
Description: PGP signature

ACPI question: Incorrect checksum.

[markus reichelt]

Hi,

I noticed the following line in dmesg output with 23-rcX kernels


ACPI Warning (tbutils-0217): Incorrect checksum in table [OEMB] -
5E, should be 31 [20070126]


Before I start investigating the issue I wonder: Is this something
serious or just a minor issue? My system works just fine so far
(normal usage, 23.rc2-rc7).

-- 
left blank, right bald


pgpqEwBErbrUF.pgp
Description: PGP signature

ACPI question: Incorrect checksum.

[markus reichelt]

Hi,

I noticed the following line in dmesg output with 23-rcX kernels


ACPI Warning (tbutils-0217): Incorrect checksum in table [OEMB] -
5E, should be 31 [20070126]


Before I start investigating the issue I wonder: Is this something
serious or just a minor issue? My system works just fine so far
(normal usage, 23.rc2-rc7).

-- 
left blank, right bald


pgpqEwBErbrUF.pgp
Description: PGP signature

2.6.23-rc1 section mismatch warnings

[markus reichelt]

Hi,

2.6.23-rc1 (as well as 2.6.22.x) produces some section mismatch
warnings during compile on slackware 11 (gcc-3.4.6, glibc-2.3.6):

  LD  vmlinux.o
  MODPOST vmlinux.o
WARNING: vmlinux.o(.text+0x139c1): Section mismatch: reference to
.init.data:trampoline_end (between 'setup_trampoline' and
'cpu_coregroup_map')
WARNING: vmlinux.o(.text+0x139c9): Section mismatch: reference to
.init.data:trampoline_data (between 'setup_trampoline' and
'cpu_coregroup_map')
WARNING: vmlinux.o(.text+0x139d3): Section mismatch: reference to
.init.data:trampoline_data (between 'setup_trampoline' and
'cpu_coregroup_map')
WARNING: vmlinux.o(.data+0x275c): Section mismatch: reference to
.init.text:thermal_throttle_cpu_callback (between
'thermal_throttle_cpu_notifier' and 'mce_work')

config is just "make menuconfig" and exit, after unpacking sources.
with and without "optimize for size", config attached anyway


processor   : 0
vendor_id   : AuthenticAMD
cpu family  : 15
model   : 44
model name  : AMD Sempron(tm) Processor 2800+
stepping: 2
cpu MHz : 1607.821
cache size  : 256 KB
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 1
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr
pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext
fxsr_opt lm 3dnowext 3dnow up pni lahf_lm ts ttp tm stc
bogomips: 3217.76
clflush size: 64

Linux version 2.6.21.5 ([EMAIL PROTECTED]) (gcc version 3.4.6) #1 SMP
PREEMPT Sat Jun 30 15:53:09 CEST 2007

-- 
left blank, right bald
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.23-rc1
# Mon Jul 23 08:44:17 2007
#
CONFIG_X86_32=y
CONFIG_GENERIC_TIME=y
CONFIG_GENERIC_CMOS_UPDATE=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_SEMAPHORE_SLEEPERS=y
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_ZONE_DMA=y
CONFIG_QUICKLIST=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_DMI=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32

#
# General setup
#
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
# CONFIG_BSD_PROCESS_ACCT is not set
# CONFIG_TASKSTATS is not set
# CONFIG_USER_NS is not set
# CONFIG_AUDIT is not set
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=18
# CONFIG_CPUSETS is not set
CONFIG_SYSFS_DEPRECATED=y
CONFIG_RELAY=y
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SYSCTL=y
# CONFIG_EMBEDDED is not set
CONFIG_UID16=y
CONFIG_SYSCTL_SYSCALL=y
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_ANON_INODES=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_SLUB_DEBUG=y
# CONFIG_SLAB is not set
CONFIG_SLUB=y
# CONFIG_SLOB is not set
CONFIG_RT_MUTEXES=y
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
# CONFIG_MODVERSIONS is not set
# CONFIG_MODULE_SRCVERSION_ALL is not set
# CONFIG_KMOD is not set
CONFIG_STOP_MACHINE=y
CONFIG_BLOCK=y
CONFIG_LBD=y
# CONFIG_BLK_DEV_IO_TRACE is not set
# CONFIG_LSF is not set
# CONFIG_BLK_DEV_BSG is not set

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
CONFIG_DEFAULT_AS=y
# CONFIG_DEFAULT_DEADLINE is not set
# CONFIG_DEFAULT_CFQ is not set
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED="anticipatory"

#
# Processor type and features
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_SMP=y
# CONFIG_X86_PC is not set
# CONFIG_X86_ELAN is not set
# CONFIG_X86_VOYAGER is not set
# CONFIG_X86_NUMAQ is not set
# CONFIG_X86_SUMMIT is not set
# CONFIG_X86_BIGSMP is not set
# CONFIG_X86_VISWS is not set
CONFIG_X86_GENERICARCH=y
# CONFIG_X86_ES7000 is not set
# CONFIG_PARAVIRT is not set
CONFIG_X86_CYCLONE_TIMER=y
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
# CONFIG_MPENTIUMII is not set
CONFIG_MPENTIUMIII=y
# CONFIG_MPENTIUMM is not set
# CONFIG_MCORE2 is not set
# CONFIG_MPENTIUM4 is not set
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
# CONFIG_MK8 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MEFFICEON is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MGEODEGX1 is not set

2.6.23-rc1 section mismatch warnings

[markus reichelt]

Hi,

2.6.23-rc1 (as well as 2.6.22.x) produces some section mismatch
warnings during compile on slackware 11 (gcc-3.4.6, glibc-2.3.6):

  LD  vmlinux.o
  MODPOST vmlinux.o
WARNING: vmlinux.o(.text+0x139c1): Section mismatch: reference to
.init.data:trampoline_end (between 'setup_trampoline' and
'cpu_coregroup_map')
WARNING: vmlinux.o(.text+0x139c9): Section mismatch: reference to
.init.data:trampoline_data (between 'setup_trampoline' and
'cpu_coregroup_map')
WARNING: vmlinux.o(.text+0x139d3): Section mismatch: reference to
.init.data:trampoline_data (between 'setup_trampoline' and
'cpu_coregroup_map')
WARNING: vmlinux.o(.data+0x275c): Section mismatch: reference to
.init.text:thermal_throttle_cpu_callback (between
'thermal_throttle_cpu_notifier' and 'mce_work')

config is just make menuconfig and exit, after unpacking sources.
with and without optimize for size, config attached anyway


processor   : 0
vendor_id   : AuthenticAMD
cpu family  : 15
model   : 44
model name  : AMD Sempron(tm) Processor 2800+
stepping: 2
cpu MHz : 1607.821
cache size  : 256 KB
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 1
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr
pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext
fxsr_opt lm 3dnowext 3dnow up pni lahf_lm ts ttp tm stc
bogomips: 3217.76
clflush size: 64

Linux version 2.6.21.5 ([EMAIL PROTECTED]) (gcc version 3.4.6) #1 SMP
PREEMPT Sat Jun 30 15:53:09 CEST 2007

-- 
left blank, right bald
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.23-rc1
# Mon Jul 23 08:44:17 2007
#
CONFIG_X86_32=y
CONFIG_GENERIC_TIME=y
CONFIG_GENERIC_CMOS_UPDATE=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_SEMAPHORE_SLEEPERS=y
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_ZONE_DMA=y
CONFIG_QUICKLIST=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_DMI=y
CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32

#
# General setup
#
CONFIG_LOCALVERSION=
CONFIG_LOCALVERSION_AUTO=y
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
# CONFIG_BSD_PROCESS_ACCT is not set
# CONFIG_TASKSTATS is not set
# CONFIG_USER_NS is not set
# CONFIG_AUDIT is not set
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=18
# CONFIG_CPUSETS is not set
CONFIG_SYSFS_DEPRECATED=y
CONFIG_RELAY=y
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SYSCTL=y
# CONFIG_EMBEDDED is not set
CONFIG_UID16=y
CONFIG_SYSCTL_SYSCALL=y
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_ANON_INODES=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_SLUB_DEBUG=y
# CONFIG_SLAB is not set
CONFIG_SLUB=y
# CONFIG_SLOB is not set
CONFIG_RT_MUTEXES=y
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
# CONFIG_MODVERSIONS is not set
# CONFIG_MODULE_SRCVERSION_ALL is not set
# CONFIG_KMOD is not set
CONFIG_STOP_MACHINE=y
CONFIG_BLOCK=y
CONFIG_LBD=y
# CONFIG_BLK_DEV_IO_TRACE is not set
# CONFIG_LSF is not set
# CONFIG_BLK_DEV_BSG is not set

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
CONFIG_DEFAULT_AS=y
# CONFIG_DEFAULT_DEADLINE is not set
# CONFIG_DEFAULT_CFQ is not set
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED=anticipatory

#
# Processor type and features
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_SMP=y
# CONFIG_X86_PC is not set
# CONFIG_X86_ELAN is not set
# CONFIG_X86_VOYAGER is not set
# CONFIG_X86_NUMAQ is not set
# CONFIG_X86_SUMMIT is not set
# CONFIG_X86_BIGSMP is not set
# CONFIG_X86_VISWS is not set
CONFIG_X86_GENERICARCH=y
# CONFIG_X86_ES7000 is not set
# CONFIG_PARAVIRT is not set
CONFIG_X86_CYCLONE_TIMER=y
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
# CONFIG_MPENTIUMII is not set
CONFIG_MPENTIUMIII=y
# CONFIG_MPENTIUMM is not set
# CONFIG_MCORE2 is not set
# CONFIG_MPENTIUM4 is not set
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
# CONFIG_MK8 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MEFFICEON is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MGEODEGX1 is not set
# 

Re: ck1 patches for 2.6.22 and 2.6.20

[markus reichelt]

* "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:

> Does -ck1 patches for 2.6.22 and 2.6.20 make the same job? Or it's
> better to backport -ck1 for 2.6.22 to 2.6.20?

fyi, http://article.gmane.org/gmane.linux.kernel.ck/7850

-- 
left blank, right bald


pgpZWtSASam7s.pgp
Description: PGP signature

Re: ck1 patches for 2.6.22 and 2.6.20

[markus reichelt]

* [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:

 Does -ck1 patches for 2.6.22 and 2.6.20 make the same job? Or it's
 better to backport -ck1 for 2.6.22 to 2.6.20?

fyi, http://article.gmane.org/gmane.linux.kernel.ck/7850

-- 
left blank, right bald


pgpZWtSASam7s.pgp
Description: PGP signature

Re: /dev/loop* devices not appearing in /dev (at least since 2.6.22-rc3*)

[markus reichelt]

* Paolo Ornati <[EMAIL PROTECTED]> wrote:

> So with this patch "max_loop=32" will create 32 loop devices... but
> then it doesn't allow more of them.

Well, that's what a max_ parameter implies ;p

A manually set limit of loop devices is ok with me. (32 was just an
example -- After all, I could have chosen 256 just to annoy some
people :-)

And with the recent hype of creating things when needed, or even
recycling already used ones (sdx), I worry that this impacts
stability or even usability as a whole. (yes, it's a -rc release ...)

I'll be staying with 2.6.20.x for a year or so. Get the newly
introduced bugs squashed before they have a chance to bug me, heh ;P


PS: Just wondering: Who came up with this "on-demand" hype?
-- 
left blank, right bald


pgpj4JvUea3ww.pgp
Description: PGP signature

Re: /dev/loop* devices not appearing in /dev (at least since 2.6.22-rc3*)

[markus reichelt]

* Matthew <[EMAIL PROTECTED]> wrote:

> I read that now loop devices are being created on demand, which
> obviously (still) not works

yes, someone thought this was a good idea :(


> Is there a way to trigger such creation?

does modprobe loop max_loop=32 work?

-- 
left blank, right bald


pgp1Dm6S8T6gI.pgp
Description: PGP signature

Re: /dev/loop* devices not appearing in /dev (at least since 2.6.22-rc3*)

[markus reichelt]

* Matthew [EMAIL PROTECTED] wrote:

 I read that now loop devices are being created on demand, which
 obviously (still) not works

yes, someone thought this was a good idea :(


 Is there a way to trigger such creation?

does modprobe loop max_loop=32 work?

-- 
left blank, right bald


pgp1Dm6S8T6gI.pgp
Description: PGP signature

Re: /dev/loop* devices not appearing in /dev (at least since 2.6.22-rc3*)

[markus reichelt]

* Paolo Ornati [EMAIL PROTECTED] wrote:

 So with this patch max_loop=32 will create 32 loop devices... but
 then it doesn't allow more of them.

Well, that's what a max_ parameter implies ;p

A manually set limit of loop devices is ok with me. (32 was just an
example -- After all, I could have chosen 256 just to annoy some
people :-)

And with the recent hype of creating things when needed, or even
recycling already used ones (sdx), I worry that this impacts
stability or even usability as a whole. (yes, it's a -rc release ...)

I'll be staying with 2.6.20.x for a year or so. Get the newly
introduced bugs squashed before they have a chance to bug me, heh ;P


PS: Just wondering: Who came up with this on-demand hype?
-- 
left blank, right bald


pgpj4JvUea3ww.pgp
Description: PGP signature

Re: Announce loop-AES-v3.2a file/swap crypto package

[markus reichelt]

* Jari Ruusu <[EMAIL PROTECTED]> wrote:

> loop-AES changes since previous release:
> - loop_twofish.c loop_serpent.c loop_blowfish.c modules included.
>   They are not built by default. Add EXTRA_CIPHERS=y make parameter
>   to build them.

Just curious, will the ciphers package also be continued/available
separately as before or is it merged from now on into the loop-aes
package?


-- 
left blank, right bald


pgp07NXkceOEL.pgp
Description: PGP signature

Re: Announce loop-AES-v3.2a file/swap crypto package

[markus reichelt]

* Jari Ruusu [EMAIL PROTECTED] wrote:

 loop-AES changes since previous release:
 - loop_twofish.c loop_serpent.c loop_blowfish.c modules included.
   They are not built by default. Add EXTRA_CIPHERS=y make parameter
   to build them.

Just curious, will the ciphers package also be continued/available
separately as before or is it merged from now on into the loop-aes
package?


-- 
left blank, right bald


pgp07NXkceOEL.pgp
Description: PGP signature

entropy of /dev/random vs. openssl rand

[markus reichelt]

Hi,

I need to create a moderate amount of v3 keys for loop-aes and wonder
how/if the "openssl rand" implementation differs significantly from
/dev/random concerning entropy.

In case /dev/random and "openssl rand" are somewhat comparable, I
would just use the latter to create the keys.

However, I certainly don't want to use a /dev/urandom look-alike.

Any feedback appreciated.

-- 
left blank, right bald


pgpHXQtuNUKrD.pgp
Description: PGP signature

entropy of /dev/random vs. openssl rand

[markus reichelt]

Hi,

I need to create a moderate amount of v3 keys for loop-aes and wonder
how/if the openssl rand implementation differs significantly from
/dev/random concerning entropy.

In case /dev/random and openssl rand are somewhat comparable, I
would just use the latter to create the keys.

However, I certainly don't want to use a /dev/urandom look-alike.

Any feedback appreciated.

-- 
left blank, right bald


pgpHXQtuNUKrD.pgp
Description: PGP signature

Strange performance drop with reconnected external drives

[markus reichelt]

Hi,

I'm encountered the following scenario:

Several encrypted external USB HDDs were mounted (via a hub) when
Something Bad happened: Accidentially the cable connecting the hub to
the laptop was disconnected. The devices used at that time were
/dev/sda and /dev/sdb.

Logfiles showed the usual USB stuff: disconnections, nothing really
worrysome, no oops, no bugs.

So I almost immediately replugged one drive and mounted it again, the
device used was /dev/sdc and performance was as usual. A few minutes
later I replugged the other drive and the device it was associated
with was /dev/sda. There were no error messages, the mount operation
proceeded normally, filesystem recovery went smoothly. The filesystem
was not corrupted during normal use afterwards.

I don't think the hub is the issue, but the recycling of used
/dev/sd* devices:

The really strange thing was the considerable loss in performance.
Writing files at ~ 1,5 MB/s was about a 10th of the normal
throughput. Reading was also slow. I noticed that the drive's LED was
blinking slower than usual during drive access, as if there was a
delay of ~ 100 ms during write operations.

The kernel used was 2.6.21-rc3 with recent loop-aes v 3.1f.

I strongly suspect the code of handling SCSI-compatible devices (or
whatever the code handling external USB HDDs is called exactly ;-).
Earlier kernels (2.6.16.x) just used the next available devices e.g.
/dev/sdc & /dev/sdd and did not recycle ones that had been in use
already.

Is there a way (apart from going back to earlier kernels) to get the
old behaviour back? I'd very much like that. A .config option, boot
parameter, patch, anything?

-- 
left blank, right bald


pgpz0E0A36NOW.pgp
Description: PGP signature

Strange performance drop with reconnected external drives

[markus reichelt]

Hi,

I'm encountered the following scenario:

Several encrypted external USB HDDs were mounted (via a hub) when
Something Bad happened: Accidentially the cable connecting the hub to
the laptop was disconnected. The devices used at that time were
/dev/sda and /dev/sdb.

Logfiles showed the usual USB stuff: disconnections, nothing really
worrysome, no oops, no bugs.

So I almost immediately replugged one drive and mounted it again, the
device used was /dev/sdc and performance was as usual. A few minutes
later I replugged the other drive and the device it was associated
with was /dev/sda. There were no error messages, the mount operation
proceeded normally, filesystem recovery went smoothly. The filesystem
was not corrupted during normal use afterwards.

I don't think the hub is the issue, but the recycling of used
/dev/sd* devices:

The really strange thing was the considerable loss in performance.
Writing files at ~ 1,5 MB/s was about a 10th of the normal
throughput. Reading was also slow. I noticed that the drive's LED was
blinking slower than usual during drive access, as if there was a
delay of ~ 100 ms during write operations.

The kernel used was 2.6.21-rc3 with recent loop-aes v 3.1f.

I strongly suspect the code of handling SCSI-compatible devices (or
whatever the code handling external USB HDDs is called exactly ;-).
Earlier kernels (2.6.16.x) just used the next available devices e.g.
/dev/sdc  /dev/sdd and did not recycle ones that had been in use
already.

Is there a way (apart from going back to earlier kernels) to get the
old behaviour back? I'd very much like that. A .config option, boot
parameter, patch, anything?

-- 
left blank, right bald


pgpz0E0A36NOW.pgp
Description: PGP signature

Re: race condition in dm-crypt?

[markus reichelt]

* "Jan C. Nordholz" <[EMAIL PROTECTED]> wrote:

> I'm seeing this for quite a while now (since 2.6.16 at least), but
> without any obvious indicator to what might be causing it... where
> should I continue debugging this?

I bet folks at [EMAIL PROTECTED] would love to hear about this.

-- 
left blank, right bald


pgpF8tQkEIaFG.pgp
Description: PGP signature

Re: race condition in dm-crypt?

[markus reichelt]

* Jan C. Nordholz [EMAIL PROTECTED] wrote:

 I'm seeing this for quite a while now (since 2.6.16 at least), but
 without any obvious indicator to what might be causing it... where
 should I continue debugging this?

I bet folks at [EMAIL PROTECTED] would love to hear about this.

-- 
left blank, right bald


pgpF8tQkEIaFG.pgp
Description: PGP signature

Re: max_loop limit

[markus reichelt]

* Tomas M <[EMAIL PROTECTED]> wrote:

> I hope you will like it and you will include it in kernel.
> Or, if not, maybe this patch will start some debate regarding
> the current insufficient limit of 255 loop devices.

255 loop devices are insufficient? What kind of scenario do you have
in mind?


-- 
left blank, right bald


pgp831Kb341qb.pgp
Description: PGP signature

Re: max_loop limit

[markus reichelt]

* Tomas M [EMAIL PROTECTED] wrote:

 I hope you will like it and you will include it in kernel.
 Or, if not, maybe this patch will start some debate regarding
 the current insufficient limit of 255 loop devices.

255 loop devices are insufficient? What kind of scenario do you have
in mind?


-- 
left blank, right bald


pgp831Kb341qb.pgp
Description: PGP signature

Re: encrypting jffs2 filesystem with DM-crypt or what else?

[markus reichelt]

* emin ak <[EMAIL PROTECTED]> wrote:

> I need to encrypt a jffs2/mtd formatted flash filesystem for an
> embedded device, Normally using a loopback interface (cryptoloop,
> DM-crypt or loop-aes) solves this problem but they are not well
> known on journalling file systems (like jffs2) because of cached
> write etc.. Also I could'nt find any guideline for encrypting
> fikesystem on a flash.

device-backed loops are ok, file-based once aren't. The cache issue
you talk about concerns writing caches of HDDs f.e., I haven't seen a
flash device with writing cache. However, in most cases writing cache
can be turned off.

Go with README in the loop-aes package. Don't use cryptoloop, it's
insecure.


> There is an ugly workaround to overcome this problem, I have placed
> an encrypted ext2 filesystem image on an normal jffs2 partition and
> mount this encrypted partition on a loopback, but this is not
> secure, consumes alot for disk space and not reliable (is'nt it?)
> Is there any other way to encrypt an jjffs2 partition, if not, what
> do you think about my ugly workaround?

You shouldn't do that. One more option is, in case you feel lucky and
space is not of great concern, ecryptfs in latest kernels. It's still
experimental but its roadmap looks promising. And they need testers
;-)


-- 
left blank, right bald


pgpMhGsJPmT0t.pgp
Description: PGP signature

Re: encrypting jffs2 filesystem with DM-crypt or what else?

[markus reichelt]

* emin ak [EMAIL PROTECTED] wrote:

 I need to encrypt a jffs2/mtd formatted flash filesystem for an
 embedded device, Normally using a loopback interface (cryptoloop,
 DM-crypt or loop-aes) solves this problem but they are not well
 known on journalling file systems (like jffs2) because of cached
 write etc.. Also I could'nt find any guideline for encrypting
 fikesystem on a flash.

device-backed loops are ok, file-based once aren't. The cache issue
you talk about concerns writing caches of HDDs f.e., I haven't seen a
flash device with writing cache. However, in most cases writing cache
can be turned off.

Go with README in the loop-aes package. Don't use cryptoloop, it's
insecure.


 There is an ugly workaround to overcome this problem, I have placed
 an encrypted ext2 filesystem image on an normal jffs2 partition and
 mount this encrypted partition on a loopback, but this is not
 secure, consumes alot for disk space and not reliable (is'nt it?)
 Is there any other way to encrypt an jjffs2 partition, if not, what
 do you think about my ugly workaround?

You shouldn't do that. One more option is, in case you feel lucky and
space is not of great concern, ecryptfs in latest kernels. It's still
experimental but its roadmap looks promising. And they need testers
;-)


-- 
left blank, right bald


pgpMhGsJPmT0t.pgp
Description: PGP signature

Re: 2.6.19.1: kobject_add failed for audio with -EEXIST

[markus reichelt]

* Takashi Iwai <[EMAIL PROTECTED]> wrote:

> At Tue, 12 Dec 2006 17:01:35 +0100,
> markus reichelt wrote:
> > 
> > Hi,
> > 
> > I'm still having this prob at boot. please advise.
> 
> It's the place trying to create OSS audio entry.
> What points /sys/class/sound/audio/device ?


sorry for the late answer, I totally missed your mail

I'm not sure I get what you are saying but this is what's there under
2.6.19.1

 ls -al /sys/class/sound/audio/
insgesamt 0
drwxr-xr-x  2 root root0 2006-12-24 16:12 .
drwxr-xr-x 22 root root0 2006-12-12 17:53 ..
-r--r--r--  1 root root 4096 2006-12-24 16:12 dev
lrwxrwxrwx  1 root root0 2006-12-24 16:12 subsystem ->
../../../class/sound
--w---  1 root root 4096 2006-12-24 16:12 uevent

ls -al /sys/class/sound/audio1/
insgesamt 0
drwxr-xr-x  2 root root0 2006-12-24 16:12 .
drwxr-xr-x 22 root root0 2006-12-12 17:53 ..
-r--r--r--  1 root root 4096 2006-12-24 16:12 dev
lrwxrwxrwx  1 root root0 2006-12-24 16:12 device ->
../../../devices/pci:00/:00:0e.0/:02:0a.1
lrwxrwxrwx  1 root root0 2006-12-24 16:12 subsystem ->
../../../class/sound
--w---  1 root root 4096 2006-12-24 16:12 uevent

these are the two entries /sys/class/sound/audio*


the only difference between the kernels before my last mail about the
issue is that with .19.1 i can use the sound hardware which was not
possible beforehand; it was simply dead after the borked dmesg.

if you need anything else, please dont heasitate to mail. thanks.

-- 
left blank, right bald


pgpTjf5a7di5o.pgp
Description: PGP signature

Re: 2.6.19.1: kobject_add failed for audio with -EEXIST

[markus reichelt]

* Takashi Iwai [EMAIL PROTECTED] wrote:

 At Tue, 12 Dec 2006 17:01:35 +0100,
 markus reichelt wrote:
  
  Hi,
  
  I'm still having this prob at boot. please advise.
 
 It's the place trying to create OSS audio entry.
 What points /sys/class/sound/audio/device ?


sorry for the late answer, I totally missed your mail

I'm not sure I get what you are saying but this is what's there under
2.6.19.1

 ls -al /sys/class/sound/audio/
insgesamt 0
drwxr-xr-x  2 root root0 2006-12-24 16:12 .
drwxr-xr-x 22 root root0 2006-12-12 17:53 ..
-r--r--r--  1 root root 4096 2006-12-24 16:12 dev
lrwxrwxrwx  1 root root0 2006-12-24 16:12 subsystem -
../../../class/sound
--w---  1 root root 4096 2006-12-24 16:12 uevent

ls -al /sys/class/sound/audio1/
insgesamt 0
drwxr-xr-x  2 root root0 2006-12-24 16:12 .
drwxr-xr-x 22 root root0 2006-12-12 17:53 ..
-r--r--r--  1 root root 4096 2006-12-24 16:12 dev
lrwxrwxrwx  1 root root0 2006-12-24 16:12 device -
../../../devices/pci:00/:00:0e.0/:02:0a.1
lrwxrwxrwx  1 root root0 2006-12-24 16:12 subsystem -
../../../class/sound
--w---  1 root root 4096 2006-12-24 16:12 uevent

these are the two entries /sys/class/sound/audio*


the only difference between the kernels before my last mail about the
issue is that with .19.1 i can use the sound hardware which was not
possible beforehand; it was simply dead after the borked dmesg.

if you need anything else, please dont heasitate to mail. thanks.

-- 
left blank, right bald


pgpTjf5a7di5o.pgp
Description: PGP signature

2.6.19.1: kobject_add failed for audio with -EEXIST

[markus reichelt]

Hi,

I'm still having this prob at boot. please advise.


Advanced Linux Sound Architecture Driver Version 1.0.13 (Tue Nov 28
14:07:24 2006 UTC).
ACPI: PCI Interrupt :02:0a.1[A] -> Link [LNKA] -> GSI 19 (level,
low) -> IRQ 16
ACPI: PCI Interrupt Link [LAUI] enabled at IRQ 21
ACPI: PCI Interrupt :00:06.0[A] -> Link [LAUI] -> GSI 21 (level,
low) -> IRQ 19
PCI: Setting latency timer of device :00:06.0 to 64
intel8x0_measure_ac97_clock: measured 60001 usecs
intel8x0: clocking to 55385
kobject_add failed for audio with -EEXIST, don't try to register
things with the same name in the same directory.
 [] kobject_add+0x107/0x110
 [] class_device_add+0xa3/0x2a9
 [] class_device_create+0x79/0x8f
 [] sound_insert_unit+0xe8/0xfb
 [] register_sound_special_device+0x111/0x119
 [] snd_register_oss_device+0x107/0x15d
 [] register_oss_dsp+0x4d/0x76
 [] kobject_uevent+0x391/0x399
 [] snd_pcm_oss_register_minor+0x2d/0xcc
 [] vsnprintf+0x495/0x4d3
 [] snd_timer_dev_register+0xbe/0xc3
 [] snd_device_register+0x32/0x53
 [] snd_pcm_timer_init+0xc0/0xf3
 [] snd_add_device_sysfs_file+0x4b/0x52
 [] snd_pcm_dev_register+0x181/0x199
 [] snd_device_register_all+0x2e/0x42
 [] snd_card_register+0x9/0xaa
 [] snd_intel8x0_probe+0x170/0x195
 [] pci_call_probe+0xa/0xc
 [] __pci_device_probe+0x2e/0x3f
 [] pci_device_probe+0x1e/0x30
 [] really_probe+0x38/0xe0
 [] pci_match_device+0xf/0xc3
 [] driver_probe_device+0xa3/0xaf
 [] klist_next+0x52/0x8e
 [] __driver_attach+0x0/0x75
 [] __driver_attach+0x44/0x75
 [] bus_for_each_dev+0x35/0x59
 [] driver_attach+0x14/0x16
 [] __driver_attach+0x0/0x75
 [] bus_add_driver+0x5a/0xe0
 [] __pci_register_driver+0x5d/0x6d
 [] alsa_pcm_oss_init+0x6e/0x7c
 [] do_initcalls+0x58/0xf5
 [] proc_mkdir_mode+0x3e/0x51
 [] register_irq_proc+0x5f/0x6b
 [] sys_ioprio_get+0x11e/0x182
 [] init+0x0/0x153
 [] init+0x46/0x153
 [] kernel_thread_helper+0x7/0x10
 ===
PM: Adding info for ac97:0-0:ALC850
ALSA device list:
  #0: NVidia CK8S with ALC850 at 0xfebfb000, irq 19
  #1: Brooktree Bt878 at 0xf57ff000, irq 16

 cat /proc/interrupts
   CPU0
  0:  17552   IO-APIC-edge  timer
  1:382   IO-APIC-edge  i8042
  6:  3   IO-APIC-edge  floppy
  8:  1   IO-APIC-edge  rtc
  9:  0   IO-APIC-fasteoi   acpi
 12:   2847   IO-APIC-edge  i8042
 14:  25871   IO-APIC-edge  ide0
 15:878   IO-APIC-edge  ide1
 16:   8775   IO-APIC-fasteoi   bttv0, Bt87x audio,
 [EMAIL PROTECTED]::03:00.0
 17:  19414   IO-APIC-fasteoi   ohci_hcd:usb3, eth0
 18:  0   IO-APIC-fasteoi   eth1
 19:   5949   IO-APIC-fasteoi   ehci_hcd:usb1, NVidia CK8S
 20:  0   IO-APIC-fasteoi   ohci_hcd:usb2
NMI:  0
LOC:  17520
ERR:  1
MIS:  0

 lspci -v
00:00.0 Host bridge: nVidia Corporation nForce3 250Gb Host Bridge
(rev a1)
Subsystem: ASUSTeK Computer Inc. Unknown device 813f
Flags: bus master, 66MHz, fast devsel, latency 0
Memory at f800 (32-bit, prefetchable) [size=64M]
Capabilities: [44] HyperTransport: Slave or Primary Interface
Capabilities: [c0] AGP version 2.0

00:01.0 ISA bridge: nVidia Corporation nForce3 250Gb LPC Bridge (rev
a2)
Subsystem: ASUSTeK Computer Inc. Unknown device 813f
Flags: bus master, 66MHz, fast devsel, latency 0

00:01.1 SMBus: nVidia Corporation nForce 250Gb PCI System Management
(rev a1)
Subsystem: ASUSTeK Computer Inc. Unknown device 813f
Flags: 66MHz, fast devsel
I/O ports at 5080 [size=32]
I/O ports at 5000 [size=64]
I/O ports at 5040 [size=64]
Capabilities: [44] Power Management version 2

00:02.0 USB Controller: nVidia Corporation CK8S USB Controller (rev
a1) (prog-if 10 [OHCI])
Subsystem: ASUSTeK Computer Inc. Unknown device 813f
Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 20
Memory at febfd000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [44] Power Management version 2

00:02.1 USB Controller: nVidia Corporation CK8S USB Controller (rev
a1) (prog-if 10 [OHCI])
Subsystem: ASUSTeK Computer Inc. Unknown device 813f
Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 17
Memory at febfe000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [44] Power Management version 2

00:02.2 USB Controller: nVidia Corporation nForce3 EHCI USB 2.0
Controller (rev a2) (prog-if 20 [EHCI])
Subsystem: ASUSTeK Computer Inc. Unknown device 813f
Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 19
Memory at febffc00 (32-bit, non-prefetchable) [size=256]
Capabilities: [44] Debug port
Capabilities: [80] Power Management version 2

00:05.0 Bridge: nVidia Corporation CK8S Ethernet Controller (rev a2)
Subsystem: ASUSTeK Computer Inc. Unknown device 80a7
Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 17
Memory at febfc000 (32-bit, 

2.6.19.1: kobject_add failed for audio with -EEXIST

[markus reichelt]

Hi,

I'm still having this prob at boot. please advise.


Advanced Linux Sound Architecture Driver Version 1.0.13 (Tue Nov 28
14:07:24 2006 UTC).
ACPI: PCI Interrupt :02:0a.1[A] - Link [LNKA] - GSI 19 (level,
low) - IRQ 16
ACPI: PCI Interrupt Link [LAUI] enabled at IRQ 21
ACPI: PCI Interrupt :00:06.0[A] - Link [LAUI] - GSI 21 (level,
low) - IRQ 19
PCI: Setting latency timer of device :00:06.0 to 64
intel8x0_measure_ac97_clock: measured 60001 usecs
intel8x0: clocking to 55385
kobject_add failed for audio with -EEXIST, don't try to register
things with the same name in the same directory.
 [c02d6895] kobject_add+0x107/0x110
 [c03be831] class_device_add+0xa3/0x2a9
 [c03beac0] class_device_create+0x79/0x8f
 [c04cb6b7] sound_insert_unit+0xe8/0xfb
 [c04cb824] register_sound_special_device+0x111/0x119
 [c04ddead] snd_register_oss_device+0x107/0x15d
 [c04f2339] register_oss_dsp+0x4d/0x76
 [c02d6fc4] kobject_uevent+0x391/0x399
 [c04f238f] snd_pcm_oss_register_minor+0x2d/0xcc
 [c02d9413] vsnprintf+0x495/0x4d3
 [c04df36c] snd_timer_dev_register+0xbe/0xc3
 [c04dd9da] snd_device_register+0x32/0x53
 [c04e92cd] snd_pcm_timer_init+0xc0/0xf3
 [c04d9fb6] snd_add_device_sysfs_file+0x4b/0x52
 [c04e1c93] snd_pcm_dev_register+0x181/0x199
 [c04dda29] snd_device_register_all+0x2e/0x42
 [c04da8ee] snd_card_register+0x9/0xaa
 [c04f855a] snd_intel8x0_probe+0x170/0x195
 [c02e4cc0] pci_call_probe+0xa/0xc
 [c02e4cf0] __pci_device_probe+0x2e/0x3f
 [c02e4d1f] pci_device_probe+0x1e/0x30
 [c03bda46] really_probe+0x38/0xe0
 [c02e4c02] pci_match_device+0xf/0xc3
 [c03bdba6] driver_probe_device+0xa3/0xaf
 [c05a0d10] klist_next+0x52/0x8e
 [c03bdc18] __driver_attach+0x0/0x75
 [c03bdc5c] __driver_attach+0x44/0x75
 [c03bd16c] bus_for_each_dev+0x35/0x59
 [c03bdca1] driver_attach+0x14/0x16
 [c03bdc18] __driver_attach+0x0/0x75
 [c03bd5ef] bus_add_driver+0x5a/0xe0
 [c02e4f31] __pci_register_driver+0x5d/0x6d
 [c07ace04] alsa_pcm_oss_init+0x6e/0x7c
 [c078a761] do_initcalls+0x58/0xf5
 [c018b7da] proc_mkdir_mode+0x3e/0x51
 [c014229a] register_irq_proc+0x5f/0x6b
 [c018] sys_ioprio_get+0x11e/0x182
 [c010033d] init+0x0/0x153
 [c0100383] init+0x46/0x153
 [c01037b3] kernel_thread_helper+0x7/0x10
 ===
PM: Adding info for ac97:0-0:ALC850
ALSA device list:
  #0: NVidia CK8S with ALC850 at 0xfebfb000, irq 19
  #1: Brooktree Bt878 at 0xf57ff000, irq 16

 cat /proc/interrupts
   CPU0
  0:  17552   IO-APIC-edge  timer
  1:382   IO-APIC-edge  i8042
  6:  3   IO-APIC-edge  floppy
  8:  1   IO-APIC-edge  rtc
  9:  0   IO-APIC-fasteoi   acpi
 12:   2847   IO-APIC-edge  i8042
 14:  25871   IO-APIC-edge  ide0
 15:878   IO-APIC-edge  ide1
 16:   8775   IO-APIC-fasteoi   bttv0, Bt87x audio,
 [EMAIL PROTECTED]::03:00.0
 17:  19414   IO-APIC-fasteoi   ohci_hcd:usb3, eth0
 18:  0   IO-APIC-fasteoi   eth1
 19:   5949   IO-APIC-fasteoi   ehci_hcd:usb1, NVidia CK8S
 20:  0   IO-APIC-fasteoi   ohci_hcd:usb2
NMI:  0
LOC:  17520
ERR:  1
MIS:  0

 lspci -v
00:00.0 Host bridge: nVidia Corporation nForce3 250Gb Host Bridge
(rev a1)
Subsystem: ASUSTeK Computer Inc. Unknown device 813f
Flags: bus master, 66MHz, fast devsel, latency 0
Memory at f800 (32-bit, prefetchable) [size=64M]
Capabilities: [44] HyperTransport: Slave or Primary Interface
Capabilities: [c0] AGP version 2.0

00:01.0 ISA bridge: nVidia Corporation nForce3 250Gb LPC Bridge (rev
a2)
Subsystem: ASUSTeK Computer Inc. Unknown device 813f
Flags: bus master, 66MHz, fast devsel, latency 0

00:01.1 SMBus: nVidia Corporation nForce 250Gb PCI System Management
(rev a1)
Subsystem: ASUSTeK Computer Inc. Unknown device 813f
Flags: 66MHz, fast devsel
I/O ports at 5080 [size=32]
I/O ports at 5000 [size=64]
I/O ports at 5040 [size=64]
Capabilities: [44] Power Management version 2

00:02.0 USB Controller: nVidia Corporation CK8S USB Controller (rev
a1) (prog-if 10 [OHCI])
Subsystem: ASUSTeK Computer Inc. Unknown device 813f
Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 20
Memory at febfd000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [44] Power Management version 2

00:02.1 USB Controller: nVidia Corporation CK8S USB Controller (rev
a1) (prog-if 10 [OHCI])
Subsystem: ASUSTeK Computer Inc. Unknown device 813f
Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 17
Memory at febfe000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [44] Power Management version 2

00:02.2 USB Controller: nVidia Corporation nForce3 EHCI USB 2.0
Controller (rev a2) (prog-if 20 [EHCI])
Subsystem: ASUSTeK Computer Inc. Unknown device 813f
Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 19
Memory at febffc00 (32-bit, non-prefetchable) [size=256]

2.6.19: kobject_add failed with -EEXIST

[markus reichelt]

Hi,

I still have got the same problem during boot with monolithic vanilla
kernels 2.6.18.x & 2.6.19 when it comes to init of the sound
hardware. Please advise.

Linux tatooine 2.6.19 #1 PREEMPT Sun Dec 3 13:01:23 CET 2006 i686
athlon-4 i386 GNU/Linux

lspci

00:00.0 Host bridge: nVidia Corporation nForce3 250Gb Host Bridge
(rev a1)
00:01.0 ISA bridge: nVidia Corporation nForce3 250Gb LPC Bridge (rev
a2)
00:01.1 SMBus: nVidia Corporation nForce 250Gb PCI System Management
(rev a1)
00:02.0 USB Controller: nVidia Corporation CK8S USB Controller (rev
a1)
00:02.1 USB Controller: nVidia Corporation CK8S USB Controller (rev
a1)
00:02.2 USB Controller: nVidia Corporation nForce3 EHCI USB 2.0
Controller (rev a2)
00:05.0 Bridge: nVidia Corporation CK8S Ethernet Controller (rev a2)
00:06.0 Multimedia audio controller: nVidia Corporation nForce3 250Gb
AC'97 Audio Controller (rev a1)
00:08.0 IDE interface: nVidia Corporation CK8S Parallel ATA
Controller (v2.5) (rev a2)
00:0b.0 PCI bridge: nVidia Corporation nForce3 250Gb AGP Host to PCI
Bridge (rev a2)
00:0e.0 PCI bridge: nVidia Corporation nForce3 250Gb PCI-to-PCI
Bridge (rev a2)
00:18.0 Host bridge: Advanced Micro Devices [AMD] K8
[Athlon64/Opteron] HyperTransport Technology Configuration
00:18.1 Host bridge: Advanced Micro Devices [AMD] K8
[Athlon64/Opteron] Address Map
00:18.2 Host bridge: Advanced Micro Devices [AMD] K8
[Athlon64/Opteron] DRAM Controller
00:18.3 Host bridge: Advanced Micro Devices [AMD] K8
[Athlon64/Opteron] Miscellaneous Control
02:06.0 PCI bridge: Hint Corp HB6 Universal PCI-PCI bridge
(non-transparent mode) (rev 15)
02:09.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL-8139/8139C/8139C+ (rev 10)
02:0a.0 Multimedia video controller: Brooktree Corporation Bt878
Video Capture (rev 11)
02:0a.1 Multimedia controller: Brooktree Corporation Bt878 Audio
Capture (rev 11)
03:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA
G400/G450 (rev 85)


dmesg-snip

Advanced Linux Sound Architecture Driver Version 1.0.13 (Tue Nov 28
14:07:24 2006 UTC).
ACPI: PCI Interrupt :02:0a.1[A] -> Link [LNKA] -> GSI 19 (level,
low) -> IRQ 16
ACPI: PCI Interrupt Link [LAUI] enabled at IRQ 21
ACPI: PCI Interrupt :00:06.0[A] -> Link [LAUI] -> GSI 21 (level,
low) -> IRQ 19
PCI: Setting latency timer of device :00:06.0 to 64
intel8x0_measure_ac97_clock: measured 60001 usecs
intel8x0: clocking to 55385
kobject_add failed for audio with -EEXIST, don't try to register
things with the same name in the same directory.
 [] kobject_add+0x107/0x110
 [] class_device_add+0xa3/0x2a9
 [] class_device_create+0x79/0x8f
 [] sound_insert_unit+0xe8/0xfb
 [] register_sound_special_device+0x111/0x119
 [] snd_register_oss_device+0x107/0x15d
 [] register_oss_dsp+0x4d/0x76
 [] kobject_uevent+0x391/0x399
 [] snd_pcm_oss_register_minor+0x2d/0xcc
 [] vsnprintf+0x495/0x4d3
 [] snd_timer_dev_register+0xbe/0xc3
 [] snd_device_register+0x32/0x53
 [] snd_pcm_timer_init+0xc0/0xf3
 [] snd_add_device_sysfs_file+0x4b/0x52
 [] snd_pcm_dev_register+0x181/0x199
 [] snd_device_register_all+0x2e/0x42
 [] snd_card_register+0x9/0xaa
 [] snd_intel8x0_probe+0x170/0x195
 [] pci_call_probe+0xa/0xc
 [] __pci_device_probe+0x2e/0x3f
 [] pci_device_probe+0x1e/0x30
 [] really_probe+0x38/0xe0
 [] pci_match_device+0xf/0xc3
 [] driver_probe_device+0xa3/0xaf
 [] klist_next+0x52/0x8e
 [] __driver_attach+0x0/0x75
 [] __driver_attach+0x44/0x75
 [] bus_for_each_dev+0x35/0x59
 [] driver_attach+0x14/0x16
 [] __driver_attach+0x0/0x75
 [] bus_add_driver+0x5a/0xe0
 [] __pci_register_driver+0x5d/0x6d
 [] alsa_pcm_oss_init+0x6e/0x7c
 [] do_initcalls+0x58/0xf5
 [] proc_mkdir_mode+0x3e/0x51
 [] register_irq_proc+0x5f/0x6b
 [] sys_ioprio_get+0x12a/0x182
 [] init+0x0/0x153
 [] init+0x46/0x153
 [] kernel_thread_helper+0x7/0x10
 ===
PM: Adding info for ac97:0-0:ALC850
ALSA device list:
  #0: NVidia CK8S with ALC850 at 0xfebfb000, irq 19
  #1: Brooktree Bt878 at 0xf57ff000, irq 16


 gcc -v

Reading specs from /usr/lib/gcc/i486-slackware-linux/3.4.6/specs
Configured with: ../gcc-3.4.6/configure --prefix=/usr --enable-shared
--enable-threads=posix --enable-__cxa_atexit --disable-checking
--with-gnu-ld --verbose --target=i486-slackware-linux
--host=i486-slackware-linux
Thread model: posix
gcc version 3.4.6


-- 
left blank, right bald


pgpMZ3Kn99QTT.pgp
Description: PGP signature

2.6.19: kobject_add failed with -EEXIST

[markus reichelt]

Hi,

I still have got the same problem during boot with monolithic vanilla
kernels 2.6.18.x  2.6.19 when it comes to init of the sound
hardware. Please advise.

Linux tatooine 2.6.19 #1 PREEMPT Sun Dec 3 13:01:23 CET 2006 i686
athlon-4 i386 GNU/Linux

lspci

00:00.0 Host bridge: nVidia Corporation nForce3 250Gb Host Bridge
(rev a1)
00:01.0 ISA bridge: nVidia Corporation nForce3 250Gb LPC Bridge (rev
a2)
00:01.1 SMBus: nVidia Corporation nForce 250Gb PCI System Management
(rev a1)
00:02.0 USB Controller: nVidia Corporation CK8S USB Controller (rev
a1)
00:02.1 USB Controller: nVidia Corporation CK8S USB Controller (rev
a1)
00:02.2 USB Controller: nVidia Corporation nForce3 EHCI USB 2.0
Controller (rev a2)
00:05.0 Bridge: nVidia Corporation CK8S Ethernet Controller (rev a2)
00:06.0 Multimedia audio controller: nVidia Corporation nForce3 250Gb
AC'97 Audio Controller (rev a1)
00:08.0 IDE interface: nVidia Corporation CK8S Parallel ATA
Controller (v2.5) (rev a2)
00:0b.0 PCI bridge: nVidia Corporation nForce3 250Gb AGP Host to PCI
Bridge (rev a2)
00:0e.0 PCI bridge: nVidia Corporation nForce3 250Gb PCI-to-PCI
Bridge (rev a2)
00:18.0 Host bridge: Advanced Micro Devices [AMD] K8
[Athlon64/Opteron] HyperTransport Technology Configuration
00:18.1 Host bridge: Advanced Micro Devices [AMD] K8
[Athlon64/Opteron] Address Map
00:18.2 Host bridge: Advanced Micro Devices [AMD] K8
[Athlon64/Opteron] DRAM Controller
00:18.3 Host bridge: Advanced Micro Devices [AMD] K8
[Athlon64/Opteron] Miscellaneous Control
02:06.0 PCI bridge: Hint Corp HB6 Universal PCI-PCI bridge
(non-transparent mode) (rev 15)
02:09.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL-8139/8139C/8139C+ (rev 10)
02:0a.0 Multimedia video controller: Brooktree Corporation Bt878
Video Capture (rev 11)
02:0a.1 Multimedia controller: Brooktree Corporation Bt878 Audio
Capture (rev 11)
03:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA
G400/G450 (rev 85)


dmesg-snip

Advanced Linux Sound Architecture Driver Version 1.0.13 (Tue Nov 28
14:07:24 2006 UTC).
ACPI: PCI Interrupt :02:0a.1[A] - Link [LNKA] - GSI 19 (level,
low) - IRQ 16
ACPI: PCI Interrupt Link [LAUI] enabled at IRQ 21
ACPI: PCI Interrupt :00:06.0[A] - Link [LAUI] - GSI 21 (level,
low) - IRQ 19
PCI: Setting latency timer of device :00:06.0 to 64
intel8x0_measure_ac97_clock: measured 60001 usecs
intel8x0: clocking to 55385
kobject_add failed for audio with -EEXIST, don't try to register
things with the same name in the same directory.
 [c02d6891] kobject_add+0x107/0x110
 [c03be821] class_device_add+0xa3/0x2a9
 [c03beab0] class_device_create+0x79/0x8f
 [c04cb69b] sound_insert_unit+0xe8/0xfb
 [c04cb808] register_sound_special_device+0x111/0x119
 [c04dde91] snd_register_oss_device+0x107/0x15d
 [c04f231d] register_oss_dsp+0x4d/0x76
 [c02d6fc0] kobject_uevent+0x391/0x399
 [c04f2373] snd_pcm_oss_register_minor+0x2d/0xcc
 [c02d940f] vsnprintf+0x495/0x4d3
 [c04df350] snd_timer_dev_register+0xbe/0xc3
 [c04dd9be] snd_device_register+0x32/0x53
 [c04e92b1] snd_pcm_timer_init+0xc0/0xf3
 [c04d9f9a] snd_add_device_sysfs_file+0x4b/0x52
 [c04e1c77] snd_pcm_dev_register+0x181/0x199
 [c04dda0d] snd_device_register_all+0x2e/0x42
 [c04da8d2] snd_card_register+0x9/0xaa
 [c04f853e] snd_intel8x0_probe+0x170/0x195
 [c02e4cb0] pci_call_probe+0xa/0xc
 [c02e4ce0] __pci_device_probe+0x2e/0x3f
 [c02e4d0f] pci_device_probe+0x1e/0x30
 [c03bda36] really_probe+0x38/0xe0
 [c02e4bf2] pci_match_device+0xf/0xc3
 [c03bdb96] driver_probe_device+0xa3/0xaf
 [c05a0cb0] klist_next+0x52/0x8e
 [c03bdc08] __driver_attach+0x0/0x75
 [c03bdc4c] __driver_attach+0x44/0x75
 [c03bd15c] bus_for_each_dev+0x35/0x59
 [c03bdc91] driver_attach+0x14/0x16
 [c03bdc08] __driver_attach+0x0/0x75
 [c03bd5df] bus_add_driver+0x5a/0xe0
 [c02e4f21] __pci_register_driver+0x5d/0x6d
 [c07ace3f] alsa_pcm_oss_init+0x6e/0x7c
 [c078a761] do_initcalls+0x58/0xf5
 [c018b7ce] proc_mkdir_mode+0x3e/0x51
 [c014229a] register_irq_proc+0x5f/0x6b
 [c018] sys_ioprio_get+0x12a/0x182
 [c010033d] init+0x0/0x153
 [c0100383] init+0x46/0x153
 [c01037b3] kernel_thread_helper+0x7/0x10
 ===
PM: Adding info for ac97:0-0:ALC850
ALSA device list:
  #0: NVidia CK8S with ALC850 at 0xfebfb000, irq 19
  #1: Brooktree Bt878 at 0xf57ff000, irq 16


 gcc -v

Reading specs from /usr/lib/gcc/i486-slackware-linux/3.4.6/specs
Configured with: ../gcc-3.4.6/configure --prefix=/usr --enable-shared
--enable-threads=posix --enable-__cxa_atexit --disable-checking
--with-gnu-ld --verbose --target=i486-slackware-linux
--host=i486-slackware-linux
Thread model: posix
gcc version 3.4.6


-- 
left blank, right bald


pgpMZ3Kn99QTT.pgp
Description: PGP signature

Re: Announce loop-AES-v3.0b file/swap crypto package

[markus reichelt]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Fruhwirth Clemens <[EMAIL PROTECTED]> wrote:
> On Mon, 2005-01-17 at 22:26 +0100, markus reichelt wrote:
> 
> > Fruhwirth Clemens <[EMAIL PROTECTED]> wrote:
> > > This is FUD. To get serious in-depth information about the problems
> > > associated with dm-crypt and loop-aes read,
> > > 
> > > http://clemens.endorphin.org/LinuxHDEncSettings
> > 
> > excuse me, but that's just too academic for the end user. whatever
> > you're trying to say (apart from your obvious grudge against what
> > Jari is doing), it's not clear enough.
> 
> I can't do nothing about that. Enlightenment is a gift everyone has to
> fight for on it's own.

yet you continue to stick the end user's nose into those hills and
mountains of enlightment (still largely to be fought for), knowing
for sure it won't do the end user any good.

so it seems to me that you're not interested in a mere end user's
feedback and even mock one's frustration about you communicating your
viewpoint.


> To the rest of your slightly emotional post. Most of the question
> have been already answered. I'm not going to restate my answers,
> the archive has it.

so i won't get answers to the questions not answered in the archives.

at least that's an answer not dripping with ... stuff.


> To your critiques of my reviewers: 
> 
> Your personal opinion has the same importance to me as the my
> review sources have to you. That's none.

read my lips. humor is for the gifted ones, and for everyone else
there's smilies. to repeat my feedback, unwrapped this time: include
additional info about your reviewers, a link will do just fine.
there's the slight possibility that your site's visitors may benefit
from these links, because your site does a pretty good job of leaving
end users in the dark.

let me summarize, i did not criticise your reviewers, i still am
criticising you for not stating the above on your site. may i suggest
you do so in the near future?


> What probably makes a different for others is, that the review
> sources on my web pages includes kernel developers, regulars on the
> dm-crypt mailing list and the IEEE chairman of Security in Storage
> Working Group.

not all these ppl are ignoring end users - why are you?

you seem to be anxious to state these facts on your site, be it just
for clarity's sake. seems that hill of enlightment is a full-grown
mountain, so be it. i can't tickle you every now and then for helpful
information though.

not every plant is a flower, and not everyone considers hunting down
information (which common sense would expect in plain sight) a worthy
fight for enlightment (hint hint).


> I'm sorry for my ranting ignorance. Life time is a limited
> resource. Especially mine.

I guess this is copyrighted under the GPL. please mention that fact
in the future.

/EOD
- -- 
Bastard Administrator in $hell

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFB8DLbLMyTO8Kj/uQRAnMHAJ9zpnhjXEg24uP8zmTK1ltqNgNNtACeKhB6
HXbcBNp6xgxlcEDDK/n88Qs=
=dR7Q
-END PGP SIGNATURE-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Announce loop-AES-v3.0b file/swap crypto package

[markus reichelt]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Fruhwirth Clemens [EMAIL PROTECTED] wrote:
 On Mon, 2005-01-17 at 22:26 +0100, markus reichelt wrote:
 
  Fruhwirth Clemens [EMAIL PROTECTED] wrote:
   This is FUD. To get serious in-depth information about the problems
   associated with dm-crypt and loop-aes read,
   
   http://clemens.endorphin.org/LinuxHDEncSettings
  
  excuse me, but that's just too academic for the end user. whatever
  you're trying to say (apart from your obvious grudge against what
  Jari is doing), it's not clear enough.
 
 I can't do nothing about that. Enlightenment is a gift everyone has to
 fight for on it's own.

yet you continue to stick the end user's nose into those hills and
mountains of enlightment (still largely to be fought for), knowing
for sure it won't do the end user any good.

so it seems to me that you're not interested in a mere end user's
feedback and even mock one's frustration about you communicating your
viewpoint.


 To the rest of your slightly emotional post. Most of the question
 have been already answered. I'm not going to restate my answers,
 the archive has it.

so i won't get answers to the questions not answered in the archives.

at least that's an answer not dripping with ... stuff.


 To your critiques of my reviewers: 
 
 Your personal opinion has the same importance to me as the my
 review sources have to you. That's none.

read my lips. humor is for the gifted ones, and for everyone else
there's smilies. to repeat my feedback, unwrapped this time: include
additional info about your reviewers, a link will do just fine.
there's the slight possibility that your site's visitors may benefit
from these links, because your site does a pretty good job of leaving
end users in the dark.

let me summarize, i did not criticise your reviewers, i still am
criticising you for not stating the above on your site. may i suggest
you do so in the near future?


 What probably makes a different for others is, that the review
 sources on my web pages includes kernel developers, regulars on the
 dm-crypt mailing list and the IEEE chairman of Security in Storage
 Working Group.

not all these ppl are ignoring end users - why are you?

you seem to be anxious to state these facts on your site, be it just
for clarity's sake. seems that hill of enlightment is a full-grown
mountain, so be it. i can't tickle you every now and then for helpful
information though.

not every plant is a flower, and not everyone considers hunting down
information (which common sense would expect in plain sight) a worthy
fight for enlightment (hint hint).


 I'm sorry for my ranting ignorance. Life time is a limited
 resource. Especially mine.

I guess this is copyrighted under the GPL. please mention that fact
in the future.

/EOD
- -- 
Bastard Administrator in $hell

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFB8DLbLMyTO8Kj/uQRAnMHAJ9zpnhjXEg24uP8zmTK1ltqNgNNtACeKhB6
HXbcBNp6xgxlcEDDK/n88Qs=
=dR7Q
-END PGP SIGNATURE-
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Announce loop-AES-v3.0b file/swap crypto package

[markus reichelt]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Fruhwirth Clemens <[EMAIL PROTECTED]> wrote:
> This is FUD. To get serious in-depth information about the problems
> associated with dm-crypt and loop-aes read,
> 
> http://clemens.endorphin.org/LinuxHDEncSettings

excuse me, but that's just too academic for the end user. whatever
you're trying to say (apart from your obvious grudge against what
Jari is doing), it's not clear enough.

given the choices of dm-crypt, cryptoloop, and loop-aes it is awfully
clear what to use. your patches seem a bit like the cure to all and
everything which is suspicious like hell to me.


> This document has been reviewed by a couple of noteworthy people, also
> partially to counter the on-going FUD postings, Jari Ruusu has been
> posting to LKML repeatedly.

FUD crap for heaven's sake!

(i'm calming down, not given an example of the fuss about md5
collisions lately you're not applying double standards are you?!)

first of all, when whatever people review a document the document
itself is not understood any better afterwards than its virgin
cousin. as far as i'm concerned this whole silly review thing serves
the author's sleep but not the end user, so it could have been
reviewed by [EMAIL PROTECTED] for its comedy (or lack
thereof by [EMAIL PROTECTED]) ;-)

i'm not saying it's wrong, it's just that ppl don't get it who should
according to your way of communicating the matter.

btw, just being curious, but did/do you have something to add to
this?

maybe you're still just missing Jari's point.

http://lkml.org/lkml/2004/5/16/71



http://marc.free.net.ph/message/20040726.181150.d4b819be.en.html

yes, we know you replied to that message at
http://marc.free.net.ph/message/20040726.225933.cb46c940.en.html. and
there it is again: as an ordinary user i take it that you claim to
understand what Jari's point is _all along_ but yet you both fail to
communicate that clearly during the beginning of a discussion
(repeatedly as google assures me - for the fun of it?) and you yet
acknowledge that Jari's claims are legit. might i inquire why you do
so (plain and simple please it can't be that hard)?

all i see is you giving the ordinary user of crypto on linux systems
the impression that Jari's claims are untrue, and one should follow
you the hero that brings back strong crypto to mainline. everyone
else is too stupid too realise that, and so, please get going ppl.
makes me sick :(

i'm not talking about loop-aes being the best there is, it's just
that loop-aes is getting the job done. cryptoloop and dm-crypt fail
to do so, and yet you bash loop-aes instead of contributing your
academic knowledge to the project providing the best solution for the
end user so far.

which makes me wonder, there are 3 different crypto implementations
and still you had to come up with yet another one instead of being
able to somehow work together with (at least) one of the existing
ones... because of technical issues? i doubt it. loop-aes could have
been the ideal testing platform for your stuff.


> James Morris: Can we please talk about the merge of my LRW patches soon?
> The insecurity of CBC based encryption such as dm-crypt and loop-aes is
> the reason why I have been pushing this patch so hard for the last two
> months now.

several weeks back i got the impression those patches were to be
included into mainline really soon. what's the delay?

by whom have these patches of yours been tested? for how long, in
which environment? etc. "reviewed by funny people the ordinary user
doesn't know and there's no link one can check up on them on the page
reviewed" doesn't count for me i'm afraid.

i'm gonna stick to loop-aes, and sorry for the rant but i'm just sick
of wasting energy this way, kids.

@clemens: i'm not bashing your work, i'm ranting from an end user's
point of view.

- -- 
Bastard Administrator in $hell

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFB7C2XLMyTO8Kj/uQRAi/5AJ4osZKT/D29NoHfjIT/+2cnIZXMhQCfQ31N
09aQfmhB2pwJIU1kkx6Fyf4=
=cQZG
-END PGP SIGNATURE-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Announce loop-AES-v3.0b file/swap crypto package

[markus reichelt]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Fruhwirth Clemens [EMAIL PROTECTED] wrote:
 This is FUD. To get serious in-depth information about the problems
 associated with dm-crypt and loop-aes read,
 
 http://clemens.endorphin.org/LinuxHDEncSettings

excuse me, but that's just too academic for the end user. whatever
you're trying to say (apart from your obvious grudge against what
Jari is doing), it's not clear enough.

given the choices of dm-crypt, cryptoloop, and loop-aes it is awfully
clear what to use. your patches seem a bit like the cure to all and
everything which is suspicious like hell to me.


 This document has been reviewed by a couple of noteworthy people, also
 partially to counter the on-going FUD postings, Jari Ruusu has been
 posting to LKML repeatedly.

FUD crap for heaven's sake!

(i'm calming down, not given an example of the fuss about md5
collisions lately you're not applying double standards are you?!)

first of all, when whatever people review a document the document
itself is not understood any better afterwards than its virgin
cousin. as far as i'm concerned this whole silly review thing serves
the author's sleep but not the end user, so it could have been
reviewed by [EMAIL PROTECTED] for its comedy (or lack
thereof by [EMAIL PROTECTED]) ;-)

i'm not saying it's wrong, it's just that ppl don't get it who should
according to your way of communicating the matter.

btw, just being curious, but did/do you have something to add to
this?

maybe you're still just missing Jari's point.

http://lkml.org/lkml/2004/5/16/71



http://marc.free.net.ph/message/20040726.181150.d4b819be.en.html

yes, we know you replied to that message at
http://marc.free.net.ph/message/20040726.225933.cb46c940.en.html. and
there it is again: as an ordinary user i take it that you claim to
understand what Jari's point is _all along_ but yet you both fail to
communicate that clearly during the beginning of a discussion
(repeatedly as google assures me - for the fun of it?) and you yet
acknowledge that Jari's claims are legit. might i inquire why you do
so (plain and simple please it can't be that hard)?

all i see is you giving the ordinary user of crypto on linux systems
the impression that Jari's claims are untrue, and one should follow
you the hero that brings back strong crypto to mainline. everyone
else is too stupid too realise that, and so, please get going ppl.
makes me sick :(

i'm not talking about loop-aes being the best there is, it's just
that loop-aes is getting the job done. cryptoloop and dm-crypt fail
to do so, and yet you bash loop-aes instead of contributing your
academic knowledge to the project providing the best solution for the
end user so far.

which makes me wonder, there are 3 different crypto implementations
and still you had to come up with yet another one instead of being
able to somehow work together with (at least) one of the existing
ones... because of technical issues? i doubt it. loop-aes could have
been the ideal testing platform for your stuff.


 James Morris: Can we please talk about the merge of my LRW patches soon?
 The insecurity of CBC based encryption such as dm-crypt and loop-aes is
 the reason why I have been pushing this patch so hard for the last two
 months now.

several weeks back i got the impression those patches were to be
included into mainline really soon. what's the delay?

by whom have these patches of yours been tested? for how long, in
which environment? etc. reviewed by funny people the ordinary user
doesn't know and there's no link one can check up on them on the page
reviewed doesn't count for me i'm afraid.

i'm gonna stick to loop-aes, and sorry for the rant but i'm just sick
of wasting energy this way, kids.

@clemens: i'm not bashing your work, i'm ranting from an end user's
point of view.

- -- 
Bastard Administrator in $hell

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFB7C2XLMyTO8Kj/uQRAi/5AJ4osZKT/D29NoHfjIT/+2cnIZXMhQCfQ31N
09aQfmhB2pwJIU1kkx6Fyf4=
=cQZG
-END PGP SIGNATURE-
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/